Show HN: KittenDNS – easy to setup, rule engine, LetsEncrypt compatible

As I expected, HN delivers :)

I am going to try to address the input I've received so far:

# Licensing

Arg. How could I forget? The project is now licensed under Apache 2, which is compatible with the BSD licenses that @d_meeze listed. I've used it in many previous projects, including RootTools, and some projects were included in multiple commercial projects.

# Data in the configuration file

@drdaeman yes this is definitely with simplicity in mind. Right now, the updates the server accepts are limited to RFC2136 for LetsEncrypt's ephemeral TXT fields. If this becomes a necessary feature, I may do the same as with Glauth and introduce database plugins (SQLite would remain a light, but not as simple approach)

# Toml

Controversial as always. @dhzhzjsbevs, I found that if I provide an amply documented template file, folks find it easy to use. Is this a great configuration option? No, not it is not. I personally dislike all of them.

# Record reuse

@drdaeman making another valid point. It's going to be an easy fix, which is good.

# Split horizon DNS

And then we get to @jchw and one of my unstated goals. Right now, I am using the rule engine to alter responses. Obviously, a nice demo of what it can do, but a bad idea overall. Can anyone think of a way to implement split DNS other than filtering based on which interface the query came through? I do extract the query source's IP address, but this only tells me which server is recursing.

Looks helpful - have you chosen a license to release your parts under? So far it seems to build on BSD (GO) and some completely copyrighted extensions from (github.com/miekg/dns).

I have a work project this would help with, but at this point using it commercially feels a little shaky.

I could be wrong, but one issue I see is that zone data seems to be a part of configuration (there is some indirection with `flattenRecords`, but still). I realize it's probably intentional in the name of simplicity, but this would prevent you from e.g. persisting received updates. I suppose I'm not the only weirdo out there who manages my DNS records with plain `nsupdate(8)`... Unless this contradicts your goals, I would say zone data should be independent from server configuration.

Also, I could be wrong about the design again, but on a quick glance it looks that because `app.Records` map is keyed only by the record name it seems that it's not possible (or at least not trivial) to have multiple different types of records for the same DNS name. For example, most of my zones have at least SOA, NS, A, AAAA, MX and TXT (and DNSSEC stuff if the TLD supports it) at their root. I suspect the idea is that `config.Record` is an universal record that tries to encompass all possible data into one superstructure (e.g. it seems that it can represent and A and AAAA simultaneously), but I don't think this would scale well. And TXT records can be particularly messy - there could be a real need to have more than one for the same DNS name (e.g. SPF record AND "google-site-verification" record).

All of this is based only on a Sunday evening quick cursory glance of an interesting project - so please forgive me if I got something wrong.

I still don't understand why people use toml. It's like someone said, man, yaml is great but it could be better and toml is the result.

Only yaml isn't great and toml is so much worse.

Sorry sounds off topic but the way you say it's "easy to configure" and include toml in the same sentence just gave me flashbacks to traefik.

Complicated toml is unreadable, if yaml isn't enough, you probably need json, not toml.

Toml is not much more than a standardization of how to represent trees with INI. INI has been in use since at least the 90's and it persists because it is easy to read and edit, and supports comments.

I actually find traefik quite nice to configure vs. the old conf disaster of apache. I've configured it by hand and also generated config by scripts with ease.

If you want to complain about a design on HN the better way is to suggest a design you think is superior.

Traefik supports all three of those interchangeably.

Official, meaningful tooling for yaml also doesn't exist. Parsing and emitting yaml does nothing for anyone until you can actually extract structures from the format.

The full yaml standard is also full of features no one ever actually uses in practice, but if you don't implement it, you are thusly not compliant with the specification.

If you read it, you'd go, "Wow, you can do that?" and "That's bad that you can do that."

There is a parser and producer for yaml in all the major languages. I mean, even

    perl -MYAML -E 'say YAML::LoadFile("filename.yaml")->{foo}{bar}'

what level of tooling do you mean?

No actual comments about the software, but related to its goals I have been trying to figure out how to best handle a split horizon home lab type setup. I’m halfway in on using Tailscale and halfway in on using DNS.

Makes me sorta wonder if it would be a good idea to try to split the horizon 3 ways, by responding to DNS requests differently based on whether the DNS server is contacted via a local IP, a tailscale CG NAT IP, or another IP from the internet. I guess that implies your system DNS server would go over Tailscale in the happy case—maybe not a great idea?—but it would be useful in some situations, like ensuring my local Jellyfin server is efficient when used by even other people’s devices when they are on my WiFi network, but still allowing me to tunnel to everything in a uniform way, not needing to go through the gate that clients from the internet must.

I wonder… does anyone have thoughts on that?

BIND out of the box supports split horizon DNS as many ways as you want, I do 3 way split horizon with BIND.

I've never tried pairing it with Tailscale(I don't use it), but I pair it with Consul.

The config and docs aren't the prettiest, but it works fine. Most DNS software can't handle this use-case well.