Chapter 3: Securing the Domain Name System

Overview

Today's Internet relies heavily on a large number of distinct and simple protocols, many of which have been scaled to their conceivable limit to keep up with the growth of the global network. The Domain Name System (DNS) is a perfect example of such a protocol, though many would consider it theoretically infinitely scaleable. Originally designed for simply translating easy-to-remember names (like http://www.vostrom.com) into hard-to-remember quad- dotted decimal notated numbers (like 69.16.147.21), DNS is now relied upon for virtually all significant applications that ride over the network. To qualify this remark, one must consider that without DNS, e-mail would cease to be delivered, web site names would not resolve, and even if numeric addresses were typed in their place, modern digital certificate validation methodologies and reverse-lookups adopted for security enhancements would render most numeric addresses useless when used apart from DNS. Attempts to add embedded security mechanisms into DNS, such as the DNSSEC initiative, have been slow to proliferate and gain industry acceptance. And in the case of DNS, scalability, reliability, and improved performance seem to outweigh the call for enhanced security in the near term . DNS, as it exists today, is a major challenge to security, and nearly every major network service you rely upon hangs in the balance. In this chapter, we'll discuss some of the little-known implementation techniques that will help you secure your critical DNS infrastructure and explain the dangerous realities of weaknesses in the design of the DNS protocol itself.

This chapter will cover the following:

DNS Background and Function A brief explanation of the DNS protocols and how they came to be.
Information Disclosure How DNS-based information disclosure can inadvertently allow an attacker to map your network.
Global Weaknesses Problems with the global implementation of DNS and how they might affect your organization.
Your Organization's DNS Servers An explanation of common threats and how to avoid them or mitigate their impact.

Background and Function

As DNS is one of the most important protocols in use on the Internet today, we'll begin with some background. Afterward, we'll discuss modern-day security considerations and what you need to look out for when contemplating DNS security within your organization.

History Lesson

Paul Mockapetris formally introduced the world to DNS in late 1987 when he published RFCs 1034 and 1035. While a great deal of work had been done prior to that (detailed in IEN 116, RFC 799, RFC 819, RFC 830, RFC 882, and RFC 883), Mockapetris consolidated the ideas of hierarchical name space, using the "." character as the boundary between levels in the hierarchy, common character encoding, a completely distributed database for storage, and such sophisticated concepts as local caching, cache invalidation and management, and even an extensible class-based query mechanism to allow for more complicated, application-specific uses of DNS. Some of these features have only recently been tapped by anti-spam applications, and so on. While this is all very impressive for a first run at such a critical protocol, the unfortunate reality is that DNS basically stopped evolving almost immediately. While this in itself proves that the design was excellent , it also lulls software vendors and global communications organizations into a state of adequacy that, when compounded over years , results in apathy towards continued improvement of the system and essentially invites security threats. The good news is that a few individuals have dedicated much of their lives and resources to improving the stability of DNS and staying one step ahead of aggressors. Most notable is Paul Vixie, co-founder of the Internet Systems Consortium (ISC) and the modern architect of the most prevalent DNS software package, BIND.

Note	More information on BIND, ISC, and Paul Vixie may be found at http://www.isc.org/.

DNS Functionality and Security Considerations

While the RFCs make interesting reading, a two-minute primer on DNS is all you need to know in order to understand its overall design. The system itself is elegant in its simplicity and impressive in its proven scalability. The most important overall concept in DNS is the use of hierarchical name spaces and the use of the dot character (".") as the delimiter between name spaces. As an example, to reach a system with the name "http://www.vostrom.com," we must query the DNS server responsible (the authoritative server) for systems or subdomains within the "http://vostrom.com" domain. Since we don't know what those servers are, we must first query the top-level domain (TLD) server for ".com" to ascertain the addresses for those authoritative servers. However, we don't know the TLD's authoritative servers to ask, so before doing any of these things, we begin with the unwritten "." that is really at the end of all domain names the systems commonly referred to as the DNS "root" servers. The DNS root servers are referenced by 13 IP addresses that the DNS resolver software can always start from in order to walk the DNS hierarchy to eventually get us the address that corresponds with our original query. An up-to-date list of these servers and other related information may be found at http://www.root-servers.org. As long as our DNS resolver can reach one of these root DNS servers, it will be able to walk the hierarchy step by step, finding the appropriate TLD server for ".com," which it will then query in order to find the authoritative servers for "http://vostrom.com," querying them for the authoritative servers (or in this case, our final answer) for "www." While the root was originally designed to handle the first two of these steps, TLD servers were created in order to provide another degree of separation in order to split up (and politically decentralize) the work of country-code TLDs (ccTLDs) and the generic TLDs (gTLDs). We won't be notified of any of these steps unless there is an error as the DNS resolver software is recursively doing this work for us as a proxy, so to speak. While there are several tools that help us research every stage in this chain manually, there is also a nice tool that shows it happening visually-dnstracer, by Edwin Groothuis. By using dnstracer, we can ask it to start at the root ("-s.") and to ignore any locally cached information ("-c"), while displaying the steps it takes finding the information we're seeking beginning with the root:

> dnstracer -c -s . http://www.yahoo.com
Tracing to http://www.yahoo.com via A.ROOT-SERVERS.NET, timeout 15 seconds
A. ROOT-SERVERS.NET [.] (198.41.0.4)
 \___M.GTLD-SERVERS.NET [com] (192.55.83.30)
     \___ns5.yahoo.com [yahoo.com] (216.109.116.17) Got authoritative answer
     \___ns4.yahoo.com [yahoo.com] (63.250.206.138) Got authoritative answer
     \___ns3.yahoo.com [yahoo.com] (217.12.4.104) Got authoritative answer
     \___ns2.yahoo.com [yahoo.com] (66.163.169.170) Got authoritative answer
     \___ns1.yahoo.com [yahoo.com] (66.218.71.63) Got authoritative answer
 \___E.GTLD-SERVERS.NET [com] (192.12.94.30)
     \___ns5.yahoo.com [yahoo.com] (216.109.116.17) Got authoritative answer
     \___ns4.yahoo.com [yahoo.com] (63.250.206.138) Got authoritative answer
     \___ns3.yahoo.com [yahoo.com] (217.12.4.104) Got authoritative answer
     \___ns2.yahoo.com [yahoo.com] (66.163.169.170) Got authoritative answer
     \___ns1.yahoo.com [yahoo.com] (66.218.71.63) Got authoritative answer
 \___K.GTLD-SERVERS.NET [com] (192.52.178.30)
     \___ns5.yahoo.com [yahoo.com] (216.109.116.17) Got authoritative answer
     \___ns4.yahoo.com [yahoo.com] (63.250.206.138) Got authoritative answer
     \___ns3.yahoo.com [yahoo.com] (217.12.4.104) Got authoritative answer
     \___ns2.yahoo.com [yahoo.com] (66.163.169.170) Got authoritative answer
     \___ns1.yahoo.com [yahoo.com] (66.218.71.63) Got authoritative answer
 \___J.GTLD-SERVERS.NET [com] (192.48.79.30)

... ad nauseum through the last of the thirteen root servers.

Whenever we explain this process to people, we are usually asked, "Where do I get the root server addresses in order to start this whole sleuthing process?" Their addresses are stored on your disk or, rather, your name server's disk. DNS server software packages come prepackaged with a root server listing in the form of a DNS cache file (also sometimes called the hints file) that lists the 13 root DNS servers (A through M) in the form of {A-M}.ROOT-SERVERS.NET and their corresponding IP addresses. This file should be updated periodically, though root server IP address changes seldom occur. Obviously, the security of this specific file on your name server's hard disk is of paramount importance. In fact, the security of every server in the lookup chain described above is critically important.

Tip	Visit http://www.root-servers.org for a table of all the root DNS servers, the latest root hints file, and news about root DNS operations.

Often we are asked, "Why are there specifically 13 root servers?" The little-known reason is actually quite sensible : The maximum size of a UDP DNS datagram is 512 bytes, by convention. Therefore, there is enough room in the payload portion of one UDP DNS datagram for only 13 IP addresses. The datagram size convention exists because: (1) most DNS-related questions and answers ought to fit into this space, and (2) network modeling at the time the decision was made suggested that UDP datagrams smaller than 512 bytes made it through the network with high reliability. Because DNS design and operations are highly focused on performance (the speed at which a response to any given query is obtained across the network), UDP was selected and the datagram size was a key factor in the designers' hopes to avoid fragmentation, which introduces latency and reduces reliability. Another consideration to keep in mind is that many modern firewalls and intrusion detection sensors are aware of this convention and DNS datagrams exceeding 512 bytes (sometimes as low as 256 bytes) are often filtered. While this size constraint isn't normally a consideration in the realm of UNIX and UNIX-like network operating systems, Microsoft's DNS server software contains an Extension Mechanisms for DNS (EDNS0) subsystem (see RFC 2671, Extension Mechanisms for DNS (EDNS0)), which often generates UDP datagrams larger than 512 bytes (commonly doubling or even tripling the regular per-datagram size). However, the EDNS0 features may be administratively disabled in the software to avoid compatibility problems. So, what happens when a DNS client queries a server for a record whose complete response is larger than 512 bytes? The DNS server software limits the size of the response (by truncation ) at 512 bytes, and sets the "TC" bit in the response header. When the client's resolver (cache) encounters the TC bit, it is supposed to automatically retry the query using TCP instead of UDP. Except in the case of djbdns (an alternative DNS server software discussed later in this chapter), DNS server software will respond to any valid query made over TCP in addition to UDP. Generally speaking, DNS messages 512 bytes or smaller should be transmitted using UDP while DNS messages 65,535 bytes or smaller (greater than 512 bytes) should be transmitted through TCP. djbdns, an alternative name server software package discussed later in this chatper, logically separates functions that require TCP as a security enhancement.