My goal was to create a DNS server as simple as the LDAP server I've been contributing to (glauth) and here it is: https://github.com/fusion/kittendns<p>A few things to know about it:
- It is easy to configure using a Toml file
- I am using it to bail my coredns/etcd instances when under attack
- (yes, it also works as a service location server)
- It comes with a simple, plain English, rule engine that doesn't do much at this point
- It can be used with LetsEncrypt. I use it to retrieve certificates for my home servers.
- RFC: all the nice ones :)<p>Anyway, feedback is welcome.
As I expected, HN delivers :)<p>I am going to try to address the input I've received so far:<p># Licensing<p>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.<p># Data in the configuration file<p>@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)<p># Toml<p>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.<p># Record reuse<p>@drdaeman making another valid point. It's going to be an easy fix, which is good.<p># Split horizon DNS<p>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).<p>I have a work project this would help with, but at this point using it commercially feels a little shaky.
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.<p>Only yaml isn't great and toml is so much worse.<p>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.<p>Complicated toml is unreadable, if yaml isn't enough, you probably need json, not toml.
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.<p>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).<p>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.
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.<p>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.<p>I wonder… does anyone have thoughts on that?
a DNS guide on how to get Linux itself to use the DNS server would be immense. for the life of my I cannot get systemd-resolvd to use itself as a DNS server.<p>How can dynamic DNS entries be added by dhcp servers to kitten? I feel like self addressing is something you want for home iot.
Questions<p>Is this meant to be recursive or authoritative DNS?<p>Is there an equivalent of query logging?<p>Are there plans to make this full featured liked BIND, or definitely not because your goal is to keep it "no fat, light"?