Taking the curse out of recursive DNS

As you might have heard by now, on Tuesday, researcher Dan Kaminsky, in conjunction with CERT-US, Microsoft, Cisco, Debian, and many other vendors, announced a major vulnerability in the Domain Name Service (DNS) protocol itself. The vulnerability advisories mentioned that DNS servers performing recursive name resolution are especially vulnerable to the attack. This entry is for you if you're foggy on the concept of DNS recursion.

The Domain Name Service is often called "the phone book of the Internet." This is the mechanism by which you type www.watchguard.com into your browser, and soon your PC has found the computer hosting WatchGuard's web site. To accomplish that magic, a DNS server really does two major tasks. Each DNS server has a name resolver and a name server.

Behind the scenes, your PC has asked the closest DNS server, in effect, "What is the IP address of watchguard.com?" The DNS server says in computerese, "Gimme a second and I'll find out for you." With that, your DNS server has assumed the responsibility of finding out the address of watchguard.com.
Your DNS server is aware of some other DNS servers. It will ask those other servers for information. It does it in one of two ways:

• In iterative DNS resolution, it queries another DNS server: "Do you know where www.watchguard.com is?" If that second DNS server is not the authoritative domain server for watchguard.com, it will say basically, "I dunno." So your DNS server asks another DNS server: "Do you know?" If it gets back "I dunno," your DNS server keeps working its way through all the other DNS servers it is aware of until it gets an answer or determines it cannot find the server that hosts WatchGuard's web site.
  
• In recursive DNS resolution, your DNS server asks a second DNS server, "Do you have the address for watchguard.com?" and the second server says, "No, but I have an idea where I can get it." Let's say that second server knows of a third DNS server that is authoritative for the top-level domain, dot com (.COM). The third DNS server knows of a fourth DNS server that is authoritative for WatchGuard. You get the picture: a bunch of requests and responses pass among the DNS servers, and finally that second DNS server tells your server the address of WatchGuard's web server.

In short, iterative DNS resolution means your DNS server is doing all the legwork itself. Recursive DNS resolution means a server is taking over the job for you.

But now you might begin to see why recursive DNS resolution is more open to malicious attacks than iterative DNS resolution. When all those servers start passing around requests and responses, they trust whatever answer comes back. That's when an attacker has opportunity to insert a lie, assuming he can format it to resemble a legitimate response.

It's very important that you install the DNS patches vendors started making available on July 8. But you can harden your DNS server further. You should configure it to be recursive inwardly, and iterative outwardly.

What I mean is: your DNS server must act recursively for all the clients inside your network. It's taking over the name resolution job for them, and then serving the name back to them.

But for the side of your DNS server facing outside -- the rest of the world -- it is safer to set it in iterative mode. That means it will answer queries about the domains you own. But it will shrug and say "I dunno" to all other requests. That cuts off outside opportunities for attackers to attempt DNS cache poisoning.
If you are an administrator for a small to medium sized network, there probably is no compelling reason why you need to offer the world help in resolving domains for which you are not authoritative, anway. That's one way to take some of the curse out of DNS recursion.

The newly announced vulnerability has a lot of fascinating aspects. To hear a thorough rundown, and more on what you can do to defend yourself, watch for the Firebox Special podcast episode coming out next week.