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:So how secure is it?

[Anonymous Coward]

Because BIND is a rock of stability.

Re:So how secure is it?

[johnnyb]

Diversifying for the sake of diversifying is still useful. If person A finds a flaw in one of the two systems, the rest are still functioning. This requires an attacker to have exploits for all systems, not just one. The diversity itself is a barrier.

Re:So how secure is it?

[caluml]

Well, I can only speak from personal experience, ratheer than just listening to people who say it's insecure.

I've never had any security problems with it. Chrooted, and running as a non root user helps. Funny how once something gets a reputation, it never seems to be able to shake it off.

Open Source

[Greedo]

From their site:

NSD is an authoratative only, high performance, simple and open source name server.

But further down:

The betas and releases of NSD are distributed under freeware BSD license, however we require the alpha testers to:

• test the software within reasonable timeframe
• provide NLnet Labs with feedback and bug reports in a timely manner
• not disclose the source to any third party without NLnet Labs concent [sic]
• destroy obsolete versions of the alpha code on request

So, I'm wondering, when this comes out of beta, will it still be open source? Running diverse software on the roots is probably a Good Thing, but security through obscurity isn't, so I hope they aren't trading one kind of vulnerability for another.

Re:Open Source

[gmuslera]

You said that... "betas AND releases" are under BSD license.

Re:Open Source

[copterdoc]

You can find the source here:
http://www.nlnetlabs.nl/nsd/index.html

Re:Open Source

[Anonymous Coward]

nsd will remain open source.

Daniel Karrenberg
daniel.karrenberg@ripe.net

Re:Open Source

[babbage]

Running diverse software on the roots is probably a Good Thing, but security through obscurity isn't

Man this is such a false meme, where did it get started? Obscurity by itself is questionable security, but as a component of a multi-layered security strategy it's perfectly reasonable.

• Security by obscurity is your world-readable /etc/passwd file, with the password data either hashed (obscured) or moved to the shadow file (also obscured). (And if your shadow password file isn't world readable, that's just more obscurity.)

• Security by obscurity is the fact that most people don't have the names & addresses of the personnel running the US military's nuclear weapons systems so that these people can't be blackmailed. Maybe these people can be trusted not to betray their country under torture and such, but keeping their identities non-public -- an obscurity measure -- is important too.

• Security by obscurity is Dick Cheney's "undisclosed location" (*cough* Greenbrier Resort, White Sulphur Springs, West Virginia)

• Security by obscurity is restricting access to your company's co-location facility, so that untrusted people can't get physical access to your equipment.

In short, in a broad sense, "security by obscurity" is a lot of good ideas, when you think about it. Any of these ideas can be an Achilles heel, but the solution there is not to cut off the heel altogether, but to wear sensible shoes when going out in the wilderness :)

To get back to the original topic, obscurity is a perfectly good tactic for the people running these DNS servers as part of their overall strategy for protecting the system. It's perfectly reasonable for certain aspects of their systems, processes, etc to be kept on a need to know basis. Sure, there is a benefit to keeping software source open as a security measure, though the benefit of doing that is debatable (and no, I'm not going to be the one to debate it -- I agree that it's generally a good idea but can understand some of the objections). But in this case, where the software is a black box to the outside world, and it's explicitly *not* meant for general DNS use (it's meant for authoritative servers only!) I don't see any particular harm in keeping their doors locked down pretty well.

Not that they're doing that in the first place. As another reply noted, you yourself write that both the betas & release will be available under a BSD style license :-)

But moreover, your objections are I think misplaced -- as are most of the people that blindly parrot the "obscurity is bad" meme. Think about what you're saying -- it really doesn't hold up to scrutiny.

Just like biological ecosystems

[hpulley]

Having no diversity means you are ripe for an epidemic.

Verisign using ATLAS, not BIND

[GeorgeK]

As of last year, Verisign has been running ATLAS, instead of BIND, for DNS. See the story here.

Re:Verisign using ATLAS, not BIND

[Greedo]

VeriSign is replacing an open source software package called Berkeley Internet Name Domain (BIND) with its own proprietary technology. Dubbed ATLAS, for Advanced Transaction Look-up and Signaling, VeriSign's proprietary software will be installed in its 13 DNS server sites around the globe this summer and will go into production mode in the fall.
Well, I guess one of those 13 server sites (I assume they mean the roots) isn't running ATLAS now, is it?

And again with the proprietary software! Verisign has a bad enough reputation already. Now they expect us to trust the security of their closed software ... great.

Re:Verisign using ATLAS, not BIND

[Matty_]

The server which is getting the new software is k.root-servers.net, which is managed by RIPE in London, UK. It handles DNS for the "." (root) domain.

Verisign does not run this server, but they do have their own DNS servers which handle DNS for TLD's such as "com" and "net" -- and is totally seperate from the root servers. I am sure all of those systems are still running ATLAS.

(Of course, if I recall correctly, VeriSign does manage one of the 13 root servers. I think it is a.root-servers.net, but I may be wrong.)

Diying?

[ricbasto]

I don't think the plan is to migrate away from BIND, but instead to protect the root-servers from a bind-specific exploit.
There will be years for BIND to loose it's marketshare.

Specs on BIND Vs NSD

[phorm]

If a lot of /.'ers are like me, then there are probably a lot of people who don't know the technical differences between BIND and NSD. Can somebody whack us with the proverbial cluestick as to the improvements of NSD over BIND (exempting of course, the mentioned fact that NSD was built from scratch).

I wonder what anomalies, if any, we may see from switching over. Also, as the article mentions that NSD has no design commonalities with BIND, I wonder how many of the tech personnel are knowledgable on the new system...not that a nameserver, even a root one, should be overtly complicated (except for evading DOS attacks)

Re:Specs on BIND Vs NSD

[etcshadow]

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.

Re:Specs on BIND Vs NSD

[Anonymous Coward]

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.

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

Same interface, different implementation

[$$$$$exyGal]

It has no design commonalities with bind...

This is great, but I wanted to point out that the new software does have design commonalities with bind. The way I see it, they both support the same external interface, but they have different implementations.

--sex

Re:New vulnerabilities

[cmburns69]

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

they should use djbdns

[Anonymous Coward]

Really, look at all the advantages of djbdns:

* free software, under the BSD license (makes it easy to redistribute binaries)

* easy package-based installer (easy to find everything, or to install djbdns in different locations)

* easy to configure with a single config file

* great support from the author, who's a really friendly guy.

Oh wait. NONE OF THAT IS TRUE. Never mind.

Re:they should use djbdns

[bourne]

Oh wait. NONE OF THAT IS TRUE. Never mind.

You're absolutely right. djbdns doesn't have anything going for it except exceptional security and performance, and why would a root name server need that?

Re:they should use djbdns

[radish]

:-)

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

Re:they should use djbdns

[blakestah]

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.

affirmative action

[Bull999999]

What they didn't tell you was that the move was mostly due to affirmative action, to ensure diversity on the Internet. Why do you think that IIS is still hanging around?

Affirmative action: More than just for humans.

Re:Similar

[Joseph Vigneau]

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.

Back to switchboards

[binaryDigit]

I think they should replace the root dns servers with an old fashion switchboard. I envision a large room in the bowels of VeriSign "manned" by an army of women wearing grey suits with horn rimmed glasses. A dns request will come in via pnuematic tube, the operator will pull one spring loaded ethernet cable from her console and plug it into the correct corresponding jack.

While being resistant to any port based DDOS attacks, they would be DOSable by having some hunky dude drink a pepsi outside their window.

Re:New vulnerabilities

[cduffy]

The argument isn't specific to NSD, but rather general to all cases where a wider array of software is deployed to avoid a monoculture for security reasons: In places where previously BIND needed to be compromised to affect an attack, now either BIND *or* NSD may be compromised. That's not to say that such an attack is necessarily easy with NSD, or that it has known vulnerabilities -- simply that *if* a vulnerability is discovered in one of *two* packages, this can be translated into such a larger attack (rather than having only a single point of vulnerability).

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.

Diversity is good

[MojoRilla]

Competition is a good thing. See Intel vs. AMD, Sony vs. Nintendo, Linux vs. Microsoft.

For very high reliability software, competition is also used. For example, the space shuttle uses four sets of identical software on four sets of hardware that vote on results, with a fifth set running completely different software waiting to take over if the other fail (see Fastcompany for more details).

Also, one of the benefits of breaking up Ma Bell was that one company, with one set of software, was no longer running the telephone system in the United States.

In the long run I think this is a very good thing. In the short run, however, there might be problems.

Acronyms galore

[ruiner13]

Wow, all those acronyms are making my head spin. Sigh. What does the NSA think about the DNS servers switching from BIND to SND? Does it make thier TPS reports PDQ? I'd sure hope it uses SQL somehow too.

Security through _______

[Neillparatzo]

Isn't it bad luck to have 13 root servers?

I mean if you're going to be superstitious to the point of worrying about code diversity or eyeballs-per-source-file, I think this is an issue that needs to be addressed.

Only...

[devphil]

...if the 14th is named bilbo.root-servers.net, and is added specifically for the purpose of breaking the bad luck.

Sorry, heavy geek moment there.

Waste of effort

[iamacat]

One bad thing is that NSD is only for authoratitive name servers, so the efforts spent developing, debugging, porting and optimizing its code will be wasted for most of us. More people using NSD would also mean that any security exploits are discovered faster and on less important systems than root name servers. And couldn't we all use a lightweight, secure, chaching name server to use over a dialup connection?

I would rather see them pick some alternative general purpose DNS implementation and optimize it for their needs.

Exactly!

[sterno]

I mean look at Windows. It's had this long reputation of being insecure, so naturally everybody assumes it still is. When really it's... oh... nevermiond.