The authors of this are CZ.NIC (whose website is confusingly http://nic.cz). They're the same people behind the thoroughly awesome Turris Router (https://www.turris.cz/en/). The complete hardware design for this device is open and I can vouch for it being a very awesome bit of kit.
The benchmarks for the DNS server are very impressive. Way beyond our needs though: we're doing a few hundred million queries per month, so ~100qps. Knot handles >500k qps! We've recently switched our authoritative DNS from djbdns to gdnsd (https://github.com/blblack/gdnsd), primarily due to the GSLB features.
Lots of great stuff coming out of CZ.NIC - if you're reading this, keep it up!
Knot DNS already have similar infrastructure in the place to support dynamic responses (the dynamic modules - IP(v4,v6) PTR/AAAA/A synthetis is a fine example what we can do), but more modules are missing. Any hint on what we should focus first? We will probably introduce online signing first before adding more modules, but, hey, if you can to discuss your needs on the mailing list we would be happy to hear about other deployment needs.
Freescale P2020, 2GB Ram, 16MB NOR Flash (the stuff the CPU can directly execute from, ty), 256 MB NAND Flash (the stuff the CPU has to copy to RAM before executing), 4xGigabit LAN, Wifi N w/ 3x3 MIMO... All driven by OpenWRT. Awesome!
But what's their wifi chip? They don't mention it in their spec page, and I can't identify it in the schematics. I suppose it's a miniPCIe card?
gdnsd looks awesome, I just found it a few days ago. We will probably need a combination of manually assigned geo areas + fallback on automatic assignment based on distance.
The failover modules can be a little awkward to wrap your head around at first. There's simple, weighted and multi failover modules, and sometimes the one you want isn't the one you'd expect!
Aside from that I can't fault it. We're still running a pre-1.0 version (around a year or so old) and it's not skipped a beat.
But what about IPv6 records or DKIM/SPF TXT entries?
It is hell to maintain more than a couple of these records for djbdns.
I had to use an online tool every time to help me convert my entries to tinydns format.
I switched to PowerDNS mainly for this reason.
I remember that djbdns had some other quirks too. Like I had to setup a supervisor to run it (no integration with the init system), I had to run one instance for IPv4, one for IPv6 and one for IPv4 zone transfers. Also it didn't support zone transfers over IPv6.
Maybe all these have been fixed, it is a couple years since I last used it.
I've written a library in Scheme to generate my tinydns configuration from a functional program. It includes error-checking, IPv6 and SPF support (haven't used DKIM yet). I might clean it up and publish it if there's interest.
I'll send you notification when done if you give me your email (you can contact me at the URL in my profile). (Or supposedly you could "watch" the Github repo above for similar effect.)
Edit: the functionality on Github to get notifications is "watch", not "star".
djbdns is a great read and exemplary code, but I wouldn't use it in production without significant modification; it's far too easy to DOS.
TinyDNS and dnscache can each be sped up by about a factor of two by replacing a few of a hand-rolled primitives with their SIMD equivalents, but even after that neither is terribly fast and it's very easy to exhaust their limits. axfrdns is deal-breaker slow; it forks a new process for each TCP connection.
axfrdns is a confusing mis-nomer; the daemon handles all TCP DNS queries too. TinyDNS will truncate any UDP response that doesn't fit in 500 bytes (it also doesn't implement EDNS0), leaving it to be handled by axfrdns. That's about 4% of all DNS responses going on my data.
To generalize my point; DOS is a very significant risk to DNS server availability these days, and the first and best defense is to have a fast server (Knot's target of 500k qps is in the right ballpark). djbdns is single threaded, single process and doesn't even use epoll/kqueue, it's just not up to it and tops out within a few 10k qps, axfrdns won't get close to that.
https://github.com/abh/djbdns/blob/master/byte_copy.c is a good example of my earlier point too; last time I profiled tinydns it spent a lot of time in vanity routines like that; the libc implementations are factored to CPU instructions and are much better.
No disagreement with your points about Bind though.
None of these are meaningful. BIND has a long and illustrious history of coughing up shells to attackers. Any nameserver written in C and not written by Bernstein has a high hurdle to clear.
Don't drop NSD, it's a cool piece of software and folks at NLnetLabs are our friends :). My advice would be to run at least two different pieces of software in any deployment since any software can have bugs. See this very nice presentation by Anand Buddhdev from RIPE NCC about their DNS infrastructure: https://ripe68.ripe.net/presentations/284-AnandBuddhdev_RIPE...
> Are ragel parsers really 100x faster than bison parsers?
I wouldn't say that generally, but it's true for our zonefile parser. (Or maybe the bison parser we had sucked that hard :)).
> Off hand, that seems atypical and more likely the result of other changes.
Probably, but those changes came hand in hand with the change of the parser generator.
> only two usable open-source DNS servers
> The decision [to make Knot] was based on the idea that DNS protocol is one of the most important protocols of the Internet, and thus it's stability, security, and reliability would benefit from another DNS server implementation that was written from scratch with full standards compliance in mind.
Seems laudable to me.
Practically speaking, I doubt there's much difference between Knot and NSD. Why not run a few of both? :)
It's nice that they have tests. Not enough tests to back up all their claims about standards compliance and interoperability, but more tests than most of these open source hacks have, which is none.
> Not enough tests to back up all their claims about standards compliance and interoperability
As a part of each major release testing we replay a terabytes of real traffic to be sure we don't miss some bits. It's not 100% proof, but it's better than nothing, right?
I like nic.cz because they are utilising dnscurve.
But when I try to compile knot it demands a lot more resources than compiling djbdns (tinydns), or nsd. A bit too much IMO.
There is some amusing djb-phobia in this thread. Reminds me of djb-bashing from years gone by. Always good for a laugh. Time has shown the wiser.
Despite many early detractors (for reasons unknown), his software is still going strong without major flaws while the popular alternatives (who are often grubbing for consulting bucks) have suffered embarassment after embarassment because of poor design and sloppy coding. Unlike the usual bloated crapware that needs to be fixed/upgraded umpteen times (how is this ever a sign of quality?), his stuff is rarely if ever updated. Because it does not need to be. It just works. And keeps on working. In recent years it seems to me his work (crypto-focused) is now gaining more widepsread popularity. Never thought I'd see it in something like OpenSSH.
I use djb programs daily, from qmail to daemontools to ucspi to sntpclock to cdb. All very reliable. I wish there were more authors who could do what djb does. a@kx is another one I admire, but k is not open source. I think my favorite aspect of djb software is how cleanly it compiles, no matter what system I've got. His more recent packages do not even use make!
Anyway, if the guys behind knot can get it to compile as cleanly and easily as tinydns (or even nsd), I'll give it another shot. But methinks I should not need GB's of RAM or some hugh swap space to compile a simple authoritative dns server. Simplicity is paramount. To me, anyways.
I may have to get one of these Turris routers. Nice work.
> I like CZ.NIC because they are utilising dnscurve.
we don't use dnscurve nor promote it. I am sorry, but we strongly believe in standards that are widely accepted among DNS community.
> But when I try to compile knot it demands a lot more resources than compiling djbdns (tinydns), or nsd. A bit too much IMO.
I don't know how about you, but compilation is one time event per version, but reading the zones can happen very often. So the memory used to compile zone parser doesn't worry me much.
Anyway to lower the compilation resources you can just pass --disable-fastparser to ./configure invocation (that will use -T0 instead of -G2 for ragel; see 5.11 Choosing a Generated Code Style in ragel PDF documentation).
Just as a remark - it makes me very sad when you and other people hijack the discussion with djbdns and it's old feuds. I have no idea how f.e. daemontools or ucspi are related to Knot DNS (unless... you can run knotd under daemontools if you want...)
Please accept my apolgies - I was mistaken. I was thinking of dnscurve.cz and extrapolated this to conclude that nic.cz was dnscurve-friendly. But we now know this is not the case. They do not view it as being worthy of adoption as a "standard". Sad.
The benchmarks for the DNS server are very impressive. Way beyond our needs though: we're doing a few hundred million queries per month, so ~100qps. Knot handles >500k qps! We've recently switched our authoritative DNS from djbdns to gdnsd (https://github.com/blblack/gdnsd), primarily due to the GSLB features.
Lots of great stuff coming out of CZ.NIC - if you're reading this, keep it up!