High-level DNS overview

High-level DNS overview

So, like me, you’ve probably been wondering about this DNS bug the whole world has been talking about. What is it? How does it affect the average internet user? And how do you protect yourself from this?

First: a quick DNS introduction

 

To understand this issue, you need to know a little bit about how DNS works. If you want all the details, have a look at this excellent article at Knol, or click on the image on the right for a detailed graphic of what happens when you visit a web page. A short way to sum this up is:

 

  • You want to visit a web page (www.abc.com)
  • Your computer needs the address of the web server that can give you the page you’re looking for. Since the internet uses IP addresses (something like a phone number for computers), your computer asks a DNS server for the right number. The DNS server is typically located at your ISP.
  • That DNS server (also called a “resolver” because it resolves human-readable addresses to IP’s) checks where it can find this information at something called a “root server”. These servers hold information about all the top level domains (the rightmost part of an address, in this case .com). 
  • Once the DNS server you’re using knows how to reach a server responsible for .com domains, it asks that server where to find one responsible for the domain abc.com. 
  • This continues until a so-called authorative server for the requested domain is found. That server sends your ISP’s DNS the right address
  • This address is forwarded to your PC
As you can see, this can be quite a lengthy process. To speed things up, DNS information is cached in several places; the most important one for this story is your ISP’s DNS server. Since you just requested www.abc.com, your ISP’s DNS server has now cached the IP address for this website. Any other subscriber at your ISP will now get this information from the cache of the DNS server, and doesn’t have to wait for the information to be fetched from other servers. 

So, what about this bug?

Not so fast! Before we get to this particular bug, it is important to know that the DNS is not a very safe system. This might surprise you, since DNS plays a pretty important role in the internet; but DNS bugs have been popping up for decades. The most-used DNS software on the internet, BIND, has had many serious bugs over the years. In fact, a complete rewrite of all code was commissioned after version 8. But as with all large software projects, bugs will likely keep popping up. 

The current attack focuses on cache poisoning. What this means is that an attacker inserts fake data into the DNS cache at your ISP’s nameserver. Once this has happened, they can for example redirect traffic meant for google.com to their own server. Or, perhaps more frightening: they can also do so for your bank’s website, or intercept your e-mail. This technique is used by the chinese government, but also by hackers. 

So, how does this work? This might get a bit technical, but bear with me:

 

  • The main thing we’re trying to achieve is getting your ISP’s nameserver to accept fake data
  • We can’t just send it anything unannounced; the system is protected against that
  • So the only way to get fake data in there is to send a fake reply to a query that was sent to another DNS server
Sounds tough? Not as much as you’d think. Because the DNS protocol uses a system called UDP for sending traffic, it’s pretty easy to use “spoofing”. In other words: impersonating another computer on the internet. So let’s assume our hacker knows how to spoof traffic; he now has to overcome some extra security.
  • To prevent spoofed replies, every query that is sent to another DNS server includes a transation ID. The reply has to contain the same ID, or it won’t be accepted. The attacker will have to guess this ID; since it can be any of 65536 numbers, that provides at least some protection.
  • But not every DNS server has completely random transaction ID’s. So the attacker might have a better chance!
  • To make matters worse, more than one transacion ID might work! If you can get the ISP’s DNS server to send more than one request for a specific domain name, there will be multiple transation ID’s that work! This is know as a birthday attack. To sum it up, if you can get a nameserver to send 200 query’s for the same domain name, you’d only have to fake about 400 replies to have a decent chance of succeeding, even if the transaction ID’s are completely random
Getting scary, right? So, what was the bug that’s now being fixed? It wasn’t a specific bug, it’s a combinatino of all the issues I mentioned. Basically, we’re talking about a design defect in all major DNS software (except one, read on for more!)

So now what do I do, and how was this fixed?

First of all, go check the server you use! Then read on about the fix.

First of all, the issues mentioned (bad transaction ID’s and the birthday attack) have been fixed in all major DNS servers (except for BIND8, but that was already End Of Life’d). These issues were already know, but nobody had thought about the implications these would have for the actual security of the DNS system. 

But more importantly, another layer of protection was added. Until a couple of weeks ago, all DNS servers sent their query’s from a fixed source port, port 53. Don’t know what a “port” is? Think of it as a return address. Each computer has 65536 virtual mailboxes, and replies to DNS queries always had to be delivered to box 53. Since this major update, all major DNS servers use random mailboxes. So in addition to the transaction ID that a hacker has to guess (65536 possibilities), he also has 65536 places to send his fake information to. Since both have to be right, attackers now have over 4 billion possibilities to choose from! It’s not the perfect solution, but a better system is being deployed. Quite slowly, but at least it’s going faster than the IPv6 rollout 😉

 

I promised earlier that I’d tell you which DNS implementation already had protection against these attacks. It’s DJ Bernstein’s djbdns and dnscache software. He offers a security guarantee for it, and so far no major bugs have been found. To quote the original article about this major DNS update:

DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.

There is a fantastic quote that guides a lot of the work I do: Luck is the residue of design. Dan Bernstein is a notably lucky programmer, and that’s no accident. The professor lives and breathes systems engineering in a way that my hackish code aspires to one day experience. DJB got “lucky” here — he ended up defending himself against an attack he almost certainly never encountered.

Such is the mark of excellent design. Excellent design protects you against things you don’t have any information about. And so we are deploying this excellent design to provide no information.