5 ms·

Knot DNS: A high-performance, authoritative DNS server

85 points by oerdnj 12y ago

ck2 12y ago
Still a big fan of maradns if you need something simple and fast. And Deadwood if you just need a resolver cache.
- qewrffewqwfqew 12y ago
  glad to see I'm not the only maradns fan around :-)
- oerdnj 12y ago
  No EDNS0 (with DNS-over-TCP defaulting to off), no DNSSEC? This is very very sad reading. But hey, if it works for you, then no worries :).
tptacek 12y ago
I just install djbdns everywhere. I have more confidence in djbdns not coughing up a shell on my machines than any other server. DNSSEC, by the way, is a bug and not a feature.
- colmmacc 12y ago
  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.
  - tptacek 12y ago
    What situation are you in where you need high-volume AXFR?!
    - colmmacc 12y ago
      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. And with apologies for the domain name; http://dnsneedsfuckingtcp.info/ http://dnsneedsfuckingtcp.info/ . 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 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.
- astrodust 12y ago
  How maintained is that? qmail is in an awful state, and djbdns hasn't been updated in relative millennia. Being secure is a notable achievement, but that shouldn't completely hold up iterative improvements.
  - tptacek 12y ago
    I'm just happy to be keeping software written during the age of the Plantagenets alive. Who knew Daniel Bernstein had such longevity?
- ck2 12y ago
  But djbdns has had security issues in the past? http://maradns.samiam.org/DNS.security.comparison.txt http://maradns.samiam.org/DNS.security.comparison.txt
  - tptacek 12y ago
    Nope.
    - ck2 12y ago
      Am I missing something? http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1191 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1191 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0858 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0858 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4392 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4392 It just has the fewest. But they still popup from time to time.
      - tedunangst 12y ago
        dnscache is not the authoritative server. The link in your previous comment even mentioned this explicitly.
      - tptacek 12y ago
        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.
- andmarios 12y ago
  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.
  - pflanze 12y ago
    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.
    - pyvpx 12y ago
      there is at least one person who is interested :-)
      - pflanze 12y ago
        Ok, I'll publish it as soon as I can at https://github.com/pflanze/tinydns-scm https://github.com/pflanze/tinydns-scm 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".
samcrawford 12y ago
The authors of this are CZ.NIC (whose website is confusingly http://nic.cz http://nic.cz). They're the same people behind the thoroughly awesome Turris Router (https://www.turris.cz/en/ 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 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!
- AceJohnny2 12y ago
  re: Turris Router 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?
  - ynezz 12y ago
    Yes, it's http://www.unex.com.tw/product/dnxa-h1 http://www.unex.com.tw/product/dnxa-h1
- Florin_Andrei 12y ago
  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. Anything to keep in mind when using it?
  - samcrawford 12y ago
    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.
tedunangst 12y ago
Two unrelated questions. Why would I prefer this over NSD? Are ragel parsers really 100x faster than bison parsers? Off hand, that seems atypical and more likely the result of other changes.
- scott_karana 12y ago
  > Why would I prefer this over NSD? That was also my question before I read this. From the article: > 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? :)
- oerdnj 12y ago
  > Why would I prefer this over NSD? 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_RIPE68_DNS_Update.pdf 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.
thrownaway2424 12y ago
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.
- oerdnj 12y ago
  > It's nice that they have tests. Thank you. > 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?
jingo 12y ago
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.
- Panino 12y ago
  I like nic.cz because they are utilising dnscurve. Unless I misunderstand you, unfortunately this is not the case. A quick way to check if a domain supports authoritative DNSCurve service is to do e.g. $ dig +short ns dnscurve.org You'll see labels that begin with the magic string "uz5" followed by a Base-32 encoding of a Curve25519 public key. Unless you meant something else? I agree with your post though. I also use tinydns, but with CurveDNS for DNSCurve support in front. They just work!
  - jingo 12y ago
    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.

85 points by oerdnj 12y ago

ck2 12y ago

Still a big fan of maradns if you need something simple and fast. And Deadwood if you just need a resolver cache.

qewrffewqwfqew 12y ago
glad to see I'm not the only maradns fan around :-)
oerdnj 12y ago
No EDNS0 (with DNS-over-TCP defaulting to off), no DNSSEC? This is very very sad reading. But hey, if it works for you, then no worries :).

tptacek 12y ago

I just install djbdns everywhere. I have more confidence in djbdns not coughing up a shell on my machines than any other server. DNSSEC, by the way, is a bug and not a feature.

colmmacc 12y ago
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.
- tptacek 12y ago
  What situation are you in where you need high-volume AXFR?!
  - colmmacc 12y ago
    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. And with apologies for the domain name; http://dnsneedsfuckingtcp.info/ http://dnsneedsfuckingtcp.info/ . 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 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.
astrodust 12y ago
How maintained is that? qmail is in an awful state, and djbdns hasn't been updated in relative millennia. Being secure is a notable achievement, but that shouldn't completely hold up iterative improvements.
- tptacek 12y ago
  I'm just happy to be keeping software written during the age of the Plantagenets alive. Who knew Daniel Bernstein had such longevity?
ck2 12y ago
But djbdns has had security issues in the past? http://maradns.samiam.org/DNS.security.comparison.txt http://maradns.samiam.org/DNS.security.comparison.txt
- tptacek 12y ago
  Nope.
  - ck2 12y ago
    Am I missing something? http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1191 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1191 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0858 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0858 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4392 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4392 It just has the fewest. But they still popup from time to time.
    - tedunangst 12y ago
      dnscache is not the authoritative server. The link in your previous comment even mentioned this explicitly.
    - tptacek 12y ago
      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.
andmarios 12y ago
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.
- pflanze 12y ago
  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.
  - pyvpx 12y ago
    there is at least one person who is interested :-)
    - pflanze 12y ago
      Ok, I'll publish it as soon as I can at https://github.com/pflanze/tinydns-scm https://github.com/pflanze/tinydns-scm 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".

samcrawford 12y ago

The authors of this are CZ.NIC (whose website is confusingly http://nic.cz http://nic.cz). They're the same people behind the thoroughly awesome Turris Router (https://www.turris.cz/en/ 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 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!

AceJohnny2 12y ago
re: Turris Router 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?
- ynezz 12y ago
  Yes, it's http://www.unex.com.tw/product/dnxa-h1 http://www.unex.com.tw/product/dnxa-h1
Florin_Andrei 12y ago
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. Anything to keep in mind when using it?
- samcrawford 12y ago
  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.

tedunangst 12y ago

Two unrelated questions. Why would I prefer this over NSD? Are ragel parsers really 100x faster than bison parsers? Off hand, that seems atypical and more likely the result of other changes.

scott_karana 12y ago
> Why would I prefer this over NSD? That was also my question before I read this. From the article: > 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? :)
oerdnj 12y ago
> Why would I prefer this over NSD? 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_RIPE68_DNS_Update.pdf 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.

thrownaway2424 12y ago

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.

oerdnj 12y ago
> It's nice that they have tests. Thank you. > 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?

jingo 12y ago

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.

Panino 12y ago
I like nic.cz because they are utilising dnscurve. Unless I misunderstand you, unfortunately this is not the case. A quick way to check if a domain supports authoritative DNSCurve service is to do e.g. $ dig +short ns dnscurve.org You'll see labels that begin with the magic string "uz5" followed by a Base-32 encoding of a Curve25519 public key. Unless you meant something else? I agree with your post though. I also use tinydns, but with CurveDNS for DNSCurve support in front. They just work!
- jingo 12y ago
  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.