Five Basic Mistakes Not to Make in DNS

Here are five things you can do to make sure your DNS is in good shape and not causing problems for the rest of the Internet, which, by the way, also includes you.

DNS Is Really, Really Important

Every time we get email, access a web page, make a VoIP call, or complete many other tasks, we use the Domain Name System (DNS). That makes DNS part of the critical infrastructure of the Internet.

This article describes five things that you can do to keep you and your organization safe as well as reduce unnecessary load on the DNS infrastructure:

Reverse-Map Private (RFC1918) IP Addresses in Your DNS

Ensure That Localhost Is Forward- and Reverse-Mapped

Ensure That Your Domain Name Does Not Have a Lame Delegation

Ensure That You Are Not Running an Open Recursive Name Server

Ensure That Your Email Address Is Correct in the SOA RR

For each of the items discussed, the corrective actions and BIND configuration (named.conf) or zone file fragments are included.

Some DNS Background

DNS is a complex, highly distributed system that operates on the hierarchical structure of domain names, so it is worth briefly covering some background.

In tech speak, DNS resolves a name (domain name) into an IP address using a series of queries to authoritative DNS servers until the final answer, an IP address, is obtained. This process is referred to as forward mapping and is done in units called zones, which correspond to each level of the hierarchy of the domain name. To resolve the name www.example.com, a local DNS server will query authoritative DNS servers for each level in the name, beginning with the root-servers, which will return a referral to the authoritative .com gTLD servers. The gTLD server, when queried, will return a referral to the authoritative name servers for the domain example.com, which finally will return the IP address we require. Sometimes it also useful to be able to start with an IP address and find the name allocated to it; email systems especially use this technique as part of an antispam arsenal. DNS performs IP address-to-name translation by manipulating the IP address and using reverse-mapped zones under the reserved domain name IN-ADDR.ARPA.

There are two broad classes of DNS servers:

DNS servers that operate on behalf of a group of users, either on a local network or within a larger organization--say, an ISP--and that provide what are called recursive services. These DNS servers will issue queries and follow any referrals to ensure their clients get the required answer. Such DNS servers typically maintain a cache of answers to save them from issuing the same query repeatedly, and for that reason are frequently called caching name servers or recursive name servers, or sometimes just resolvers. DNS records are maintained in the cache for a period determined by the Time to Live value associated with each Resource Record (RR).

DNS servers that are either defined to be a master or a slave for the zone. The Resource Records obtained from these servers in answer to a query are marked with a special bit (AA) to indicate they come from an authoritative source. These servers are, not too surprisingly, typically called authoritative name servers.

Now, by way of illustrating the sometimes confusing nature of the DNS, some organizations (especially smaller ones) elect to run both caching and authoritative functions in the same name server. While this is not a recommended practice for reasons that we shall see later, it may be simply a pragmatic solution. Finally, each PC has what is sometimes, but erroneously, called a resolver, which typically caches results. In fact this is almost always a stub-resolver that needs the services of a caching or recursive name server to operate effectively, since it is incapable of following referrals.

The root servers are always the starting point for any new query cycle, which makes them the critical part of the critical infrastructure! There are 13 root-servers named a.root-servers.net through m.root-servers.net. Using anycast techniques, these servers are replicated across the globe. There are now well over 100 instances of the various root-servers in operational use, the majority of which now lie outside North America. The root-servers receive more than 2 billion queries per day, of which (according to some studies [6],) only 2% are legitimate queries! While the vast majority of unnecessary traffic relates to buggy software and badly configured firewalls, a significant proportion was caused by poorly configured DNS software.

So with all this information at our fingertips, let's look at five DNS issues that you should check to minimize unnecessary traffic on the DNS infrastructure, and help keep your organization running smoothly.

Reverse-Map Private (RFC 1918) IP Addresses

Up to 7% of the total traffic arriving at some root servers consists of reverse queries for private IP addresses, and a complete routing infrastructure (AS112) has been constructed just to handle this problem. Private IP addresses are any in the ranges 192.168.0.0/16, 172.16.0.0/12, and 10.0.0.0/8. While ISPs are delegated the task of reverse-mapping public IPs, they have no such responsibility for private IP addresses. If you are running your own local recursive name server, it is your responsibility to make sure these IP addresses are reverse-mapped in your DNS configuration.

To illustrate reverse-mapping a zone, let's assume that we are using a private address range, 192.168.5.0/28 (16 IP addresses only). BIND's named.conf file defines the reverse-mapped zone and should look something like this:

The zone filename convention above uses 192.168.5.rev to make it simpler to understand, whereas the zone name must be 5.168.192.IN-ADDR.ARPA. If you really enjoy writing reversed addresses, however, you could use "5.168.192.in-addr.arpa" as the filename. Reverse maps are standard zone files, and may use zone transfers to update the slave (secondary) name server. The allow-transfer statement just limits the source of zone transfer requests to the slave name server. The allow-update statement is precautionary, and should be removed if you are auto-updating from DHCP or another source. The reverse zone fragment would look like this:

All the righthand names in this file must be Fully Qualified Domain Names (FQDNs). That is, they must terminate with a dot. If the dot at the end of mail.example.com was omitted, the $ORIGIN substitution rule would generate a name of mail.example.com.5.168.192.IN-ADDR.ARPA, which was probably not the intended result.

Ensure That Localhost Is Forward- and Reverse-Mapped

Just over 1% of the queries at the root-servers in one of the studies were for localhost. This means that in the study case, which was a subset of the total root-server query load, there were more than 12,000 DNS configurations with no localhost zone defined. Localhost is used by many applications as shorthand when referring to the local PC, and is always mapped to the loopback address 127.0.0.1 (or ::1 for Ipv6). Apart from creating unnecessary root-server traffic, it will slow down applications considerably. To resolve localhost (and its reverse map) the BIND named.conf file should have the following zone files:

The localhost forward-mapped zone file is normally supplied with most BIND distributions and may be called localhost or localhost.zone. The reverse-mapped zone file--again typically supplied with BIND distributions--is normally called something very meaningful like named.local, which may help explain why it was omitted in more than 12,000 configurations. The localhost zone may be treated as shown, with a master/slave configuration (in which case the allow-transfer statement is used to limit the transfer request source,) But in most cases, because the zone file is distributed with BIND, it is more normally defined as a master in all cases.