A Bit About DNS

The Domain Name System is generally taken for granted. You put in a name, like perimetergrid.com, and you get back an IP address (at the time of this post, The addresses change sometimes, but it just works.

However, it’s taken for granted so often that sometimes big security consequences lurk within. I’m not going to talk about DNS rebinding — that’s a relatively big issue, and a relatively new attack (and if you want to know a ton about it, you should read Dan Kaminsky’s blog; he’s a master of weird DNS tricks and a great speaker.) No, I’m talking about much simpler things.

But first, a bit about how a DNS lookup works. Imagine you’re sitting on your home computer, with Comcast as your ISP. You want to use Google’s search engine. You type “www.google.com” into your web browser. What happens?

  1. Your computer checks its hosts file and local DNS cache to see if it happens to know the IP address for “www.google.com.” If it does, it makes sure that the TTL (Time To Live) on the cache entry hasn’t expired. Assuming there’s a current entry, you’re done here — the web browser connects to the cached IP. But if not…
  2. Your computer has a record of Comcast’s DNS server IPs. It got these along with your IP when you connected to the Internet, and there are always at least two. It contacts this IP (at the time of this post, and asks for www.google.com in a UDP packet.
  3. Comcast’s DNS server has a cache, too.  If it happens to know www.google.com, it returns it to you and you’re done.
  4. If it doesn’t, it needs to find a DNS server that does.  It checks for the top-level domain (google.com) and checks to see if it knows the authoritative DNS for that name.  If so, it forwards the request there.  If not, it goes up another level (.com) — every DNS server knows the IPs of a small core of top-level domain name servers (administered by ICANN), and so it forwards the request there.  It does the forwarding itself rather than telling you to do it so that it can cache the result to improve performance next time.
  5. The top-level domain name server recieves a request for www.google.com. These top-level servers don’t cache and don’t know any subdomains — so all it can tell you is the authoritative DNS for google.com.  In the case of large companies like Google, this will be one of Google’s own servers.  For smaller websites like this one, it will be a server owned by the ISP hosting the site.  (Of course, it doesn’t tell you, since you didn’t ask it — it tells the domain name server that forwarded it the request.)
  6. The request now reaches the DNS for google.com, and asks for the IP for the server “www.”  Google’s DNS knows this, and returns it — finally your browser can load the page you want.

That whole process happens nearly instantaneously — sometimes a dozen times to load a single web page.  Every time a name is returned, it is accompanies by a TTL, which tells the servers (and your PC) how long they are allowed to cache the results before asking again (due to load-balancing and dynamic IPs, DNS results aren’t usually good forever, and sometimes are only good for a few minutes.)  In addition, DNS can return three major different kinds of records:

(DNS can actually return at least 63 other kinds of records, but they’re beyond the scope of “a bit about DNS” and some are barely ever used at all.)

The system was not designed for security.  It does not have much in the way of security features (though there is an effort to design a new, secure DNS.)  However, it does have at least two of major security options — you can restrict who is permitted to perform a “zone transfer” (essentially a special DNS lookup that tells the authoritative DNS for a domain “tell me everything you know about the domain,” meant to be used for DNS servers that mirror each other), and you can restrict who is permitted to perform a recursive lookup.  What would happen if you left those features off?

With zone transfers, it’s relatively obvious (at least compared to the recursion restriction) — if a hacker could ask for a zone transfer, they would know the names and IP addresses of every server in the domain.  This can tell you a lot about how the internal network is organized!  It tells you what targets to attack, how many servers there are, sometimes what the servers are for (if they have descriptive names), etc.  It’s enough information that trying a zone transfer is usually the first step in information gathering for an attack — it almost never works, but if it does, it’s a wealth of information.

Recursive lookups are not so obvious in their security implications.  A recursive lookup is what your ISP’s DNS does for you when you try to go to a website — it sees if it has the target in its cache, and if not, forwards the request up and down the chain until it gets it.  It won’t get stuck in infinite loops or anything — if the top-level domain name servers or the reported authoritative DNS say the name isn’t found, the lookup stops.  In a proper configuration, only people within the domain can perform a recursive lookup of a site outside the domain; people outside should only be able to look up sites within the domain.  If I’m not on Google’s network, how would my request for anything other than a Google machine end up at their DNS server?  It shouldn’t happen.

So what’s the harm if it does?  Actually, a lot.  There are two implications here: DOS amplification and cache poisoning.

In DOS amplification, a hacker wants to take down some remote IP address.  DNS lookups are tiny UDP packets (about 75 bytes), and require no authentication — a DNS server will respond to anyone, anytime.  If the hacker sets up a program to forge UDP packets claiming to be “from” my target to a DNS server, it will respond with packets “to” my target that are potentially much, much larger than my little UDP packet.  If he has a malicious DNS server to make the lookups to, there could potentially be a 4 kilobyte response to a simple lookup.  Due to the caching, any DNS server enlisted in this scheme will only hit the malicious DNS once — after that, it will amplify 75 bytes into 4000 every time it’s asked!  With this, one hacker on a 384 Kb cable modem uplink can bring down a web server with a 20-megabit line.  While this isn’t an attack on the person running the badly-configured DNS server, it’s not the kind of public service a network admin wants to provide.

Cache poisoning, however, it is an attack on the company with the badly-configured DNS server. This time, the hacker sets up his own google.com — or more likely, his own citibank.com or amazon.com.  It’s probably a proxy of the real thing, only with a bit of spying going on to steal information, or site modification to install malware.  He then issues a huge number of DNS lookups to the target DNS server, all requesting the site he wants to hijack, like google.com

For each one, the target DNS dutifully goes to the top-level domain servers, gets google.com’s IP, and asks the DNS server for the DNS record.  Google will reply, along with a sequence number that lets the DNS know which request this response matches.

However, at the same time the hacker sent all his requests, he also sends a similarly huge number of replies, all spoofed to be “from” the authoritative DNS being queries, with random sequence numbers.  This makes use of a “birthday attack” — guessing a single 16-bit sequence number is very hard, but if you make 300 guesses and there are 300 right answers, your chances of hitting one are actually 50%.  800 packets is effectively certainty.  This isn’t quite as easy as it sounds, since the attacker’s replies have to get there before the real ones.  But they’re 75-byte UDP packets, so they’re fast, and a determined attacker will sometimes DoS the real DNS at the same time to slow it down.

Now the target’s DNS server has cached a false record for google.com or whatever other domain was chosen — and that record probably has an insanely long TTL (say, weeks) so another lookup won’t happen for quite a while.  Every time a legitimate user of the domain tries to go to the chosen site, they get directed, transparently, to the hacker.  It says “google.com” in the address bar of their browser, because the browser knows that’s where they are — it trusts DNS, and the user doesn’t want to know about IP addresses anyway.

Correct configuration of DNS servers is vital to the secure operation of the Internet — the smallest errors have huge consequences, because DNS is the trusted foundation on which all other communication relies.

attacks, networks

If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.