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."
Well.. I guess they're not in a BIND anymore!
...god, that was the worst joke ever. Someone shoot me.
slashdot!=valid HTML
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. ;-)
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?
Tuus crepidae innexilis sunt.
Having no diversity means you are ripe for an epidemic.
$#!^ happens, but why does it always have to happen to me???
As of last year, Verisign has been running ATLAS, instead of BIND, for DNS. See the story here.
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
But previously if you learned of a BIND vulnerability, you could hijack ALL of the root servers, redirecting 100% of requests to your site. Now, if there is a single vulnerability in either system the hijacking could only affect a portion of the system, not the entire internet.
An online Starcraft RPG? Only at
Online Starcraft RPG? At
Dietary fiber is like asynchronous IO-- Non-blocking!
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.
You are not alone. This is not normal. None of this is normal.
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.
1f u c4n r34d th1s u r34lly n33d t0 g37 l41d
In particular, it means it isn't a "fork" of BIND, either in architecture or implementation. If it were a fork, it would possibly be vulnerable to the same attacks as BIND, where they share code. The whole point of this switch is to use a nameserver that does not share those vulnerabilities. I have no doubt nsd has vulnerabilities of its own, but it's far less likely that BIND and nsd share the same vulnerabilities.
I think 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.
I think he meant that keeping the source closed was security through obscurity, not the fact that they are diversifying.
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.
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.
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.
today is spelling optional day.
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.
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%)
...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.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
> 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.....
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.
Ciao
----
FB
I would rather see them pick some alternative general purpose DNS implementation and optimize it for their needs.
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.
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.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
Seriously, djbdns, as supplied, is not usable on a root server due to security constraints involved in retrieving the root zones.
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.
This sig has been temporarily disconnected or is no longer in service
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.
LedgerSMB: Open source Accounting/ERP