Essential DNS Concepts

We begin with a look at the ideas behind DNS, prior to discussing the details of the software used to implement it. An understanding at this level is invaluable in avoiding the majority of problems that administrators commonly experience with DNS, as well as in diagnosing and quickly solving the ones that do occur. The following overview omits several small details in the protocol because they are not relevant to the everyday tasks of a DNS administrator. If you need more information about DNS, consult the DNS standards, especially RFC 1034. The RFCs related to DNS are distributed with BIND. Fedora installs them in /usr/share/doc/bind-*/rfc/.

The domain namespace is structured as a tree. Each domain is a node in the tree and has a name. For every node, there are resource records (RRs)each of which stores a single fact about the domain. (Who owns it? What is its IP address?) Domains can have any number of children, or subdomains. The root of the tree is a domain named . (similar to the / root directory in a file system).

Each of the resource records belonging to a domain store a different type of information. For example,

• A (Address) records store the IP address associated with a name.

• NS (Nameserver) records name an authoritative nameserver for a domain.

• SOA (Start of Authority) records contain basic properties of the domain and the domain's zone.

• PTR (Pointer) records contain the real name of the host to which the IP belongs.

• MX (Mail Exchanger) records specify a mail server for the zone.

Each record type is discussed in detail later in this chapter.

Every node has a unique name that specifies its position in the tree, just as every file has a unique path that leads from the root directory to that file. That is, in the domain name, one starts with the root domain "." and prepends to it each name in the path, using a dot to separate the names. The root domain has children named com., org., net., de., and so on. They, in turn, have children named ibm.com., wiw.org., and gmx.de..

In general, a fully qualified domain name (FQDN) is one that contains the machine name and the domain name, such as

foo.example.com.

This is similar to the following path:

/com/example/foo

Contrary to the example, the trailing dot in an FQDN is often omitted. This reverse order is the source of confusion to many people who first examine DNS.

How Nameservers Store DNS Structure Information

Information about the structure of the tree and its associated resource records is stored by programs called nameservers. Every domain has an authoritative nameserver that holds a complete local copy of the data for the domain; the domain's administrators are responsible for maintaining the data. A nameserver can also cache information about parts of the tree for which the server has no authority. For administrative convenience, nameservers can delegate authority over certain subdomains to other, independently maintained, nameservers.

The authoritative nameserver for a zone knows about the nameservers to which authority over subdomains has been delegated. The authoritative nameserver might refer queries about the delegated zones to those nameservers. So, we can always find authoritative data for a domain by following the chain of delegations of authority from . (the root domain) until we reach an authoritative nameserver for the domain. This is what gives DNS its distributed tree structure.

How DNS Provides Name Service Information to Users

Users of DNS need not be aware of these details. To them, the namespace is just a single treeany part of which they can request information about. The task of finding the requested RRs from the resource set for a domain is left to programs called resolvers. Resolvers are aware of the distributed structure of the database. They know how to contact the root nameservers (which are authoritative for the root domain) and how to follow the chain of delegations until they find an authoritative nameserver that can give them the information they are looking for.

At the risk of stretching the analogy too far, you can think of domains as directories in a file system and resource records as files in these directories. The delegation of authority over subdomains is similar to having an NFS file system mounted under a subdirectory: Requests for files under that directory would go to the NFS server, rather than this file system. The resolver's job is to start from the root directory and walk down the directory tree (following mount points) until it reaches the directory that contains the files the user is interested in. For efficiency, the nameservers can then cache the information they find for some time. This is why things appear to be listed in reverse order. This process is examined in detail next.

In practice, there are several authoritative nameservers for a domain. One of them is the master (or primary) nameserver, where the domain's data is held. The others are known as slave (or secondary) nameservers, and they hold automatically updated copies of the master data. Both the master and the slaves serve the same information, so it doesn't matter which one a resolver asks. The distinction between master and slave is made purely for reasons of reliabilityto ensure that the failure of a single nameserver does not result in the loss of authoritative data for the domain. As a bonus, this redundancy also distributes the network load between several hosts so that no one nameserver is overwhelmed with requests for authoritative information.

Note

As a DNS administrator, it is your responsibility to ensure that your nameservers provide sufficient redundancy for your zones. Your slaves should be far away from the master so that power failures, network outages, and other catastrophes do not affect your name service.

Despite these precautions, the load on DNS servers would be crushing without the extensive use of local caches. As mentioned before, nameservers are allowed to cache the results of queries and intermediate referrals for some time so that they can serve repeated requests for data without referring to the source each time. If they did not do this, root nameservers (and the nameservers for other popular zones) would be contacted by clients all over the world for every name lookup, wasting a huge amount of resources.

Name Resolution in Practice

When a web browser issues a request for an IP address, the request is sent to a local nameserver, which resolves the name, stores the result in its cache, and returns the IP address. DNS can be a fascinating and extremely in-depth subjectsee the Reference section at the end of this chapter for further reading.