5.1. The Criticality of DNS

The correct operation of DNS is vital to any Internet network. We rely on it to translate human-readable names into IP addresses both to organize our computers and to make them easier to work with. Of course, DNS is involved in the reverse process, too: mapping IP addresses to names. DNS plays a vital role in a variety of other Internet services. DNS records enable or help prevent several kinds of man-in-the-middle attacks. DNS records are often used to help distribute Internet traffic between different geographical sites. With the increasing use of IPv6, DNS can be invoked to help distribute public keys in an asymmetric cryptography system.

Your organization probably relies on DNS in a variety of ways. If you have any online presence, then DNS enables your visitors to resolve DNS names to your servers' IP addresses. More importantly, the mapping of names and IP addresses in DNS is critical to your customers' trust of the SSL certificate and connection that you offer them. Your company's email is routed via DNS records. Most modern companies rely heavily on email, and their successful use of email depends absolutely on the correct functioning of DNS. Thus, reliable and accurate DNS records are vital for keeping Internet communications open between your organization and others.

5.1.1. Technical Risks Related to DNS

There are a few ways in which DNS can be attacked that relate directly to the software you run or the data in your DNS zones. Sometimes the absence of data, or the presence of a typo, can create a significant opportunity for mischief.

5.1.1.1 Vulnerabilities in DNS software

Of the two software packages discussed in this chapter, BIND has had the worse track record; numerous and significant vulnerabilities have been found in it over the years. Some have granted root access to remote attackers. With certain versions and certain configurations, the named(8) process could inadvertently execute rogue code on the DNS server. Once any kind of rogue code can be executed, it is often possible to invoke a shell on the system. Once a shell can be executed, an attacker can usually escape a chroot environment with only a little more time and effort.

5.1.1.2 Zone misconfigurations

Zone misconfiguration problems are possible with both BIND and djbdns because they are problems in the zone data itself, not with the DNS server software.

One reasonably common problem in the DNS world is called a "lame" delegation. In this case, your zone file lists the IP addresses of DNS servers that supposedly serve your domain. However, one or more of the listed IP addresses is not serving your domain. Perhaps it is not running any DNS software at all, or the host is down or unreachable, or perhaps the IP address is mistyped. Most frequently the server is your slave server, but someone forgot to give it the zone information. In any case, the situation has two different impacts on your organization: it creates slightly slower performance on domain lookups, and it opens the opportunity for hijacking of your domain. If you list two domain servers in your zone and one of them is lame, then half the time people will try the lame IP address first. They wait for a response, often up to 30 seconds depending on their particular system and its settings. Eventually they give up and try the other nameserver, which works.

The other problem with lame delegations stems from the fact that every IP address belongs to someone. If you accidentally mistype an address in the zone file, then the person who controls that IP address can set up a DNS server that claims to serve your domains. Suddenly your customers might end up browsing a competitor's site, or your employees might end up connecting to a hacker's machine instead of your VPN gateway.

5.1.1.3 Missing zone information

Like bad zone data, missing zone data can create problems. The effects are the same with BIND or djbdns. There are a small variety of attacks that can be launched because of missing zone data.

In DNS terminology, "forward" zones are those that map a name to an IP address. The corresponding "reverse" zones map IP addresses to names. In order to be standards compliant and to resist some kinds of attacks, every machine that has a DNS entry should have both a forward and a reverse map. That is, if www.example.com is 12.34.56.78, then there should be an entry in the 56.34.12.in-addr.arpa zone that maps 78 to www.example.com.

Matching forward and reverse records serves as a confidence indicator on the Internet. They imply that the IP address and name are under the same administrative control. Internet hosts tend to be suspicious of a server that does not have matching forward and reverse records in DNS. Some mail servers will refuse to take mail from a system that has no reverse record. All modern web browsers will warn their user if the browser makes an SSL/TLS connection to a web server that does not have matching reverse records. If you want to avoid casting doubts in the minds of your users, you should make sure that any secure web server has matching A and PTR records. This is true even for an intranet web server.

5.1.2. Risks Related to DNS and Mail

MX records in DNS are vital to today's email-dependent businesses. They determine where email for a given domain name goes. Typically, you have at least one MX record for your domain. Ideally, you have additional MX records for all the hosts in your externally published domains as well. To be safest, you have multiple MX records for all your hosts. Multiple MX records allow for fastest recovery when your primary mail server is unavailable.

When a standards-compliant mail transfer agent (MTA) wants to determine the correct mail server for a domain, it uses DNS. Consider the fragment of a BIND zone file shown in Example 5-1.

Example 5-1. MX records in a BIND zone file

$ORIGIN example.com. $TTL                86400 example.com.                 A         12.34.56.78                 MX        10 mail-a.example.com.                 MX        20 mail-b.example.com. www             A         12.34.56.78                 MX        10 mail-a.example.com.                 MX        20 mail-b.example.com. mail-a          A         12.34.56.79                 MX        10 mail-a.example.com.                 MX        20 mail-b.example.com. mail-b          A         12.34.56.80                 MX        10 mail-a.example.com.                 MX        20 mail-b.example.com.

In this example, an MTA trying deliver mail to an address ending in @example.com will try to connect to the server named mail-a.example.com, whose IP address is 12.34.56.79. If that server does not respond for some reason, the sending MTA will try mail-b.example.com. If the first server does respond, but rejects the email for some reason (e.g., an invalid destination address), the sending MTA does not try the other server.

Notice the additional numbers on the MX lines. They indicate a relative priority between the different possible mail servers. The lower the number (with zero being the lowest valid number), the higher the priority. That is, the lowest numbered server is tried first. Servers with equal numbers are tried in random order.

There are two security considerations involving MX records in DNS: all the records must match, and you should consider where your email might go.

Make sure that all your MX records, and their corresponding A and PTR records all match up. In an effort to crack down on unsolicited, bulk email ("spam"), some mail servers will categorically reject email from your mail server if all its DNS records do not match. Lost or significantly delayed email can be very costly or disruptive to your organization, or perhaps to another organization that is closely related to you.

As a redundancy measure, some businesses have backup mail servers. Because they are listed in your DNS zones, they receive your email when your primary server does not respond. Backup mail servers are most effective if they are on different networks and in different data centers than your primary server. If both the primary and backup are in the same data center, with the same connectivity to the Internet, then the Internet connectivity and the data center are single points of failure for email. If the one link to the Internet goes down or if the data center loses power, for example, both primary and backup mail servers become unavailable.

Backup mail service can create risks, however. Many small and medium-sized businesses cannot afford to operate mail servers in geographically distributed data centers. They often arrange for their Internet provider or another ISP to be their backup mail server. If the ISP that serves as a backup is less well protected than the organization's primary mail server, an attacker can try to compromise the backup mail server instead.

Given that DNS records of backup mail servers are public, the attacker can spend time analyzing your IP addresses and the backup mail server's susceptibility without ever probing your primary data center. It is absolutely critical, therefore, to consider how well protected any backup mail servers are when setting up your MX records in DNS.

5.1.3. Risks Related to DNS Attacks

Your DNS can be attacked by attacking the servers directly, by attacking servers you trust, or by attacking the domain registration, which seeds DNS. Each of these attacks can be mitigated or at least resisted through the best practices we describe in "Responding to DNS-Based Risks."

5.1.3.1 Cache poisoning

Cache poisoning is a DNS attack that was more popular a few years ago than it is today. Attackers maliciously configured DNS servers to send incorrect, superfluous records when responding to legitimate queries. This extra data is sent in the "additional" section of the DNS response. The additional section of a response is often used as a convenience for the server to provide relevant information that was not specifically requested but is related to the original query. For example, if I ask the authoritative example.com server for its MX record, it will send me the MX record. It will probably also put the A record (the IP address) of the mail server in the additional section, if the mail server is in the example.com domain.

The surprising thing is that older versions of BIND would store additional information as if it was authoritative. It did not matter that the bogus information did not come from the right server. The next time someone would query that BIND server (again, your organization's caching server), it would use the bogus data as if it were authoritative.

While this attack is no longer a major threat (it has been solved in BIND for years and was never a problem for djbdns), it highlights two important concerns. First, it demonstrates the value of running a secure DNS resolver for your organization. Second, it shows how the utter lack of authentication between DNS servers creates a variety of trust problems that are hard to solve.

5.1.3.2 DNS spoofing

Some DNS abuse is possible because DNS uses User Datagram Protocol (UDP) datagrams for most messages. Simple UDP messages carry no authenticating information other than the IP address of the sender which can easily be forged. Despite the fact that both BIND and djbdns guard against cache poisoning now, spoofing is harder to protect against. DNS needs to use UDP for a variety of reasons, efficiency being the most obvious. An unavoidable consequence of using UDP, however, is that spoofing is quite easy unless the DNS protocol itself adds authenticating information.

If any system on the Internet can monitor traffic between your caching server and the Internet, it can attempt to launch a spoofing attack against your users. It waits for a request for something like www.yahoo.com to be transmitted from your site to the Internet. Then it injects a response that looks legitimate. If the attacker knows in advance a certain set of sites (such as Yahoo!) that he will be attacking, he will craft his forged responses so that they even appear to originate from the correct IP addresses (i.e., yahoo.com's nameservers). Just like in the cache poisoning attack, the attacker has now inserted records into your server's cache. Your DNS server now believes his spoofed packet simply because it answered the question that was asked.

Monitoring a WAN line for such traffic, crafting the correct response on the fly, and injecting that response at the right time is tricky, but not impossible. There is a proof-of-concept program called the "Denver Project" (http://www.ilionsecurity.ch) that implements a simple LAN-based DNS spoofing tool.

5.1.3.3 Registration hijacking

There are a variety of ways that you can lose control of your domain altogether by losing control of its registration. Your domain expires from the Internet registry unless someone pays the renewal fees when they are due. There are professional scam artists who snap up lapsed domains and register them. They often demand high ransoms to return ownership. Although U.S. trademark law can help fight them off, the courts are slow and your organization can completely lose the use of your domain while the hijacking is sorted out in the courts.

Some attackers have successfully forged registration transfer agreements that convinced registrars to change ownership of domains. They forge documents, email messages, or whatever is necessary to persuade the registrar that they now control the domain. Then, they can control the NS records that appear in the root top-level domain (TLD) servers (e.g., the .com, .org, or .net nameservers). Suddenly the nameservers that serve your domain are not your nameservers, but are someone else's. Using an attack like this, an attacker can route all web traffic through transparent proxies at his site, or route all email through his own proxy mail server. He can monitor Internet communications by causing DNS lookups to resolve to his IP addresses instead of yours. Then he sets up proxy services that actually look up (using your nameservers) and connect to the correct real servers. Carefully done, this attack can proceed for a long time with few symptoms.

It is critical that you use a trustworthy domain registrar and that you stay up to date on all domain registration requirements. An occasional check with the registrar's web site is a good idea as well, to make sure nothing has unexpectedly changed. Be sure to treat the access codes (user ID, password) to the registrar's web site as confidential, as you would any other administrative password.

5.1.4. Responding to DNS-Based Risks

There are many different "best practices" that address various security concerns. They do not necessarily improve efficiency, maintainability, or manageability of your nameservers. They are worthwhile if you suspect your organization is exposed to some of the risks above. It is not usually a good methodology to simply invoke every possible security feature just because it exists. You should consider the threats that your organization faces, and which DNS features you use, and then apply the mitigations recommended below that make sense.

Depending on whether you use BIND or djbdns, you have different options for best practices. With djbdns you often get fewer choices with respect to security posture. The authors have chosen a specific stance on a particular risk, and that is the stance all djbdns users are forced to take. The default djbdns configuration will create a secure system that needs little or no tweaking. BIND, on the other hand, offers myriad security options. Virtually all BIND installations make use of several options to improve on the default security posture of a BIND configuration.

5.1.4.1 Limit recursion

A recursive query happens when a server looks up the answer to a client's query on the client's behalf. A client asks the server for a name that the server does not know and indicates that it would like the server to search for the answer if necessary. The server performs the various tasks of consulting the root domain servers, global top-level domain servers, or other servers as necessary to fulfill the client's request. If you run an externally facing DNS server whose only purpose is to answer authoritatively for your domain, it should not answer recursive queries. They consume unnecessary resources in CPU and bandwidth. More importantly, BIND has had several widely publicized bugs in its recursion algorithms, some of which completely compromised the server. This is a case where it is prudent to turn off a feature of BIND if you are not making use of it.

As with other BIND bugs, djbdns does not suffer this problem. Its authoritative server (tinydns) and its recursive server (dnscache) are different processes that usually run in different sandboxes, if not on different physical servers. It is hard to have unnecessary recursion on an authoritative djbdns server.

5.1.4.2 Limit zone transfers

There is no legitimate reason for anyone outside your organization to transfer your zones in bulk. A zone transfer request asks your DNS server to send all the zone information: hostnames, mail server records, nameserver records, etc. Although all this information is publicly available through your DNS server, there is no reason to make an attacker's life easier. Restricting zone transfers makes hackers' lives just a little harder and has absolutely no detrimental impact on legitimate use of DNS.

In BIND's named.conf file, you can create sets of trusted hosts who are allowed to transfer your zones, and then refer to that set of hosts later in each zone's configuration block. Example 5-2 shows an access control list (ACL) of two hosts that are allowed to transfer the zones in bulk.

Example 5-2. Restricting zone transfers with IP addresses in BIND

acl trusted-servers  {         12.34.56.78;  // our name server         23.45.67.89;  // our ISP }; zone example.com  {         type master;         file "zones/example.com";         allow-transfer { trusted-servers; }; };

Note that cryptography is far more difficult to spoof than IP addresses. To be even more careful about who can transfer zones, you can use transaction signatures (TSIG) to authorize zone transfers. (See "Transaction Signatures (TSIG)" for more information.)

Unauthorized zone transfers are primarily a BIND concern. If you use djbdns, you have to go to a lot of effort to enable even authorized zone transfers. The recommended way to synchronize zones in djbdns is to use rsync(8) and ssh(1) to copy the zone data from the master to the slaves. Clearly you will only enable such access between systems that you trust. It is highly unlikely that a host will be able to inadvertently download your zone information through rsync and ssh.

5.1.4.3 Maintain your own zones

One of the reasons that forward and reverse records often fail to match is because they are owned and distributed by different entities. You own your domain name (the forward mapping), but someone else owns the reverse map. Often that someone else is your upstream connectivity provider, but it may be ARIN, RIPE, or a carrier upstream from your immediate ISP. If your organization changes names frequently, or if you have many different public IP addresses to manage, you may find your upstream provider unwilling to make changes in the reverse maps as often as you would like. There is an elegant solution to this, but it may be too subtle for your upstream provider. They can delegate the name service responsibility for your chunk of addresses to your server. Consider Example 5-1, in BIND syntax, showing a chunk of our fictitious 12.34.56.X zone. Let's assume that our company example.com has been granted the IP addresses 12.34.56.72 through 12.34.56.80. The zone file in Example 5-3 shows how our upstream DNS provider can delegate the reverse PTR records to us for our IP addresses while maintaining direct control of the reverse records for other IP addresses.

Example 5-3. in-addr.arpa zone with delegations

$ORIGIN 56.34.12.in-addr.arpa. $TTL 86400        ; 1 day. ... 70                PTR        mail.othercustomer.com. 71                PTR        www.othercustomer.com. 72                CNAME      72.example-com.56.34.12.in-addr.arpa. 73                CNAME      73.example-com.56.34.12.in-addr.arpa. ... 81                PTR        mail.somebody.com. ... example-com       NS         ns1.example.com.                   NS         ns2.example.com.

In this situation, a client looking for the PTR record for 72.56.34.12.in-addr.arpa, will not find it here. Instead, it finds CNAME records that point to a subdomain of 56.34.12.in-addr.arpa. This subdomain, named example-com to help an administrator remember who it serves, is then delegated to the example.com nameservers. The client then queries the nameservers, either ns1.example.com or ns2.example.com, and finds the correct information from them. This technique is recommended and explained more fully in Chapter 6.5 of the DNS and Bind Cookbook, which is listed in the Section 1.7 section at the end of the chapter.

If you can get your upstream ISP to delegate the reverse records, then you gain a valuable measure of autonomy. You can update the reverse records as you need to without the intervention of your ISP. There are many advantages to such a situation. If a sudden problem causes you to switch to a backup data center where the IP addresses were different, you would want to be able to update the reverse records on your SSL-enabled web servers. Otherwise, visitors to your backup web servers would receive warnings about your SSL certificates. Likewise, when you bring new systems online with public IP addresses, or decommission old systems, you can trivially set the reverse records to be correct without having to interact with your upstream ISP.

ISPs may be reluctant to delegate the reverse records to you, however. You could use the reverse record to advertise your IP address as www.yahoo.com or some other domain that you don't own.

5.1.4.4 Run secure, organization-wide recursion servers

For resolution of domains other than your own, you should run all queries through one or more servers that perform recursive queries on behalf of internal workstations. They will live in your DMZ, and will need to talk to both internal and external hosts. This arrangement offers two kinds of security: it protects individual client systems inside your organization, and it limits the potential damage from malicious DNS attacks. This arrangement is depicted in Figure 5-1.

Centralized recursive queries allow the IT staff to direct all DNS traffic through just the authorized recursive, caching servers. This means that the firewall can prevent all DNS traffic flowing into or out of the organization, except for that going to the caching servers. Some Trojan programs use bogus DNS requests as a covert channel back to a controlling server. They install and lay dormant until the control system gives them a command. They send malformed DNS queries to their command server and receive responses that indicate what to do (such as participate in a DDoS attack). If DNS must pass through a central query server, then such covert back-channels are prevented or hindered.

Centralizing recursion usually means that queries will be faster because records will frequently be cached. Additionally, if there are recursion or cache-poisoning bugs in the resolvers of your internal workstations, those bugs will not be exploitable by an outside attacker. You have more time to get an effective patch tested and deployed because the buggy DNS functionality is not directly exposed.

5.1.4.5 Separate caches from authoritative servers

Even if you use BIND, which can run both caches and authoritative servers in the same process, you should separate them. It is not necessary to separate them onto different physical machines, however.

If you are using FreeBSD and want to keep both processes on the same system, you can run them in separate jails, each with its own IP address. Likewise, on OpenBSD, two processes can be run in different chroot environments, and each can be assigned a different IP address.

This separation of duties is a fundamental security principle. In this case, you are protecting your authoritative server from cache-oriented attacks. If an attacker sends a flood of queries or a series of poisoned responses to your cache server, you do not want them to affect your authoritative server.

5.1.5. Summary

You may have noticed a trend among the various security vulnerabilities and problems we cited above. Many problems exist with BIND that simply do not exist with djbdns. This is not surprising, however, since djbdns was written to solve them. Though djbdns explicitly addresses many of BIND's problems, it does not offer many of the usability features that BIND offers. Usability and security often find themselves at opposite ends of a functionality axis. BIND has chosen one point on the axis, and djbdns has chosen another. Deciding which one addresses the needs of your environment will be up to you.