Securing DNS From The Roots Up

jeffy124 writes: "This article at ComputerWorld tells the story of how ICANN would like to replace the root DNS systems with secured servers. Lars-Johan Liman, one of the root operators, spoke about the concept at ICANN's annual meeting today. He discussed how the world's current redundant DNS system is vulnerable to DDOS attacks and yet-to-be-discovered root holes in bind that can ultimately undermine the entire Internet by taking away the name-IP mappings that are relied upon by just about everyone."

Comments

Why still running on BIND?

[kc8apf]

I have yet to find the great reason of why everyone uses BIND. I've been working on my own DNS server just for kicks. The protocol itself is trivial. It can be handled so easily, but yet, if you look at BIND's source code, you can't tell what is going on at all. So, why does everyone continue to use it? Or better question, why hasn't someone written a better alternative?

Re:Why still running on BIND?

[fanatic]

Already available is djbdns, written by D. J. Bernstein with security as a design goal. In fact, he offers rewards to anyone who can find a vulnerability.

Re:Why still running on BIND?

[astrashe]

I don't know if it needs to be an SQL database, but it needs to be some system that will let you update the zone files dynamically and instantaneously.

The official BIND 4.x and 8.x trees are full of bad code that will probably yield serious bugs down the road. OpenBSD's audited BIND is based on 4.x, and as such lacks some important features that you really need. Theo and the gang have said that they have no intention of auditing the 8.x code, because it's so sloppy, and because they don't feel it adds enough to the 4.x tree.

I'm paranoid about the MySQL enabled version of BIND, because I'm not confident that it would be patched quickly in the event that an exploit was discovered.

I've been meaning to try to tie djbdns into a web application that could modify zone data -- the command line programs seem like they could be called easily by php, although I haven't actually installed it yet, so I could be all wet. If you don't do many modifications, it might be a reasonable compromise between a full blown SQL system and something more lightweight and secure.

A fully featured SQL database could probably keep itself in sync with djbdns with triggers, so long as you weren't pounding on the data and changing it frequently. That would eliminate SQL bottlenecks on the serving side, although I have no idea how it would stand up under heavy zone editing.

I wish the government would throw a couple of million bucks at this problem, and open source all the results. It would make the world a much better place.

Re:Why still running on BIND?

[gorilla]

Here we have our internal DNS running off some Microsoft based system, with MSSQL as the datastore.

I've had to write a program which validates that all our hosts are still properly resolving, as every few weeks it drops a bunch of records. The adminstrators of the DNS have no idea why it happens, all they can do is manually re-add the addresses through the GUI system.

register.com's nameservers

[po_boy]

from the article:

Vendors at the conference offered their own security solutions. Register.com Inc. in New York, for example, has created its own propriety DNS software. The company continues to deploy BIND as well as its own software because diversity improves security, said Jordyn Buchanan, who worked on the team that developed the system.

Is there anyone here knowledgeable about this who can comment on a few things?

• Can I get the source to that in any way?
  
• Does it use a SQL database backend?
  
• Any chance of licensing it out even without the source?
  
• Does it support dynamic updates?
  
• Anything else cool about it?
  
• Are you hiring?
  

I'd love to see (more closely) another implementation of the DNS system other than the 3 or so commonly found.

Re:register.com's nameservers

[davidu]

I can't comment on register.com but at EveryDNS.Net we found bind to be too much of a risk to run for our servers. In the long run, DJBDNS has proven to not only be secure but also far easier to setup, administer as well as write parsers for.

Just my $.02,
davidu

Re:register.com's nameservers

[po_boy]

Would you really look at the source if it was given to you? Would you commit to fixing at least X bugs if they gave you the source?

I would probably look. I've leafed through the source to BIND to see how they do certain things. I doubt I would commit to fixing X bugs, but if I found any, I would submit patches. I have in the past to other people's work.

Does it really matter one way or another, or are you just throwing out buzzwords with SQL and backend?
Any chance of licensing it out even without the source?

yeah, it would be neat if it would. I've been looking for a good nameserver that holds its zone information in my database. I haven't found a good one for the hooks in BIND 9 yet, and I would be willing to ditch it if I found a descent replacement. I am also curious why they wrote their own, and I can see this being one of the reasons.

Since it's going to be used on root servers, I hope not.

I didn't realize they ran it any of the root servers. I just figured they ran it on some of the authoritative servers that they run. Those are the same servers that I update through their web pages rather regularly. Actually, I didn't even realize that register.com ran *any* of the root servers.Which ones do they run?

No need to comment on the last two.

Yeah, trolls aren't known for their stamina.

djbdns and opennic

[SuperDuG]

djbdns states "I offer $500 to the first person to publicly report a verifiable security hole in the latest version of djbdns." ... and no one has claimed the $500 yet.

Also OpenNIC is an ICANN indepent root system ... why not just use them instead of ICANN?

Re:djbdns and opennic

[mutende]

And then there's the Open Root Server Confederation who has instructions for setting up your own root zone using DJBDNS or BIND. Highly commendable! And you get a whole slew of new TLDs in the process...

ICANN does something useful

[kingdon]

Is it my imagination or is ICANN actually working on getting their job done rather than horribly complex politics (more complex than needed to solve the problem), or trademark/legal craziness? There's some background at the page of the ICANN DNS Root committee.

Now, I'm pretty skeptical that a closed source DNS server from Register.com is going to be a big part of the solution, but even that I don't really mind so much. Having a few alternatives is good if for no other reason than helping to keep BIND from stagnating.

The article didn't talk much about DNSsec (or this older page) which has got to be part of the solution (to try to give the 10 second summary, when a client makes a DNS query and gets a response, it is kind of tricky to ensure that the response is really from the correct server, and DNSsec uses crypto to solve this and other problems).

Security, reliability and the like

[Jordy]

Reading this article, I have to start wondering if maybe I'm misunderstanding the problem.

The actual root servers are only queried for the top-level domains and while they have rather massive databases, the types of queries they get is limited.

Now, I'm going to assume that given all the money collected for domains, there somewhere exists a nice pot of money available for running root DNS servers. If there isn't then something is seriously wrong with the administration of DNS.

Segmentation of the actual root servers from the world by utilizing a front-end dns cache that would rewrite the actual DNS queries would solve a lot of problems.

First, rewriting queries would allow an amazing amount of sanity checking to be done on the query itself and should prevent exploiting the back-end root servers directly.

Second, as front-end dns caches can be extremely simple and require almost no configuration, the OS installation can be absolutely minimal excluding even shells. You could go as far as to use an OS that allowed you to revoke system privledges such as certain syscalls (fork, exec, open, etc aren't all that necessary once everything is running) and even make the caching DNS server run as init (though you must have something to bring up networking interfaces.)

Physical segmentation is obviously important as well so a private backbone strung between all core root servers and a seperate interface on each front end cache to access them would help quite a bit.

Of course then comes the issue of DoS attacks which again should be rather easy to solve considering what we are talking about. Just buy a lot of front-end cache systems. You would think given how important root servers are and how much money domain revenues generate, buying a thousand or even ten thousand machines and sticking them in every major network access point wouldn't be all that big of a deal.

Now you still have to deal with the fact that most DNS servers still have a static list of root server IPs. Thankfully, the simple DNS queries that hit root servers can be done with a single UDP packet request and response (until you have to work up the hierarchy) making them prime targets for one of the many clustering solutions out there from simple IP sharing virtual servers to routing protocol tricks.

Of course, I may be oversimplifying the problem.