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 :)
Anyway, feedback is welcome.
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.
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.
Parsing json as a human is unambiguous and simple.
Parsing yaml and toml is full of ambiguity and readability problems depending on where you're reading it.
The only people who think json is a bad format are the type of people that think semicolons are the problem. They're just not.
This is however besides the point. I hate any format if it is misused. TOML is great for config files up to a certain complexity. It is not great for configuration files that should be code. If you feel your configuration file could use a configuration file, you might be doing it wrong.
TOML to me is an successor to INI, with support for lists and other things that can be useful for typical configurations. I have never had any configuration-syntax related issue with any tool that used TOML for configuration — YAML on the other hand...
shrug
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."
perl -MYAML -E 'say YAML::LoadFile("filename.yaml")->{foo}{bar}'
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.
Or more accurately, I should hate you. Thanks for the reference, I am going to look into it as it's definitely something I would like to make work.
Serving different data on the same zone based in subnets of clients.
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?
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.
How can dynamic DNS entries be added by dhcp servers to kitten? I feel like self addressing is something you want for home iot.
Is this meant to be recursive or authoritative DNS?
Is there an equivalent of query logging?
Are there plans to make this full featured liked BIND, or definitely not because your goal is to keep it "no fat, light"?
Query logging can be easily implemented.
I don't expect to ever make this as full featured as BIND. Then again, this also was true of Glauth, and correctness-as-a-goal ends up forcing us to roll lots of functionality in the software.
I have a work project this would help with, but at this point using it commercially feels a little shaky.
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.