Andrew Hudson - Fedora™ Unleashed, 2008 edition

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 stores 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 the following:

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.

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 you can always find authoritative data for a domain by following the chain of delegations of authority from . (the root domain) until you reach an authoritative nameserver for the domain. This is what gives DNS its distributed tree structure.

Users of DNS need not be aware of these details. To them, the namespace is just a single tree — any 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 for which they are looking.

As an analogy, you can think of domains as directories in a file system and RRs 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 in which the user is interested. 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 reliability—to 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 over whelmed with requests for authoritative information.

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 enormous resources.

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

Fedora includes a number of standard tools that enable you to work with DNS. These tools, found in the bind-utilsand whoispackages, have everyday uses that do not require DNS administrator skills. If you want to know what domain name belongs to an IP address, or vice versa, these are the tools to use to track down that information. Forward lookups are where you map a name to an IP address; reverse lookups are where you map an address to a name.

Here are tools you can use:

► dig( Domain Information Groper )

► host

► nslookup

► whois

The following sections briefly describe these tools and provide examples of their use.

The Domain Information Groper is a command-line utility that queries DNS nameservers. By default, diguses the nameservers listed in /etc/resolv.confand performs an NS(nameserver) query. Reverse lookups are accomplished with the -xargument with a default A(Address) query.

Here is an example of a forward lookup with dig:

$ dig www.pearson.com

; <<>> DiG 9.5.0a6 <<>> www.pearson.com

;; global options: printcmd