Misery is when you head to one of your usual Web site hangouts and find yourself somewhere nasty instead because of Domain Name System (DNS) poisoning. DNS cache poisoning doesn’t happen often, but when it does happen, it can make large parts of the Internet unusable. The answer to this potential poison problem? Domain Name System Security Extensions (DNSSEC).
DNS poisoning works like this. The DNS is the master address list for the Internet. With it, instead of writing out an IPv4 address like “http://209.85.135.99/,” one of Google’s many addresses, you can simply type in “http://www.google.com” and you’ll be you on your way. But, how can your browser be sure that “209.85.135.99″ is a correct address for Google? By itself, it can’t. It relies on DNS and, here’s the kicker, with plain Jane DNS, the system doesn’t have any built-in way to make sure that the information it’s feeding your browser is the real deal.
DNSSEC attempts to prevent DNS cache poisoning attacks by requiring Web sites to verify their domain names and corresponding IP addresses with DNS servers. To make sure this information isn’t compromised DNSSEC uses digital signatures and public-key encryption for this information exchange. That, in turn, makes it much harder for a cracker to effectively attack a DNS server since for an attack to work it needs to compromise the DNS information for popular Web sites.
The Internet’s 13 root name servers , the master DNS servers, began supporting DNSSEC on July 15. Today, DNSSEC is supported by 55 of the Internet’s 294 top-level domains (TLDs). This includes the TLDs in charge of all the non-profit .org domain and education institutions’ .edu domain. VeriSign is scheduled to start supporting DNSSEC on the .net domain by early 2011.
For most of us, changes at that level really don’t matter. We’re not likely to call on the root name servers or the TLDs for our DNS resolution. Now the switchover to DNSSEC is starting to affect us though. On October 18th, Comcast became the first major ISP to deploy DNSSEC. Indeed, if you want to start using it today, you can. Comcast customers, or anyone else for that matter, can set their DNS servers point to the IP addresses 75.75.75.75 and 75.75.76.76. For more on how to do this, see this Comcast DNSSEC video. If you want to know more about why using DNSSEC is a good idea, the new Web site Practice Safe DNS is chock-full of information.
So, if DNSEC is such a good idea why hasn’t everyone already done it? Well, you see, like any major Internet improvement, some legacy programs and hardware will have trouble with DNSSEC.
The chief problem is that some routers, switches, and firewalls won’t handle DNSSEC packets properly. DNS traffic uses User Datagram Protocol (UDP) and the usual DNS UDP packets are under 512 bytes in size. Thus, the default on a lot of network hardware and software is to reject any UDP packet over 512 bytes. Unfortunately, DNSSEC packets are always bigger than 512 bytes.
On some systems, this will cause DNS failures. Others will fail-over to Transmission Control Protocol (TCP). The downside of using TCP is that it uses significantly more bandwidth than UDP. It’s not a lot, but if you’re in charge of an enterprise network, it can add up to a noticeable increase in latency. And, no one likes a slow Internet.
In addition, some ISPs and DNS servers rewrite DNS answers to redirect their customers to customized search pages when they’re trying to find a non-existent website. For example, I use OpenDNS because it provides faster DNS service than my ISP. But, if I try to go to a domain that doesn’t exist, it pops me into an OpenDNS search page. What would happen if I were using DNSSEC and OpenDNS tried to do this? I don’t know, but I’ve a bad feeling it won’t be good.
OpenDNS, by the by, has elected to go with an alternative way of managing DNS security: DNSCurve. How will DNSCurve work with DNSSEC? Well, it won’t. They try to handle DNS security in rather different ways. What this is likely to mean for users is that you’ll still be able to use DNS, regardless of the security safeguard on the other side, but if they’re not using the same technology, you won’t get any security benefits.
The best thing you can do, as I see it, is to update your in-house DNS software and firmware to the latest DNSSEC-compliant version. You can also check to see if your upstream DNS is DNSSEC ready by following the DNS-OARC guidelines For those of you who aren’t network administrators, you can also run a Java application that will give you a quick, easy-to-understand answer.
If it turns out your ISP isn’t using DNSSEC, send them a note to get on the bandwagon. DNSSEC is coming and the sooner your ISP and you are protected with it, the better.
