Background: The structure of DNS and how to hijack domains

So, I promised to write about the security issues of DNSSEC versus certificates but I realized that it helps to have a sense of how the DNS registration system works, so this post is about that. I'll get back to the topic soon, I promise.

The important thing to remember is that DNS is a distributed system, where authority can be delegated. So, when I want to get the address of www.educatedguesswork.org, something like the following happens:

1. Go to the root servers and ask who is responsible for .org. The answer turns out to be a bunch of servers operated by Afilias.
2. Go to one of the Afilias servers and ask who is responsible for educatedguesswork.org. The answer turns out to be a bunch of servers operated by Dreamhost.
3. Go to one of the Dreamhost servers and ask for the record for www.educatedguesswork.org

[Technical note: I'm massively oversimplifying here, but this is close enough to give the big picture.] If I'm an attacker and I want to hijack traffic to www.educatedguesswork.org, I can manipulate any of these records. Let's ignoring tampering with the records for .org, which is probably a bigger job. First, I can arrange to have the Afilias servers point to somewhere other than Dreamhost for educatedguesswork.org, i.e., to some server I control and which will give out any result I want. Alternately, I can have the Dreamhost servers give out a different address for www.educatedguesswork.org. Either of these will direct traffic where I want it.

What's often surprising (and confusing) to people is that there are potentially at least three different organizations involved here. Two of these are obvious:

• The registry (Afilias), who is responsible for the whole top level domain (.org).
• The DNS server operator (Dreamhost) who actually serves the records for my zone.

The third is less obvious: many (most?) users don't deal directly with the registries. Rather, they deal with a registrar which stores their domain name data and then transmits updates to the registry. In my case, Dreamhost is also my registrar (or at least is frontending for my registrar), but there's no logical connection between the two functions it's performing. Indeed, back in the old days people often ran their own DNS servers but they still had to deal with a registrar. Dreamhost is just providing one-stop shopping. Any registry may be served by multiple registrars, but any given domain is associated with a single registrar. A user can transfer their domain between registrars (though not registries, since those are defined by the delegation structure), but it's a bit of a pain, since the registrars obviously want to keep your business.

So, ignoring tampering with the DNS protocol itself (remember, DNSSEC is supposed to secure that), you could imagine trying to attack any of these entities: you could try to convince the DNS server operator to change the victim's records, the registrar to point to a server of your choice, or the registry to hand the records over to a different registry which you could control somehow. If you could manage to do any of these, you could arrange to serve up any records you wanted with the result that traffic got redirected to you rather than the owner of the domain.

Obviously, the victim has an account with both the registrar and the DNS server operator, so you can mount all the standard attacks on the account, login system, password recovery system, etc. For instance, Dreamhost's password recovery feature is of the classic "email confirmation" type. Remember: the operators are not in the business of making your life miserable, but rather of providing service. This makes it hard for them to enforce really rigid recovery policies. You might imagine, of course, that you could have an arrangement with your registrar/operator where you told them that they needed to enforce a much stricter policy, but I don't know if anyone does that now. I do imagine that Google's registrar would think twice before accepting my emailed request to my request for password recovery, but I doubt that would apply to requests for educatedguesswork.org. You can also use ordinary social engineering mechanisms to do fraudulent transfers of a domain name to yourself. This sort of thing has actually happened. Finally, you could imagine fraudulently moving a domain from one registrar to another and then changing the information. This has happened as well, though there are mechanisms you can use (e.g., "registrar locking") to protect your domain from this to some extent.

While I've been primarily talking about addresses above, it should be clear that more or less everything I've just said applies just as well to keying material (public keys, certificates), stored in the DNS. Next: comparing DNS to the certificate infrastructure.