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

Hehe

[zapfie]

Well.. I guess they're not in a BIND anymore!

...god, that was the worst joke ever. Someone shoot me.

Re:Hehe

[DonkeyJimmy]

...god, that was the worst joke ever. Someone shoot me.

I would shoot you, but I can't find you because your name isn't resolving for some reason.

Re:Hehe

[teamhasnoi]

However, the admins of the new servers seem to have NSD cold.

I may have taken that bullet for you...

Diversity?

[Anonymous Coward]

Man, my company would be majorly pissed off. We don't want diversity, we want conformity!! All systems should be running one OS for ease of administration and that OS should be Windows2000. Thankfully I'm offsite and use Linux. ;-)

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?

[b!arg]

Diversifying for the sake of diversifying is good in this sense. Let's think back to 7th grade biology and natural selection. If the genetic makeup of all animals of a species was the same, then one disease could kill off the entire species. But the diversity of the genetic code makes it possible for the species to survive that traumatic event. Some animals will get killed off, but others that have a way to fight it, won't. Now replace "genetic code" with "OS", "disease" with "hacker" and "species" with "network" and you've got yourself a concept.

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.

Re:So how secure is it?

[N3WBI3]

Actually no you are creating multiple POF's not just having one POF which I dont care how *many* systems youre running having them all run the same software is creating just that, no matter how good the software is..

Re:So how secure is it?

[wesmo]

That's a bogus argument. Diversifying for the sense of being diverse is just a rephrasing of "Security Through Obscurity".

It is not security. If anything, it represents another vulnerability. Rather than maintaining a single system (ease of administration is a strong point of security unto itself), now multiple system implementations are in place.

Sure, if someone wanted to take down ALL of the root name servers, chances are that if they could hack in to one, they could hack in to them all if they are all running the same DNS server software. However, that is usually not the case.. the real hit is when someone hacks in to A DNS server.

Another brand of software is in no means a security benefit. You have now doubled the requirements for a secure environment: both vendors now must be equally as secure.

A classic case of the failure of the axiom: benefits outweighing the costs (and efforts)

Essentially, the administrative workload has been doubled and the potential for exposure through hacking has doubled (you have doubled your software base) for the benefit of "security through obscurity".

Bah.. what a waste of time.

Re:So how secure is it?

[Random Frequency]

anything that has had a history of being insecure will continue to have a history of being insecure as long as new functionality is added.

Re:So how secure is it?

[kasperd]

Another brand of software is in no means a security benefit. You have now doubled the requirements for a secure environment: both vendors now must be equally as secure.

Now you are assuming that for the system as a whole to be secure, each part has to be secure. However that is not how secure systems are designed. Though DNS is really not designed with much security in mind, so it may all fail due to weaknesses in design. Had the design been secure multiple implementations would be an advantage. The best you can do right now to protect yourself from false results from a cracked root DNS server is to ask more than one, but that of course does not help against DoS attacks. And of course always use secure protocols like ssh and https on top of IP+UDP+TCP+DNS.

Re:So how secure is it?

[johnnyb]

' That's a bogus argument. Diversifying for the sense of being diverse is just a rephrasing of "Security Through Obscurity".'

You misunderstand the problem of "security through obscurity". The phrase "security through obscurity" does not mean to say that obscurity is useless - in fact, it is a very important part of computer defence. What it means is that obscurity should not be confused with security. They are orthogonal. If I have an obscure system on the other side of the firewall, it will take a hacker longer to figure his way around, thus giving me extra time to detect him. This shouldn't be done to _replace_ security, but is a definite complement to security.

Re:So how secure is it?

[jericho4.0]

No it's not. Do you want your car keys, house key, and work keys to all be the same key? Probably not, because if it was comprimised, you'ld be screwed.

For the same reason, no one with any security sense uses the same password on every account.

Re:So how secure is it?

[Alex]

Because BIND is a rock of stability.

Why is this modded as funny? Its true.

If the guy had said security it would have been funny, but it is very very stable.

Alex

Re:So how secure is it?

[Bert64]

"As secure as bind" is hardly an ideal to live up to, bind has probably had more remote-root vulnerabilities than any other application.. and as a consequence is obviously poorly coded. Whats more, its widespread use has meant that whenever a remote root vulnerability is discovered, exploits are quickly written and distributed to blackhats... and thousands of servers became compromised every time, and each time people installed the so-called "secure" patch... only to be at risk again the next time a flaw was found.
Any alternative to the bind monoculture is good, the idea of the next flaw in bind bringing the entire dns system crashing down doesn't sit well with me.
And no talk of chroot... its ofcourse possible to break chroot, and whats more, crashed dns servers are almost as bad as rooted ones, and its still possible to hijack the bind process instead of exploiting it to execute a shell... you could cause it to serve bogus data or such.

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

[modemboy]

I think you answered you own question
"The betas and releases of NSD are distributed under freeware BSD license"

it says "and releases"

It sounds like just the alpha versions are closed.

Re:Open Source

[gmuslera]

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

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:Open Source

[arvindn]

(slightly OT)

You brought up a very good point. "Open source" which you're not allowed to disclose.

Which is why RMS asks us to distinguish between Free as in freedom and open source as in buzzword compatible.

IMHO, what the license restriction probably shows is that deep down, they really believe that less eyes on the source == better. They probably want to achieve some kind of "middle ground" (shared source anyone?) with bug fixers getting to look at the code but not "hackers".

Not to be too harsh, just bitter that they follow the letter but not the spirit of open source.

Re:Open Source

[copterdoc]

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

Re:Open Source

[bn557]

which makes sense. If I'm trying to implement the core of a product that I intend on finishing in my lifetime, I don't want a million people e-mailing me telling me that this part should be handle that way and that part should be handled this way. Once it reaches Beta and Release stage, it's already implemented and now it's just bug fixes. At that point, make it open source and let somone else do all the rewrites while you finalize the initial release.

P

Re:Open Source

[Anonymous Coward]

nsd will remain open source.

Daniel Karrenberg
daniel.karrenberg@ripe.net

Re:Open Source

[Tony-A]

I 'spect that they're trying to insure that any bugs in the alpha version do not get a chance to live on in stale copies or in somebody else's code. Makes sense that they would want as few bugs as possible with their name on them.

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.

Re:Open Source

[dan g]

In your argument you've considerably broadened the definitions of both security and obscurity beyond how they are generally used in this context. Amongst other things, according to your logic any sort of encryption at all is 'security through obscurity' because technically the information is obscured. That is clearly absurd and not the intent of the phrase.

Note that I happen to agree than in some cases obscurity can be a reasonable additional layer of security, but the the essence of your point is, dare I say it, obscured by your changes in definition.

Re:Open Source

[babbage]

What can I say, it doesn't take much to reduce an already absurd slogan to more obvious absurdity :-)

My real point, which I think you're well aware of, is that pat, convenient slogans like this are often too simplistic, and there's a danger that by taking them to heart you're taking away the wrong lesson.

By broadening the definition, my hope is that people will think a little more about parroting things like this and consider that, in this case, security by obscurity *isn't* per se a bad thing. It has a place, a role, and proper ways to apply it. Having it as the first & only line of defence usually isn't one of the proper ways, but as part of a balanced security plan it can fit in very effectively.

Re:Open Source

[iabervon]

If you look at the terms of the license, it becomes clear that they want to limit the spread of broken, unreleased versions; they'd like anything that's going to continue running (and therefore be attackable) to have at least completed testing successfully.

This is an effort to have effective open source QA, not an attempt to limit the eyes on the code; the only source that's restricted is source that, once testing is complete, nobody will be running.

I think it's reasonable to have a middle ground between the totally private contents of my unsaved emacs buffers and the released version of the source in the tarballs in the archive. This includes my mode 755 working directory on a company-wide NFS server and the copies I send to someone who tests on PPC. Open source requires that once I'm providing the code *to a user* *for use*, the user then has the necessary freedoms.

Re:Open Source

[Zeinfeld]

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.

This has nothing to do with security through obscurity. More harm is being done by people inanely prattling 'security through obscurity' these days than by people actually practicing it.

A case in point here, when I started arguing for shaddow passwords in UNIX more than ten years ago people objected because it was 'security through obscurity', took three years of argument and soe folks writing crack to hammer the idea into some very thick skulls that the Morris architecture was vulnerable to a dictionary attack.

In this case the iea of forcing people to stop using alpha code is a pretty good one. I recomend it because it simplifies mainenance greatly.

Remember the early days of the Web when Netscape would release a fresh alpha release on a monthly basis? That was a nightmare, features appeared, dissappeared, reappeared depending on who got their act together. After a while they got a clue and would put drop dead dates in the non production releases.

Re:Open Source

[xA40D]

I think the term "security through obscurity" is perfectly valid, and not at all absurd. It indicates a mindset that suggests being shady is all it takes to make you secure.

For instance not putting signs on the NOC so it can't be found. Then letting any fool wander in. That's security through obscurity.

Whereas not putting signs on the NOC so it can't be found. Then making people jump through hoops before you'll open the door. That would be security WITH obscurity.

Far too often the suits (and, indeed, some techies I work with) seem to think being obscure is sufficient. The slogan "security through obscurity is no security" helps make the job of convincing such fools marginally easier.

New vulnerabilities

[crow]

So previously, a vulnerability in one piece of software would allow the whole system to crash or otherwise be compromised. Now a vulnerability in one of two pieces of software will allow part of the system to be compromised. If the only risk were lack of service, this would be a good thing. However, the risk also includes providing malicious service. I could see some people wanting to redirect all DNS querries so that the result would point to some site of questionable virtue. Doing so may have just been made easier.

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

Re:New vulnerabilities

[binaryDigit]

Doing so may have just been made easier.

How is going to a different dns server make this easier now? Are you saying that NSD somehow makes this easier? Is this a known vulnerability in NSD?

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.

Re:New vulnerabilities

[Elwood P Dowd]

But previously if you learned of a BIND vulnerability, you could hijack ALL of the root servers, redirecting 100% of requests to your site.

I'm not sure that is exactly the attack everyone is concerned about. More likely they'd point the firehose at, you know, someone else's site... I'll leave it to the trolls to suggest which sites.

Re:New vulnerabilities

[jasonflacid]

We can make every dns lookup to go slashdot.org. Then we can slashdot slashdot.

Re:New vulnerabilities

[Eravau]

Does it really increase the probablility of finding a vulnerability? The efforts of those seeking vulnerabilities will be divided between the two servers instead of concentrated on one. So their overall vulnerability finding pace should be about the same I would think. It's just become a 50/50 chance on where they'll find a vulnerability next, instead of a 100% assurance that the next vulnerability will be found in BIND.

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.

Re:New vulnerabilities

[sangdrax]

so which OS-es do they run? since one would expect diversity there as well then..

Re:New vulnerabilities

[cduffy]

I am inclined to argue that there is a finite number of vulnerabilities, and that the number of them which are reasonably and profitably located and exploited is particularly limited.

Simply put: The set of possible inputs to a block of code (excluding cases where input lengths are unbounded -- something DNS software should never allow) is finite; hence, there is a finite set of correctly-handled cases, a finite set of error cases which are gracefully handled, and a finite set of error cases which are incorrectly handled. That last set can indeed be located, and if the expense is warranted can even be eliminated and proven to be so.

As for the argument that the supply of potential vulnerabilities is near-infinite, I am disinclined to believe this so long as certain reasonable assumptions regarding the operating environment can be made. If you care to put forth an argument, however, by all means feel free to do so.

Re:New vulnerabilities

[cduffy]

Not necessarily -- folks looking for vulnerabilities do so for different reasons; many of the folks working on finding vulnerabilities in IIS have little interest in finding vulnerabilities in Apache, and the contrary is so as well. Indeed, most of those looking for holes in BIND are likely not to be doing so with any intent of cracking the root nameservers, whereas those investigating NSD are more likely to have that as their intent (being that, as an authoritative-only nameservers, it has little function otherwise).

It could also be argued that some who would be attacking BIND anyhow might additionally put forth some effort on NSD due to its novelty.

Re:New vulnerabilities

[raju1kabir]

I am inclined to argue that there is a finite number of vulnerabilities, and that the number of them which are reasonably and profitably located and exploited is particularly limited.

If that's the case, the two of us should stop wasting time posting on Slashdot and just quickly fix them all.

Re:New vulnerabilities

[cduffy]

If that's the case, the two of us should stop wasting time posting on Slashdot and just quickly fix them all.

Quite a strawman, there!

I never said that these exploits were easy to find, nor that fixing "them all" for every (or even any) nontrivial piece of software would even approach being a 2-man job -- simply that the number of mishandled error states in any piece of software having an upper bounds on input length is limited, and can with sufficient effort such states can be eliminated. It's still a nontrivial task, and requires a software development process much more rigid and controlled than merely hacking together code that covers all the common cases (which is, frankly, what I usually do).

Please, don't put words in my mouth -- but nonetheless, I hold to my prior statement: Any given piece of code has only a limited set of exploitable bugs, and that these can in practice be located and eliminated, given sufficient effort.

Just like biological ecosystems

[hpulley]

Having no diversity means you are ripe for an epidemic.

Re:Just like biological ecosystems

[Abcd1234]

Sounds like current world Banana crops, which are genetically identical, for all intents and purposes (since they are reproduced asexually). Already there is fear of a disease which will wipe out world banana production. Fun stuff!

Yes, this is OT, and I like it!

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

Re:Verisign using ATLAS, not BIND

[howardjp]

Really. Especially since Paul Vixie runs Root Server F. That will always be BIND.

Re:Verisign using ATLAS, not BIND

[sigsegv]

a.root-servers.net and j.root-servers.net

Re:Verisign using ATLAS, not BIND

[Phroggy]

a.root-servers.net and j.root-servers.net

Yes, and J changed its IP a few months ago when it moved across town - they were both at the same facility, which was dumb.

Re:Verisign using ATLAS, not BIND

[Phroggy]

Well, I guess one of those 13 server sites (I assume they mean the roots) isn't running ATLAS now, is it?

I assume that you assume incorrectly.

There are also 13 gTLD servers, in addition to the 13 root servers: [a-m].gtld-servers.net are authoritative for the .com and .net gTLDs. Interestingly, it looks like the root servers are authoritative for .mil? Odd.

Verisign apparently also has [a-g,l-m].nstld.com, which are authoritative for .org, .edu, .gov, and [a,f,g,l].nstld.com share authority of .name with ns[1-3].nic.name.

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.

It's about time.

[LAI]

The root servers are the core of what we know as the internet. We need authoritative name servers if we don't want to have to remember IP addresses, and I am happy to see that K is now finally making some move toward securing itself, even if only a little more.

Re:It's about time.

[Llanfairpwllgwyngyll]

> The root servers are the core of what we know as the internet. We need authoritative name servers if we don't want to have to remember IP addresses

Actually, that isn't really true. We just do it like that NOW.

All that the root servers do it tell us where to start.

How do we find the root servers? By using a "well known list" that doesn't change very often (order of many years between *major* changes - as long as one of the servers listed is reachable and valid we get an up-to-date list of root servers first time we talk to it after booting).

Suppose that we used a different "well known list" that, instead of listing root servers, listed the authoritative servers for each TLD (.arpa,.net,.biz,....,plus country TLDs). Then you don't actually NEED a "." domain at all.

Sounds crazy? Surely this bigger list would get out of date quicker? Yet we accept new "global" CA's without blinking (or even knowing about it) each time we install a new version of Mozilla (or other browser). This is part of the critical trust infrastructure too. So offer a new "well known list" Free With Every Browser Download :-)

Of course, if this made you nervous, you could still include a "fallback" set of servers for "." to contact in the event that you had a query for a TLD which either was not in the existing list held (new .sux TLD anyone?) or had no responding servers from those listed. Even this would hugely reduce the traffic to the real "root" (ie serving domain ".") servers.

Just a thought.....

Re:It's about time.

[chef_raekwon]

Yet we accept new "global" CA's without blinking (or even knowing about it) each time we install a new version of Mozilla (or other browser). This is part of the critical trust infrastructure

not only did this make me nervous, but at the same rate, scared. Accepting new 'global' CA's reminds me of Microsofts EULA, where they can change anything on a whim, cause hell, we accepted it (ofcourse, not us @ Slashdot, cause we use Linux). What if someone with an ulterior motive decides to change things, and redirect requests??

This is certainly a good idea, but, certainly a cause for concern....or am I off base?

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

Re:Specs on BIND Vs NSD

[phorm]

my guess would be... the less extraneous things it does - the better. As long as the the root nameserver serves out addresses, it is accomplishing its purpose. If BIND does things above and beyond, it's just allowing more ways to possibly break or slow down the system.

Re:Specs on BIND Vs NSD

[gorilla]

Authoritative servers run at more than just the root servers, every domain would have two or more of them. What NSD isn't used for is client resolutions, so you wouldn't point your desktop machine at a NSD server.

Re:Specs on BIND Vs NSD

[c_ollier]

(except for evading DOS attacks)

Like in http:\\slashd~1.org ?

Re:Specs on BIND Vs NSD

[matthewp]

Some of the problems with BIND in the past were triggered by malformed data from another nameserver. Software that will never pass a query on, and only answer in respect of domains fot which it is authoritative, is immune from that class of vulnerabilities.

It's possible to disable BIND's recursion feature, though. In fact, that's been the recommended workaround for a number of problems in the past: try a Google search for 'workaround recursion'. Still, the feature is there and makes the software more complex than it would be otherwise. Less complexity *should* (all other things being equal) translate into fewer bugs and hence vulnerabilities.

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:Same interface, different implementation

[Surak]

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.

By your definition, Apache and IIS share design commonalities. :)

Re:Same interface, different implementation

[kisielk]

Both support the same external interface? You mean they both respond to DNS lookups? Incredible, who would have thought a DNS server would do that. Thanks for pointing out this oversight in the article! Oh how we could have been misled!

Re:Same interface, different implementation

[supergiovane]

\begin{troll}
Even my PC and my house have design commonalities. I need to use keys to access both of them.
\end{troll}

Re:Same interface, different implementation

[Abcd1234]

Bingo, the same interface, different implementations. And when they said "has no design commonalities", I will guarantee you, they were referring to the implementation. So I fail to see your point... unless you're concerned that the interface itself is insecure, which seems incredibly unlikely to me.

Monkeys?

[petronivs]

When are they going to switch all of them to monkeys typing randomly?

Hey, it worked for Shakepeare

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

[FroMan]

/cry

no mod points

Re:they should use djbdns

[Feyr]

you forgot a few things

- it works SOOOO much better
- the documentation is clearly, concise and complete

hu ho.. NOT

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

[Beatbyte]

Anonymous? I THINK NOT!

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?

Re:they should use djbdns

[radish]

It's the same thing, tinydns is a subcomponent of the djbdns package.

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

[abulafia]

When you can dance as well as Britney Speers, you can make fun of her. Until then shut up.

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.

Re:they should use djbdns

[kashani]

Except that it's not faster. In our tests 8.x was faster then 9.x and djbdns in handling 1000+/s requests on Solaris, BSD, and Linux.

kashani

Re:they should use djbdns

[TheLink]

The reason why installing DJBDNS seems difficult is usually because people are used to BIND and djbdns does things differently - different programs to do different things. The other possible reason is the person installing doesn't really understand DNS.

It took me some time to understand djbdns, but that's not surprising - learning something new always takes time.

BIND really isn't easier to me - look at the config files.

Re:they should use djbdns

[LiENUS]

the difference is...
90% of the people on this planet dance better than britney spears.

Re:they should use djbdns

[TheLink]

Probably depends on how you test and what you are testing - dnscache or tinydns.

See Name Server C

http://www.icann.org/tlds/org/applications/switc h/ nsconcept.htm

The access capacity for that is 5000 queries/sec, which seems reasonable when compared to other reports on similar spec hardware.

If you are testing dnscache, are the requests already cached?

Anyway if djbdns isn't much slower than BIND I'd stick to djbdns as it has a better security track record.

Re:they should use djbdns

[FunkyMarcus]

Exactly what is svcmgr replacing that it only does things 0.0001% better than?

init.

Mark

Re:they should use djbdns

[Doktor Memory]

Small hint: turn off logging. By default, tinydns and dnscache emit multiple log lines per query, turning your logging disk into a bottleneck. Pipe stdout and stderr from the tinydns process into /dev/null for an order of magnitude (or more) performance increase.

Re:they should use djbdns

[inetuid]

er, init? Put the service in /etc/inittab.

Re:they should use djbdns

[Chupa]

I have to agree with most people's experience here. Sure, djbdns has a bit of a learning curve, but if you know how DNS works and have a bit of patience, it's not bad and it's worth the effort. Once you understand it, it's actually much simpler and easier to maintain, too. DJB's online docs are helpful if you work through them, (though I do sometimes wish he would include built-in help in his command-line utils), and the way he does things does usually make more sense when you think about them. daemontools is pretty slick if you ask me, and the modularization of the djbdns package is really a good idea. I mean isn't that what UNIX is all about? Writing programs to do one thing, and do it well? tinydns and dnscache are trivially easy to set up once you have done it before, and the best part is, it's easy to secure them. Unlike BIND, where it's easy to make a mistake if you don't know what you are doing...and lord knows that improperly configured servers are probably responsible for 90% of break-ins.

Besides, who else gives an actual security guarantee? I mean look at qmail's track record. Hasn't it been around for 6 years now? And how many holes has it had? How about sendmail for comparison? I'm inclined to believe that djbdns/qmail are some of the most secure server programs ever written. Sure DJB might be lacking some of the social graces many of us take for granted, but it would appear that he knows what he's talking about, and I would trust his software over pretty much anyone else's.

Re:they should use djbdns

[blakestah]

See This page

to see a summary of the things that daemontools does compared to other init strategies. You have to run something in inittab to ensure that process restarting is clean and reliable. The daemontools package also makes it easy for one daemon to check all the others, re-start the dead ones, add and/or remove services at will, signal them cleanly, and is available under all flavors of Unix.

You MAY think that is only an incremental improvement over init. I don't.

Re:they should use djbdns

[radish]

I'm not complaining about the thing itself, and I've never used BIND (it's MyFirstDNS [tm]). But I have installed a hell of a lot of software in my time, on an awful lot of platforms, and that was one of the more painful experiences. It wasn't the configuration (e.g. setting up the addresses etc) it was just getting the bastard thing running at all, if you'll pardon my french. The little scripts to add entries and stuff were cool, no problems there, and I like the two components being seperate, makes sense to someone who knows how DNS works but has never used BIND (that's me!).

Re:they should use djbdns

[radish]

OK so lets agree to disagree on how wonderful daemontools is. Fact is, why should I have to learn that, and get it working (which was not easy), when all I want is a little DNS daemon? That's the real problem. I don't want daemontools (so shoot me) but I do want djbdns. I couldn't see how to get one without the other (maybe it's possible, again, I couldn't be bothered to work through it).

Anyhows, everyone seems to think I have something against djbdns (which I don't - I said I liked it) so I'll leave it there.

Re:they should use djbdns

[vadim_t]

monit, running from init.

monit can restart daemons, check the md5 sums of files so that it doesn't start a changed daemon and do a few other nice things.

Re:they should use djbdns

[D. J. Bernstein]

You say that it wasn't easy to get daemontools working. Did you follow the official installation instructions in cr.yp.to/daemontools/install.html? If not, why not? If you did, what went wrong?

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.

Re:they should use djbdns

[radish]

Hmmm...I had written a nice long post but /. just deleted it for me :-(

Anyway, to summarise:

I did follow the instructions, but I wanted to do things a bit differently, which you might say led to me making my own problems, but hey :) First off I didn't want to create a new /package dir just for daemontools - I like to keep my filesystem neat where I can. I wasn't sure from the instructions exactly what would end up in there vs /usr/local/bin etc, so it took a few goes before I was able to figure out the correct dir on my setup to substitute for /package. For example, I wasn't sure if it was just used for source and compiling, or config, or what. Turns out it hold the compiled executables. Personally, I'd prefer if things put their binaries directly into an appropriate bin dir rather than creating their own app dir and then symlinking them, but I guess that's just personal preference (it also seem the most common way of working for most apps).

Likewise I wanted to alter log levels for the djbdns apps, this took a little while to get right (because it uses daemontools' logger). IIRC also the install only worked as root, which isn't mentioned in the instructions. When I ran it as !root it failed with not very helpful error messages.

Finally (and I realise this is a special case, but daemontools did make it very hard for me) - I like to avoid disc access where possible. My server box doesn't do a lot other than DNS and NAT, and so while it's idle I like it to be able to spin down the disk and save some power and noise. As I use reiser (another mistake I want to rectify!) it's impossible to even read from cache without it updating the access records on the physical drive. So the 5 second scan which svcmgr does turns into a 5 second disc hit. Very annoying and noisy! I could see (a) no way of disabling the poll or (b) no way to run djbdns without svcmgr. So I had to improvise, /service is now a ramdisk which is mounted and populated by an init script.

This probably sounds like whinging (and maybe it is) but all I wanted was a DNS daemon which would sit there quietly and serve DNS. In the end that's exactly what I got (and thanks again for tool itself, very cool) but it did seem quite painful compared to all the other installs I've done on this box (apache, mod_php, ntpd, mysql etc). I can't help thinking BIND would have been an easier and more consistent setup (and I'm not talking about the zone file formats or anything here). Maybe it would be easier if my distro (SuSE) had djbdns packaged within it? Dunno :)

Re:they should use djbdns

[Rysc]

That's odd. I've used djbdns and didn't find it at all difficult to install.

Oh, wait. I run Debian. Nevermind.

Re:they should use djbdns

[Doktor Memory]

urk urk urk. You really like to make things hard for yourself, don't you? :)

Okay, first-off, a statement of sympathy: djb has gone out of his way to make it difficult to install some of his software in standard places, and yours is a good example of the kind of headaches that result from his intransigence on this issue.

That said, there are much easier ways to do what you're trying to do here, and I suspect that this would have become immediately apparent if you'd taken a bit more time to read through the documentation, play with the tools, and understand what you're working with.

The big fact that you need to keep in mind here is that the collection of tools that usually gets referred to as "djbdns" is actually (assuming you more or less follow the instructions) three seperate software packages:

• djbdns 1.05
• ucspi-tcp 0.88
• deamontools 0.76

djbdns is a collection of client and server tools for getting and sending dns information. ucspi-tcp is a collection of tools for making generic TCP clients and servers (sorta like inetd or netcat), and daemontools is a collection of tools for managing persistant programs and their logs. It's entirely possible to run them without each other, but you have to be aware of what each package provides and be willing to roll the functionality yourself.

A few suggestions:

• The whole "/package" and "/command" monstrosity is only part of version 0.76 of daemontools. Previous versions (0.70 is still available for download) of daemontools compile in /usr/local/src and install into /usr/local/bin like a sane program should.
• There is no requirement that you use the svscan functionality of daemontools. If you know exactly what it is you want started, just execute "supervise /service/whatever" manually or out of an init script.
• Likewise, you can dispense with daemontools altogether if you just exec the "/service/whatever/run" scripts directly. Of course, you lose auto-restarting and the like, but you may not care.
• If you don't care for the way that daemontools handles logfiles, the "splogger" program from djb's qmail package will take the stdout from a process and pipe it into syslog. (But since tinydns and dnscache log pretty verbosely, you may just want to pipe it to /dev/null.)
• Speaking of those "run" files: you really should read them (they're short), since that will give you a much better idea of what's going on, and why.
• Of course you need to start tinydns and dnscache as root: how else are they going to bind to a privleged udp port? Check the code; they setuid themselves to an unprivleged user soon after binding. (Axfrdns doesn't have this problem: the tcpserver instance runs as root, while axfrdns does not.)
• The contents of /service don't need to be actual directories; a tree of symlinks will do. (This should be a lot easier to build into a ramfs partition than all of the actual subdirs.)

That all said, I find daemontools (modulo the current slashpackage nonsense) to be a very handy utility, and have been slowly converting over most of my long-running daemons to work under it. "Try it, you'll like it."

Re:they should use djbdns

[montesquieu]

The main config file is much easier to
make sense of.

The nicest thing is the fact that I can
resolve 192.168.x.x addresses on the private
side of the net and have them resolve to
something else on the public side.

So the entire private network is freed of
host file maintenance.

Re:they should use djbdns

[lyle_hanson]

Besides, why do your daemons need monitoring? If they stop running or need restarting, that's a bug and should be fixed.

That's true. But what if you're running a (usually) stable daemon that you can't afford to have go down? Wouldn't it be better to have it restarted, and then you can look into fixing the bug later (instead of suffering downtime)? I guess it's a kludgy way to have a bit of assurance.

Actually, I'm glad I noticed this thread because I'm using somebody's apparently unstable daemon in a little project of mine, and I can't really afford to spend all kinds of time debugging somebody's (uncommented!!) code when all I really need is for it to not go down for too long. So this may just work for me.

Elegant? No. But it works in a bind (no pun intended).

Re:they should use djbdns

[radish]

Thanks a lot for all that - I really appreciate it. I'll read through it all and see what bits might be useful later :)

Cheers.

Re:Similar

[squiggleslash]

This sounds a little to general to me, almost PR'ish.

It has no design commonalities with bind

What does that REALLY mean?

It's true. They didn't even look at the same RFCs... ;-)

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:affirmative action

[Rooktoven]

If I had mod points, I'd mark you as funny.

Re:affirmative action

[sean23007]

George Bush is expected to criticize this, citing several cases of more capable BIND systems losing their places on root servers just to give space to a non-BIND system.

security through obscurity

[mxs3549]

Diversity isn't security through obscurity, it's simply insuring that the same exploit can't be used to attack the entire system.

Re:security through obscurity

[emdean091876]

I think he meant that keeping the source closed was security through obscurity, not the fact that they are diversifying.

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:Back to switchboards

[JWSmythe]

Not a problem. They don't have Windows. :)

Mmmmm.. Your dialogue is sounding like one of my fantasies.. You forgot about the part where after work, she takes off her glasses, and lets her hair down, and the clothes come flying off .. hehe

Re:Back to switchboards

[Viqsi]

Ooh. I'd love to see this happen. Might be my best chance to get a tech job. :D

Re:Back to switchboards

[sean23007]

Yeah, but hunky dudes typically don't like to drink their Pepsi anywhere near anyone's bowels. Trust me...

Re:Back to switchboards

[undertoad]

I think I can provide a port based DDOS attack against them. Aww yeah!

I need to get out more.

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.

Re:Diversity is good

[MacGunner]

Sure compition is good when your dealing with companys that make money. But with opensouce? prolly not.

Re:Diversity is good

[christopher240240]

Ma Bell was broken up??? I could've sworn I saw a commercial by them the other day talking about 150 years of sweat. Oh wait, that was SBC.

Re:Diversity is good

[jalet]

For very high reliability, the space shuttle seems to be a bad example, just like anything which tries to fly...

Re:Diversity is good

[opie92115]

Personally I think its vital to open source that there be competition. It means that projects will be competing to make a better project so that someone else doesn't out do them. Look at how many Distributions of Linux there are. They all try to be better than each other and as a result we get a better product (hopefully).

Re:Diversity is good

[Phroggy]

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.

Uhh, except that now we have four, and they still haven't gotten rid of the original software. I used to know what it was called, I'm trying to remember - anyone know?

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.

Re:Security through _______

[digitalsushi]

"Baker's Dozen"

Re:Security through _______

[reifchen]

The number of '13' comes into play because of two competing factors.

a) More machines is good (the query load is not insignificant).

and b) Limitation in the packet size; you can only fit in 13 names if they're all in the same zone (root-servers.net).

Now, the ideal placement of those 13 servers, thats a completely different story.

Re:Security through _______

[TeknoHog]

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

No, but it's bad luck to be superstitious.

Perhaps a silly question.

[Misuzu]

Perhaps this is a silly question, but I am curious...

The article states: "K will answer either using bind8 or nsd".

How does one go about identifying which software is in use at a DNS server? Is there a piece of data transmited with the response - like with webbrowsers to indicate which version/browser was used to make the request?

Perhaps the article is talking in an abstract manner about how the server will respond, and not in a litteral way - and such a feature of DNS does not exist.

(I cant see how it would NEED to exist frankly. People want to know the IP address of the name they are looking up - not what piece of software is being used to retrieve it)

Nevertheless, I am curious.

Re:Perhaps a silly question.

[Anonymous Coward]

dig @server.example.com. version.bind chaos txt

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

Re:Perhaps a silly question.

[reifchen]

> The article states: "K will answer either using bind8 or nsd".

Actually, the full quote is:
: During the cut-over period, K will answer either using bind8 or nsd
( There is a load balancer in front of a number of machines performing the K-root function )

To answer your other question, being:

> How does one go about identifying which software is in use at a DNS server?

There are three methods. One is the defacto which was introduced with BIND4.mumble, by which you could send a TXT query of 'version.bind' to the nameserver, and it may answer with the actual version (depending on how the local administrators set it up - ref BIND documentation for further details).

Another method is currently going through the IETF process as draft-dnsop-serverid, and consists of sending a similar query for 'version.server'. (ref the draft for further specifics). NSD replies to this method since it is not BIND.

The third method is analysis of how the nameserver replies to queries. Even between BIND versions there are a variety of subtle differences in the packet that you get back.

But, we haven't answered the 'why'. One reason is if you are tracking obscure protocol bugs from servers not under your control. Another is purely for local administration and tracking which nameserver is doing what.

Re:Perhaps a silly question.

[kindbud]

djbdns drops queries in the CHAOS class, so it, too, returns no answer to the version.bind question.

Re:Perhaps a silly question.

[Fenris Ulf]

I like how bind 9 will round-robin the authors.bind response. Probably so no author feels slighted by being listed last :)

Try hitting h.root-servers.net a few times to see what I mean (it hits bind9 about half of the time).

Re:Perhaps a silly question.

[Virtex]

One is the defacto which was introduced with BIND4.mumble, by which you could send a TXT query of 'version.bind' to the nameserver

Just to clarify, the record in question is a chaos record. So, for example, if you wanted to know what server Slashdot's DNS servers are using, you could do something like this:

dig chaos txt version.bind @ns1.vasoftware.com

Phew!

[DarwinDan]

With all of the vulnerabilities in BIND thank goodness the folks at VeriSign finally switched to something else!

Re:THIS PROVES OPEN SOURCE ISNT READY FOR PRIME TI

[Anonymous Coward]

The problem is not the Microsoft DNS server, it's the platform on which it runs. Windows Server OS products cannot be trusted. Period. Just as everyone that used to run MS SQL prior to the slammer exploit. How many MySQL installations were hacked by slammer?

(Just under 0%)

Re:Netcraft confirms it..

[fgb]

are you trying to imply that BIND might be dying?

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.

djbdns

[markfletcher]

I wonder why they didn't switch to Dan Bernstein's DNS package (djbdns). Like all his code, it's solid as a rock, speedy, and easy to understand. Maybe it's because there's such bad blood between Dan and the BIND guys.

Re:djbdns

[reifchen]

I think that it is a kindness to djb to not use djbdns on any of the root servers. His ego is already large enough; it would simply explode if djbdns ran on a root server.

Seriously, djbdns, as supplied, is not usable on a root server due to security constraints involved in retrieving the root zones.

I wish we could start replacing the DNS system

[digitalgimpus]

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.

Re:I wish we could start replacing the DNS system

[MavEtJu]

And more rapid updating, so changes take effect faster.

Just set the TTL to a lower value and you're in. It all happens automatic.

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

Re:Security?

[Abcd1234]

Well, how else do you propose to test for buffer overflows? Sure, you can do your best to ensure they aren't written in the first place. You can audit your code to catch any of these things. But when it comes down to it, you should probably test for it somehow...

Re:Security?

[Nevyn]

Well, how else do you propose to test for buffer overflows?

Don't have staticly sized buffers.

There are more than a few string libraries for C, and amazingly there is a direct correlation between those servers that use one and those that are secure. Then again nsd doesn't seem to have that many static buffers, and UDP servers can get away with this a lot more than most ... and it only has one call to strncpy() (which looks dodgey -- but is in the config parser) ... well it's not like it can be much worse than bind.

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:Sodftware diversity not always a Good Thing

[johnnyb]

" Thinking of it, it would be nice if compilers could generate (randomly) different - but working - binary code from the same sources."

Actually, you can through compiler switches.

However, this doesn't help any. It may mean that someone may need to write multiple versions of the same exploit, but the exploit will be there in all versions.

Even in the case you mention - cracking a machine - you still have only 1 machine cracked versus the whole bunch. At least afterwords you would have at least 1 known-good copy of the data.

way too easy to hack

[Anonymous Coward]

Wouldn't surprise me if bad blood was the reason. The IETF has made lame BIND hacks like AXFR and TSIG part of the DNS standards, and DNSSEC is a fading pipe dream, which is good, because it's the stupidest of all. Standards are supposed to be independent. It wouldn't be so bad if BIND was any good, but it really is an awful piece of junk. Hurrah for djbdns, and for nsd, and for any quality alternative to the buggy bloaty mess that is BIND.

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.

Re:Waste of effort

[FunkyMarcus]

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.

Ooh, is that flamebait I smell?

It's long since been agreed upon that combining authoritative and recursive name services is a terrible idea. With that in mind, is there any reason for your authoritative DNS server to contain recursive code? Do recursive servers (for most of us?) benefit at all from the authoritative code?

Most of us in the scope that you use it may never realize incredible benefits from software targeted at most of us network operators. Just because the effort spent developing this software will not directly benefit you doesn't mean it was wasted.

to use over a dialup connection?

Oh, I see. It was flamebait, after all.

Mark

In a bit of a bind?

[paulhar]

No longer can we say that "k" is in a bit of a bind.

Why they didn't go the whole hog though and run with Windows 2000 "Advanced" "Server"; it's got DNS - we could transition everyone to ActiveDirectory and the world would be a better place. Just imagine, attempting to surf the web and getting bounced by kerberos because of >5 minutes clock skew...

Erm!

Won't stop DDoS attacks

[huckamania]

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.

Re:Security through ?

[JWSmythe]

I'm confused on point b.

.voyeurweb.com. has 218 A records in it.
.microsoft.com. had thousands of A records. I did a recursive lookup on them once. It was funny. It's obvious there are some people over there with a sense of humor.

voyeurweb.com. itself has 14 A records, but we've had up to 22. We did overrun the packet size when we had more A records (25) in there, but only some clients were failing because of it. They could easily add another root server, without breaking things. Well, assuming everyone would update their hints. I don't think most people optimize their hints file for their location.

> dig voyeurweb.com A

;; QUESTION SECTION:
;voyeurweb.com. IN A

;; ANSWER SECTION:
voyeurweb.com. 3600 IN A 63.208.2.97
voyeurweb.com. 3600 IN A 209.247.59.14
voyeurweb.com. 3600 IN A 209.247.59.15
voyeurweb.com. 3600 IN A 209.247.59.16
voyeurweb.com. 3600 IN A 209.247.59.17
voyeurweb.com. 3600 IN A 209.247.59.84
voyeurweb.com. 3600 IN A 209.247.59.85
voyeurweb.com. 3600 IN A 209.247.59.86
voyeurweb.com. 3600 IN A 209.247.59.87
voyeurweb.com. 3600 IN A 63.208.2.23
voyeurweb.com. 3600 IN A 63.208.2.25
voyeurweb.com. 3600 IN A 63.208.2.62
voyeurweb.com. 3600 IN A 63.208.2.64
voyeurweb.com. 3600 IN A 63.208.2.84

{sigh} I think I'm hitting every posting violation today..
"Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted."
"Reason: Please use fewer 'junk' characters."

Mod parent up, good rebuttal

[Abcd1234]

The tendency to produce software which includes everything but the kitchen sink is a serious problem these days. BIND is an excellent example of that, for exactly the reasons the parent poster mentioned.

Re:"Petard"

[Alan Partridge]

see what I mean?

Why is BIND insecure?

[deanthebean]

So...

Why exactly is BIND insecure?

Seriously.

I've used BIND for years and years, never had a problem out of it. I update when need be, like I do the rest of my software and never once did anything bad come out of using BIND.

All the time, like in these comments, I hear quite a bit about BIND being insecure. What is it that makes BIND insecure?

Re:Why is BIND insecure?

[Anonymous Coward]

The same reason duplicating and installing the exact same lock & key in thirteen houses is insecure.

Re:Why is BIND insecure?

[MavEtJu]

What is it that makes BIND insecure?

You dis-believer! Don't you know that BIND sucks and that DJB rules?

Anyway, what people don't understand is that one of the goals of BIND is to be a reference-model for DNS related RFC. So if there is an RFC saying that name-servers should do "blaat", BIND has to support that function. The other nameservers (maradns, firedns, djbdns, nsd) don't have to adopt all these features. And if you add more features, more things can get broken.

Regarding the choice to use NSD over BIND, I too would choose software which is doing exactly what I like it to do (authoritative answers only) above something which is generic. For other machines, I would still run BIND.

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.

Re:Exactly!

[bheer]

I get uptimes of 20-30 days on my Windows 2000 box (512MB RAM) without logging out, which i use as a workstation (usually 10-20 IE/Phoenix/Opera windows open + VS.net + at least 2-3 Office XP tasks, plus 3 messengers + pageant + antivirus + Winamp2 + Outlook XP. I'd get more but I run Windows Update every ~20-30 days for the security updates (which ask me to reboot).

Only bug I've noticed is that explorer.exe sometimes fouls up its icon cache every 14 days or so, though restarting explorer.exe via the Task Manager solves that problem.

This is much better than my experience of X sessions on Linux that'd force me to exit X once in 3-7 days or so (I'd love to know what uptimes other get with X -- am I doing something wrong? (Redhat 7.1 on a (dualbooting) Dell Optiplex)).

I'd just like to add -- make no mistake, Windows 2000 (and XP, though I don't like its default looks -- you can make it look it Win98 if you want though) line is *great* as a graphic workstation. When you consider that Win2k SP3 added a great compatibility layer (WinXP has a better one though) then Win2K looks sweeter than OSX because of broader app availability.

Re:Similar

[Phroggy]

It's true. They didn't even look at the same RFCs... ;-)

Which came first, BIND or the RFCs?

Name server statistic plots

[geog33k]

They have some monthly and other name server statistic plots available showing the changes in traffic before and after the upgrade.
These graphs were processed using Orca.

security through obscurity

[nothings]

"'Security through Obscurity' Considered Harmful" Considered Harmful

The basis of almost all security is the keeping of a secret--whether that be a login password or the passcode to access your private key for encryption. The whole premise of security is that users with this "secret knowledge" will keep it secret. You could even keep your private key in the clear on your hard drive, relying on the fact that nobody has physical access to that hard drive.

Keeping a secret is central. Keeping that secret secret. Obscuring that secret. Security through obscurity. So the slogan ("'security through obscurity' considered harmful") is just wrong.

Now I'm going to wander off-topic in a more straightforward scenario here, but what the slogan intends to address is that, if you, say, use a secret encryption algorithm to protect your data, you have to keep that encryption algorithm just as secret as you keep your secret key, if you expect that algorithm to buy you any extra protection over, say, triple DES. And that tends to be hard.

You have to describe and encode your algorithm somewhere, and keep that secret. You can measure the number of bits it takes you to describe and encode that algorithm, and add in the number of bits of your encryption key. That's the total number of bits you have to keep secret to protect yourself.

The real truth behind this sort of scenario of the anti-"security through obscurity" meme is that you get better security through putting the same number of bits into a secret encryption key for a well-tested public algorithm than you get for splitting those bits between a secret algorithm and a secret key, because even if your algorithm isn't inferior, it's still using fewer bits of key.

So, sure, security through obscuring your algorithm is bad, because there are better places to spend your secret bits. But "security through secrecy" is fundamental--and I think it's foolish to try to distinguish between "secrecy" and "obscurity".

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.

Huh?

[iamacat]

Surely some code to share can be found between autoratitive and recursive DNS servers. I am going to expose my ignorance of DNS here, but I assume both speak the same UDP and TCP protocols. Why not share the code that parses and assemble the packets? Likewise, both will need a database and an in-memory cache to answer requests efficiently. Do two versions really need to be written separately?

Now I am going to dig an even bigger hole for myself, but aren't most DNS servers authoratitive for one or several domains and caching data for all the others? Why shouldn't they benefit from the optimized authoratitive code?

I guess you wouldn't like embedded Linux then, because desktop Linux has all that bloated mainframe scalabilty code that is not needed on a PDA. Of course, unnecessary weight should be compiled out whenever possible, but I don't see how refusing to reuse code without a specific reason is superior. If BIND sucks or is not modular enough, then write a nicer, more modular DNS server that covers the needs of most users. Finally, why shouldn't dialup users run a caching-only DNS server to reduce the number of lookups going over the modem? Last I checked, this was an option in Redhat.

Re:Huh?

[FunkyMarcus]

Why not share the code that parses and assemble the packets?

There's nothing wrong with that. Many projects, of which BIND is one, aim to produce a monolithic DNS server capable of performing both authoritative and recursive service. On the other hand, a project which aims to focus on a more specific aspect of DNS should not be discounted for the reason that it ignores all the other aspects. On the contrary, the focused nature of such a project is indeed a benefit for those that do not require the flexibility of something like BIND, but instead seek (for example) performance, scalability, and security.

That's not to say that BIND and other monolithic DNS servers are terrible. In fact, I run BIND and find it quite agreeable. The code (versions >=9) is clean and easy to digest and modify, and the developers have been receptive to bona fide bug reports.

Now I am going to dig an even bigger hole for myself, but aren't most DNS servers authoratitive for one or several domains and caching data for all the others?

Not in this day and age. Real DNS servers managed by competent administrators are dedicated to one task or the other.

Why shouldn't they benefit from the optimized authoratitive code?

It's optimized for the wrong purpose. In general, a recursive server would be better off with its own optimizations. This is the general KISS principle. It's a guideline, not a hard-and-fast rule. One of the goals of the NSD project, and other similar projects, is to produce an authoritative-only nameserver. Recursive operations being outside of this scope, they're omitted. If that makes the software unattractive to you, then so be it. But have no fear, there are plenty of recursive-only nameservers out there that have been optimized for their tasks.

The market for DNS server software that is able to perform both authoritative and recursive service from within a single process has shrunk to an incredibly small size. There are just too many problems when the DNS universe is shared by the two data sources, and we've realized that this sharing is not necessary. So, while the world may see future development of new do-it-all DNS servers, we shouldn't be bound to developing future DNS servers to meet the needs of yesterday's network. If there's a better way to do it, we shouldn't let prior practice discourage us.

I guess you wouldn't like embedded Linux then, because desktop Linux has all that bloated mainframe scalabilty code that is not needed on a PDA.

Hyperbole much? Besides, I don't like Linux or PDAs for other reasons. :)

I don't see how refusing to reuse code without a specific reason is superior.

Y'know, I bet that some of the NSD code would be reusable in a recursive server. Much of that code would come from the top end, where data is moved between the network and the nameserver process. That code is largely trivial. It's the equivalent of int main(int argc,char **argv). You can optimize that as much as you want, but the end result won't be much different than what you started with.

If BIND sucks or is not modular enough, then write a nicer, more modular DNS server that covers the needs of most users.

I think you've mistaken my viewpoint for a complaint.

Finally, why shouldn't dialup users run a caching-only DNS server to reduce the number of lookups going over the modem?

There's no reason they shouldn't. It's an excellent idea. Just use a tool designed for the job. Recursive-only? Great. Big monolithic DNS, SMTP, and HTTP server with integral seat warmer? Great. But something designed for an entirely different target audience? It's not happening.

Mark

Failure mode

[driehuis]

There are two things that can go wrong with root name servers:

1- Compromise: returning bad data, etcetera
2- Denial of service

It's important to look at the failure mode, and at the effects and probability of each.

If half the root servers are compromised, there's a 50-50 chance that a user gets compromised DNS records. That means that the chance of it getting detected quickly goes up rather than down if there is no monoculture, as someone is bound to spot the inconsistency. If all root servers return bogus data, focus will initially be deflected to the source of the data (i.e., the database itself). I investigate corrupted DNS issues at least once a month (so far, never an issue on the root DNS servers, but bogus DNS data is rife on corporate and ISP name servers; and the fact that someone picks up the phone and asks me to look into an issue is testament to the fact that discrepancies are spotted more easily than all out failures).

If half the root servers suffer a DoS, hardly anyone will notice. Seeing that DoS attacks on the root DNS servers are rather common these days, I'd say diversity is a win no matter what.

And as a matter of fact, I think that attacks on DNS caches at ISP's and corporations will increase. Already spammers are taking advantage of obscure BIND features to cover their tracks. But that's got nothing to do with the root servers.

An added benefit of the NSD initiative: a piece of software written to deal exclusively with this subset of DNS functionality is inherently easier to verify by desk checking. Which will quite likely result in the monoculture shifting towards NSD eventually :-)

I expect NSD to pan out simply because it has less "moving parts" than BIND has, and I think that is a very important consideration.

Re:Failure mode

[cduffy]

An added benefit of the NSD initiative: a piece of software written to deal exclusively with this subset of DNS functionality is inherently easier to verify by desk checking. Which will quite likely result in the monoculture shifting towards NSD eventually :-)

I expect NSD to pan out simply because it has less "moving parts" than BIND has, and I think that is a very important consideration.

Honestly, I entirely agree with you.

I got into this thread by explaining a strictly theoretical argument made by crow to someone who Didn't Get It. I still hold that crow is correct in his argument -- but that's not to say that NSD is not a more secure piece of software, or that it shouldn't be in (partial or widespread) use.

Read more carefully

[vrt3]

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

(emphasis mine)

Re:Security through ?

[reifchen]

The premise that the roots operate on is that you want to be able to reply to most things in a single packet, otherwise you incur greter overhead in falling back to TCP. Since the roots only deal with delegations (NS lists), that imposes a limit on the number of nameservers for each TLD, in addition to the number of the root servers.

The next limiting factor is the maximum size of a UDP DNS packet. For various reasons, this is 512 bytes.

Then, you need to have space to repeat the query (up to 255 bytes) as per the DNS protocol. That cuts down on the amount of space available. Fortunately, there is compression used in the packet, such that you can get ~8 nameservers if they're in different domains, and ~13 in a single domain (ref 'root-servers.net' and 'gtld-servers.net'), and all the addresses are 4 bytes (IPv4).

Re:Hello

[42forty-two42]

"edotrial" team?