Slashdot Mirror
Root-server switches from BIND to NSD
A Sorry End writes "It appears that one of the 13 root-servers, the core of DNS name resolution, have moved away from BIND to NSD since wednesday, Feb 19th, 2003, which is a Good Thing. Since the 26th of october 1990, all root-servers have been running BIND. According to this message, this change was designed to increase the diversity of software in the root name server system, the lack of which is widely considered to be a potential vulnerability. The nsd software has been designed from scratch specifically as an authoritative name server. It has no design commonalities with bind, the currently prevalent DNS implementation.
In addition to that nsd provides a significant increase in the performance reserve of k.root-servers.net.
NSD was developed at NLnet Labs in coorperation with RIPE."
Tuus crepidae innexilis sunt.
As of last year, Verisign has been running ATLAS, instead of BIND, for DNS. See the story here.
But previously if you learned of a BIND vulnerability, you could hijack ALL of the root servers, redirecting 100% of requests to your site. Now, if there is a single vulnerability in either system the hijacking could only affect a portion of the system, not the entire internet.
An online Starcraft RPG? Only at
Online Starcraft RPG? At
Dietary fiber is like asynchronous IO-- Non-blocking!
Well, the biggest difference has got to be that the two are built for completely different purposes.
BIND is a general purpose name server for use anywhere in the hierarchical dns scheme. That is, in simplest terms, it accepts requests from below, and either serves them or passes the query up (hierarchy = tree).
NSD, according to what is being said is for *authoritative servers only*. That is, it only serves requests, it never passes them up (because it only runs at the nood nodes). It may be true that they intend to make it a general purpose name daemon in the future, but at least for right now, it just simply does not do all of the different things that bind does. One might guess that, because it does fewer things, it does them better, but I sure as hell don't know that to be the case.
:Wq
Not an editor command: Wq
In particular, it means it isn't a "fork" of BIND, either in architecture or implementation. If it were a fork, it would possibly be vulnerable to the same attacks as BIND, where they share code. The whole point of this switch is to use a nameserver that does not share those vulnerabilities. I have no doubt nsd has vulnerabilities of its own, but it's far less likely that BIND and nsd share the same vulnerabilities.
I think he meant that keeping the source closed was security through obscurity, not the fact that they are diversifying.
If you download the source tarball from the NSD site linked in the article and expand it, you'll find a DIFFERENCES document. It's a summary of observed differences between BIND 8.2.2-REL and NSD 1.0.1 written by Daniel Karrenberg at RIPE.
I'm scanning through it right now, and it looks like the main differences are:
NSD is Authoritative only. It doesn't pass requests to other servers.
NSD is quieter in the sense that if you send it a request which it refuses (like an update), it simply returns a Refused message and not the content of the update request. BIND does. This is considered a weakness in BIND that could make it susceptible to DoS attacks.
There are a number of different interpretations of the RFCs between BIND and NSD which I don't understand.
dig @server.example.com. authors.bind chaos txt
Compare results. If you get a response for both queries (including REFUSED and SERVFAIL), then it's probably BIND 9. If you get a response for the first query (including REFUSED and SERVFAIL) and not the second, then it's probably BIND-8. If you don't get a response for either query, it's probably an old version of BIND-4.9.2 (or below), or Microsoft DNS (which is based on BIND-4.9.2 or below).
The DNS system is pretty buggy... Propigation time, only a few servers... not exactly perfect... good, but not great.
I wish they would start work on a replacement. Perhaps *more* of a p2p approach among ISP's. And more rapid updating, so changes take effect faster.
I think technology on the net is so much further than DNS allows us.
It's the same thing, tinydns is a subcomponent of the djbdns package.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
:-)
I recently installed DNS on my local net for the first time (had been making do with hosts files until then). It seemed I saw a new BIND problem every week, so I thought I'd give djbdns a go, it looked pretty straight forward and I like works like "secure". It did take a full evening to install (longer that I would have hoped) and yes, that service manager thing is a ROYAL piece of annoying crap, but once it was up and running I've had exactly zero problems with it.
IMHO djb seems to write some pretty decent code, the apps themselves seem well designed, but he REALLY needs to get with the programme re: installers, and not re-inventing the wheel just because he reckons he can do it 0.001% better than everyone else (svcmgr).
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
IIRC, the large-scale attack on the root servers was a simple ping flood. Changing the software that the root servers run will not mitigate the same or a similar type of attack.
I think the internet is going to have to move to a tiered approach of trusted and untrusted networks. Unfettered access was okay when there were only a few systems connected but with millions of users, trust is something you must earn. If a network or ISP allows a user to spoof the packets they send than that network or ISP should be labeled untrustworthy and their QOS should reflect that. Legitimate users will eventually migrate to trusted nets and ISPs.
The internet should be a priveledge ala driving. If you can't be trusted with that priveledge than your access should be revoked or at least severely limited.
not re-inventing the wheel just because he reckons he can do it 0.001% better than everyone else (svcmgr).
Exactly what is svcmgr replacing that it only does things 0.0001% better than?
Phrased more simply, what exactly is there to check that service daemons are running, and starts them if they are not?
Whereas daemontools replaces init scripts, it also does the job of checking that services are still running, and starts them if they are not. It is a very useful daemon - a supervising master daemon to watch all the other daemons, because time has shown that daemons aren't very good at watching themselves.
I also don't understand your comment about having to ``learn'' daemontools. There aren't any decisions to make, and you aren't expected to read any of the daemontools documentation before using djbdns. All you have to do is install the programs so that djbdns can use them.