Securing the Domain Name System

44 COPUBLISHED BY THE IEEE COMPUTER AND RELIABILITY SOCIETIES ■ 1540-7993/09/$26.00 © 2009 IEEE ■ SEPTEMBER/OCTOBER 2009 T he Domain Name System (DNS) 1 is the Internet’s de facto name resolution system. In fact, almost every transaction performed on the Internet is prefaced by a DNS lookup—for example, when a user types “www.bankofamerica.com” into his or her Web browser, it issues a DNS request to get Bank of America’s IP addresses. However, in today’s Internet, attackers can spoof DNS messages. The DNS Security Extensions (DNSSEC) RFCs specify how DNS domains (logical namespaces such as bankofamerica.com) can use cryptographic keys to digitally sign their content and gain the protection of origin authenticity, data integrity, and secure denial of existence. DNSSEC specifies that each reply from authoritative DNS servers will have cryptographic signatures attached to it. DNS resolvers (clients) can obtain cryptographic keys for each domain and then formally verify that the key generated the signatures, the correct DNS server originated the data the signatures cover, and the data wasn’t modified on the way to the resolver. However, resolvers must ensure that the keys they have for a domain are authentic and not spoofed. Although DNSSEC’s deployment has grown, the mechanisms by which resolvers can obtain and verify domains’ cryptographic keys haven’t evolved as needed. Specifically, it was envisioned that resolvers would begin with a trusted key for the DNS root domain (“.”) and recursively trace a secure delegation chain (chain of trust) from parent domains to their children until the resolvers reached the domain containing the queried name. For example, a resolver might want to get the A records (which contain IPv4 addresses) for the domain www. foo.com. This would require it to ask the root domain “.” to refer it to the com domain, and then the com domain would refer it to the foo.com domain. At that point, the foo. com domain would be able to respond to the www. foo.com query. One essential problem facing DNSSEC deployment today is that neither the root nor many of the top-level domains (TLDs, such as com) have deployed DNSSEC. Consequently, DNS resolvers don’t have an automated way to verify whether the keys they have for foo.com are valid or spoofed by an adversary (unless the keys are configured into the resolvers as trust anchors via some unspecified, out-ofband process). In this article, we examine the space of various cryptographic key management issues involved in DNSSEC deployment and the approaches resolvers might use to identify the proper keys (trust anchors) for the DNS domains they visit. Further examination into these mechanisms leads to many more subtle issues that arise from how we currently manage the DNS.