Slashdot Mirror
Root-server switches from BIND to NSD
A Sorry End writes "It appears that one of the 13 root-servers, the core of DNS name resolution, have moved away from BIND to NSD since wednesday, Feb 19th, 2003, which is a Good Thing. Since the 26th of october 1990, all root-servers have been running BIND. According to this message, this change was designed to increase the diversity of software in the root name server system, the lack of which is widely considered to be a potential vulnerability. The nsd software has been designed from scratch specifically as an authoritative name server. It has no design commonalities with bind, the currently prevalent DNS implementation.
In addition to that nsd provides a significant increase in the performance reserve of k.root-servers.net.
NSD was developed at NLnet Labs in coorperation with RIPE."
Having no diversity means you are ripe for an epidemic.
$#!^ happens, but why does it always have to happen to me???
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.
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)
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
Very popular slashdot journal for adul
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.
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.
Engineering and the Ultimate
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.
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.
When you can write code as good as DJB then you can make fun of him. Until then shut up.
djbdns rocks.
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?
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.
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%)
> 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
:-)
.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.
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
Just a thought.....
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.
I would rather see them pick some alternative general purpose DNS implementation and optimize it for their needs.
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!
Seriously, djbdns, as supplied, is not usable on a root server due to security constraints involved in retrieving the root zones.
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.
Everybody dies frustrated and sad and that is beautiful
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.
DO NOT LEAVE IT IS NOT REAL
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.
Get your own free personal location tracker
The same reason duplicating and installing the exact same lock & key in thirteen houses is insecure.
' 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.
Engineering and the Ultimate