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."

Comments

So how secure is it?

[modemboy]

Anyone familiar with NSD care to comment on how secure it is? Are we diversifying just for the sake of diversifying or is it as secure as BIND?

Re:Open Source

[dainkenkind]

Although it has been beaten to death here at Slashdot, and although it may be an unpopular ideology here, open source does not necessarily equal less bugs, and the converse is also true. What is definately good though, is diversity, which will make taking down all of the authoratative name servers with a single exploit much more difficult. The fact that it is not at all based on BIND code will hopefully mean that it isn't vulnerable to any of the same attacks, allowing us to resolve names all day long without worrying about having to use those nasty binary octets to connect to our favorite pr0n hosting servers.

Re:Specs on BIND Vs NSD

[Anonymous Coward]

We did quite some testing comparing responses
to millions of both real world and artificial
queries. None of the differences observed are
material enough to be noticed by common resolvers
and much less any applications or even users.

Daniel Karrenberg
daniel.karrenberg@ripe.net

Re:they should use djbdns

[jerryasher]

It sounds very similar to tinydns. Most of the slides in their presentation look as though they might have been taken from a tinydns presentation, including:

• authoritative only makes for simpler software, higher performance, increased security, more robust software
• load/reload entire db, with very fast load times, and no incremental changes at runtime
• axfr offband (it is not clear how they do this, but it sounds as though nsd is not doing this, and neither does tinydns, it can be done better with other programs (such as rsync)) IIRC, many flames have ignited over tinydns's AXFR support (or supposed lack thereof), and it seems as though the nsd developers chose a design.

One can reasonably ask, if it is so similar, why reinvent tinydns? If it's good that one root server is running nsd, why not implement tinydns on another root server? Or how does nsd differ from tinydns?

Security?

[kryps]

I have my doubts regarding the security design of nsd. Quoting from the nsd-1.0.2 distribution TODO file:

[...]
TESTS
- set all the buffer sizes to ridiculously small values see if it causes core dumps
[...]

-- kryps

Sodftware diversity not always a Good Thing

[bockman]

As it has been said in other posts, it depends on the deployment and on the attack purpose.

If the attack purpose is a DOS, software diversity helps in preventing that your whole system is killed by a single exploit. But if the attack purpose is to crack a machine on your network to run some trojan and/or spyware, software diversity only means that the attacker has more chances to find an hole.

Now, it would be different if they diversify the CPU, since most of the exploit code around is platform-dependent: keeping alive some Alphas to run some of the root DNS whould be wise from a security POV (although maybe not from other POVs).

Thinking of it, it would be nice if compilers could generate (randomly) different - but working - binary code from the same sources. You would have a single source to scrutinize for security holes, but generating different binaries on different critical machine would limit the risk of monoculture.

Re:New vulnerabilities

[raju1kabir]

Running a wider array of software on the root nameservers is still almost certainly a Good Thing , and decreases the probability than all of the servers will be prone to any given vulnerability -- but also increases the probability that a vulnerability will be found such that some subset of the servers is prone.

Unless you can argue that there is a finite number of potential vulnerabilities, and that the number is sufficiently small that they are well within the capacity of attackers to exhaustively exploit, I'm not sure how well your logic bears out. This multiplicative math only works with known/finite probabilities.

It could well be argued that there is a near-infinite supply of potential vulnerabilities, and that X cracking effort yields N holes. In this scenario it the overall chance of any single compromise doesn't increase with the diversity of products. But the susceptibility of the entire system to any given attack does decrease. That makes this change a win.

Their loss

[einhverfr]

To tell you the truth, I just don't get this.

Why are alphas not freely redistributable when the releases are redistributable under one of the most permissive licenses? Are they worried about security? If so, wouldn't a more open audit of the code before release actually help? Are they worried about subsidizing their competition? Then Why use the BSD licence? And as far as competition goes, who is the competition? BIND? DJBDNS? I doubt that DJB will copy their code-- that isn't his style, and as far as BIND, they already have the majority market share, so even if they can only get the code in the final release, they can still add the features they want and maintain market share.

The problem I see here is that this seems inconsistant with the release licenses.I don't think this is good for open source projects.