Securing DNS From The Roots Up

jeffy124 writes: "This article at ComputerWorld tells the story of how ICANN would like to replace the root DNS systems with secured servers. Lars-Johan Liman, one of the root operators, spoke about the concept at ICANN's annual meeting today. He discussed how the world's current redundant DNS system is vulnerable to DDOS attacks and yet-to-be-discovered root holes in bind that can ultimately undermine the entire Internet by taking away the name-IP mappings that are relied upon by just about everyone."

Comments

Re:routing != DNS

[Zeinfeld]

The bottom line is this. Don't be too worried about DNS going down. Unlike www.microsoft.com or www.whitehouse.gov, there is little incentive for a malicous script kiddie to attack DNS.

Untrue, DNS is like www.whitehouse.gov under permanent attack. The article is based on a number of assumptions that are not true of all the root servers.

Steve Bellovin is somewhat inaccurate in his statement about BIND. While it is true that most of the Root servers run code that originated in BIND most of the heavy lifting is done by a few servers that sit on the fattest pipes that run a stripped code base. The code paths of that code base have at this point been as near to completely tested as anything gets.

The real problem is that most of the root servers are still maintained by the ad-hoc volunteer network of the 1980s Internet. As a result many of the 'root servers' are hosted on drinking straws rather than pipes.

There are 13 servers however and all have to go down to take out the Internet. Even then the effect would take some time to be felt. The root servers only manage the top level domains. These tend not to change very often and so the TTL on the root records can be made very long without causing operational difficulty.

A much more serious problem would be if someone brought up a fake root server. DNS does not provide authentication.

Rather than obsess about the code base problem ICANN should be either deploying BIND or telling the IETF the characteristics of the security protocol it really needs.

Re:Why still running on BIND?

[DaSyonic]

djbdns, and other stuff written by him, (including qmail) is all under a restrictive license. He essentially prevents any vendor/distribution to release it, as any vendor would need to make minor changes, but a vendor can't even change the pathnames to certain files... that's not acceptable.

Read his license and see for yourself.

axfrdns, part of djbdns does zone transfers

[bbk]

check here:
http://cr.yp.to/djbdns/axfrdns.html

this supports outgoing transfers. Incoming are a possible security risk (NO authentication happens in most cases, other than IP address checking, IIRC), making this a prudent decision, IETF or no.

BBK

Re:Why still running on BIND?

[Tet]

Why does everyone thing DNS zone's must be contained in flat text files? I would like to see a nice SQL backed system.

What on earth for? SQL is a general purpose query language designed to maximize flexibility over performance. SQL lets you do all sorts of complex nested subqueries and joins which simply aren't needed for DNS, so why have the overhead? It all comes down to using the right tool for the job. And in this case, a fast non-SQL database (such as Berkeley DB, for example) is far more suited to the job. Too many people equate the term "database" with "SQL", when that's just one of the options. Often it's the right choice, but sometimes it isn't, and this is one of those times.

Re:Why still running on BIND?

[shub]

Uh, yeah. Right. The first of what I'm sure will be many people to recommend djbdns. I've got a long list of reasons why djbdns is inherently bad, and I'll share some of them with you:

• By default, tinydns does not hand out referrals to questions it is asked about zones it does not control. I believe that this violates the spirt of the RFCs, if not the letter.
• By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt of the RFCs, as well as the letter (if a DNS query via UDP results in truncation, you're supposed to re-do the query using TCP instead).
  Indeed, if you want to support TCP under tinydns, you have to configure an optional program called "axfrdns", which was intended to handle zone transfers, but also happens to share the same database as tinydns, and can handle generic TCP queries.
• The suggested method for copying contents of DNS zones is rsync, scp, or other remote copy tools. The DNS standard method of zone transfers (query type "axfr") is only supported as an additional, disrecommended method.
  The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed. Contrariwise, if you use the standard zone transfer mechanism, then the zone transfer should fail if the master is munged, and the slaves should keep a good working copy for a while and give you time to notice that the master is munged and needs to be fixed.
• Without a patch from a third party, tinydns does not listen to more than one IP address. If you have a multi-homed server, you have to apply a patch from someone other than they author, before you can get it to listen on more than one address/interface.
• Without a patch from a third party, tinydns does not support the standard "NOTIFY" protocol of informing secondary nameservers that the zone has been updated, and that they need to check the SOA serial number and download a new copy (if they don't already have it).
• Without a third party patch, tinydns does not support standard SRV records (which are intended to ultimately replace MX records, as well as perform similar functions for services other than mail).
• Like tinydns, dnscache will not bind to more than one IP address without a third party patch.
• Because they are separate programs, you can't have both tinydns and dnscache listening to the same IP address(es) on the same server.
  While this is not the recommended mode of configuration, some sites don't have the luxury of having separate authoritative-only and caching/recursive-only server(s), and need to mix them both on one machine (or set of machines). With the BIND 9 "view" mechanism, this is relatively easy to do. With djbdns, this is impossible.
• There aren't even any patches that can get djbdns to implement TSIG, Dynamic DNS, or DNSSEC, nor are they ever likely to be created (my understanding is that the author is strongly opposed to them).
  Unfortunately, as time goes on and more and more people are doing things like IPv6, VPNs based on IPSec, or people just care about being able to cryptographically prove that their servers are handing out the only correct information and that the clients are able to cryptographically verify this fact (think: electronic banking), these kinds of features are going to become ever more commonplace.
  Note that, with the advent of BIND 9, you can create a caching-only server that will validate cryptographically signed records, and all clients can benefit even if they do not themselves implement any of the new DNSSEC features.
• There are a number of things that djbdns does which I believe to be outright bugs. However, the author of this package simply refuses to accept that his code could be anything less than 100% perfect, and while he claims to have a "bounty" that he will pay for any bug that is found, in reality he is the one that gets to define what he accepts as a "bug", and has repeatedly demonstrated a tendancy to openly refuse to accept some purported bug, but then to quietly fix the code with future releases.
  So, let's look at some of these bugs:
  • When an IQUERY is sent to a djbdns server, it will respond with opcode set to QUERY. (it should simply copy the opcode, not make something up).
  • DNSCACHE (the caching server) does not respond to queries with the RD bit clear in the query. (Instead of simply answering from cache without recursing the dns-tree).
• One argument frequently used to support the use of djbdns over BIND is performance. Upon further investigation, this claim simply does not hold water.
  Benchmarks published by Rick Jones have clearly shown that BIND can scale up to at least 12,000 DNS queries per second, and there is every indication that BIND 9.2 will be able to go considerably higher. The best benchmarks available for tinydns indicate that it can handle at least 500 queries per second, but that is the highest number reported. Other people on the bind-users mailing list have indicated that they have performed their own (as yet unpublished) benchmarks of tinydns, and that it had notable performance problems that BIND did not suffer.
  The best published benchmarks from the author for dnscache report a query handling rate of less than one million records over a 4.5 hour period of time, which works out to an average of less than sixty-two queries per second. Even if you look at numbers of queries per CPU second, the best numbers they can provide are 13.7 million queries over a four week period of time with 128 minutes of CPU time used (an average of slightly less than 1784 queries per CPU second).
  Compare this with the requirement from RFC 2010 "Operational Criteriafor Root Name Servers" (since obsoleted by RFC 2870 "Root Name Server Operational Requirements") is that the machine and software in question be able to handle at least 2000 queries per second, and be scalable to levels higher than that. Indeed, recent reports have indicated that a.root-servers.net (considered by many to be the "primary" root nameserver) is currently handling around 12,000 DNS queries per second at peak.
  Preliminary benchmarks published on the bind-users mailing list have indicated that, on the same hardware, there is little or no performance benefit to using dnscache as opposed to BIND 9.1.2, and when these tests are re-run with BIND 9.2, I'm sure that it will come out even faster.
• Unfortunately, a lot of the reasons the author gives for running djbdns instead of BIND are related to problems in older versions of BIND which have been fixed or are largely non-issues in later releases of BIND 9.
  For example, he makes a big point of tinydns being better than BIND, because while the process is starting up, it still answers queries. While previous versions of BIND would not answer queries during startup, this is no longer a problem with BIND 9.
  Dan also makes a great deal of the fact that the djbdns tools run as a user other than root, and in chroot() environments. While the "monolithic setuid root" situation was an issue with older versions of BIND, even more recent releases of BIND 8 could be easily run as a non-priviledged user in a chroot() environment, and this is the preferred method of running BIND 9.
  Contrariwise, one of the legitimate big complaints about older versions of BIND is that they implemented zone transfers in a separate program. If the database was large, then the fork()/exec() overhead was large, and the system could seriously thrash itself to death as it copied all those pages (for systems without copy-on-write), only to immediately throw them away again when it fired up the named-xfer program. With BIND 9, this problem is solved by having a separate thread inside the server handling zone transfers, and no fork()/exec() is done. However, tinydns/axfrdns goes back to the fork()/exec() model that was so greatly despised.

And this doesn't even begin to get to the more core philosophical issues that Dan gives for running djbdns instead of BIND. I can easily rip him apart in these areas as well, but this takes more space than I think that I should devote here.

Suffice it to say that there is absolutely nothing that djbdns does that I believe can't be done at least as well (or considerably better) with BIND, and there are no security benefits it provides that cannot be provided at least as well (or much better) by a proper installation of a modern version of BIND.

I believe in the "security through diversity" scheme as much as anyone, but I'd take root nameservers running a program written in Bourne shell over djbdns. Hell, I'd rather fall back to using HOSTS.TXT than use djbdns.

Unfortunately, the other alternative of DENTS is also unsuitable for use as a production nameserver.

Show me something that is sufficiently better than BIND (and open source), and I'm sure that everyone will quickly gravitate towards it. Until then, BIND is the best we've got.