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 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 Core 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. 

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 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 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 they are interested in. For efficiency, they 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 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. To better understand this process, take a moment to see what happens behind the scenes when a web browser issues a request for the IP address of www.ibm.com. This example mimics the actions of the resolver by using the incredibly useful dig utility to follow the chain of delegations between zones until you find the A record you are looking for. Because most nameservers would follow the delegations for you, this example uses the +norec dig parameter to turn off recursion. That is, if the nameserver does not know how to answer your query, it will not issue further queries on its own.

NOTE

There are 13 root nameservers around the world. Several are located in the United States Virginia, California, and Maryland. Others are located in London, Stockholm, and Tokyo. These root servers do not hold "master lists" of IP addresses and domain names, but simply hand off requests to other nameservers.

After a recent DOS (Denial of Service) attack on the root servers, at least one of them now runs an alternative application to BIND.

Begin by randomly selecting one of the 13 root nameservers (ranging from a.root-servers.net to m.root-servers.net; we picked e), and ask what it knows about an A record for www.ibm.com:

 ---------- |    $ dig @e.root-servers.net www.ibm.com A +norec | |    ; <<>> DiG 9.1.3 <<>> @e.root-servers.net www.ibm.com A +norec |    ;; global options:  printcmd |    ;; Got answer: |    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52356 |    ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13 | |    ;; QUESTION SECTION: |    ;www.ibm.com.                   IN      A | |    ;; AUTHORITY SECTION: |    com.                    172800  IN      NS      A.GTLD-SERVERS.NET. |    com.                    172800  IN      NS      G.GTLD-SERVERS.NET. |    com.                    172800  IN      NS      H.GTLD-SERVERS.NET. |    com.                    172800  IN      NS      C.GTLD-SERVERS.NET. |    com.                    172800  IN      NS      I.GTLD-SERVERS.NET. |    com.                    172800  IN      NS      B.GTLD-SERVERS.NET. |    com.                    172800  IN      NS      D.GTLD-SERVERS.NET. |    com.                    172800  IN      NS      L.GTLD-SERVERS.NET. |    com.                    172800  IN      NS      F.GTLD-SERVERS.NET. |    com.                    172800  IN      NS      J.GTLD-SERVERS.NET. |    com.                    172800  IN      NS      K.GTLD-SERVERS.NET. |    com.                    172800  IN      NS      E.GTLD-SERVERS.NET. |    com.                    172800  IN      NS      M.GTLD-SERVERS.NET. | |    ;; ADDITIONAL SECTION: |    A.GTLD-SERVERS.NET.     172800  IN      A       192.5.6.30 |    G.GTLD-SERVERS.NET.     172800  IN      A       192.42.93.30 |    H.GTLD-SERVERS.NET.     172800  IN      A       192.54.112.30 |    C.GTLD-SERVERS.NET.     172800  IN      A       192.26.92.30 |    I.GTLD-SERVERS.NET.     172800  IN      A       192.36.144.133 |    B.GTLD-SERVERS.NET.     172800  IN      A       192.33.14.30 |    D.GTLD-SERVERS.NET.     172800  IN      A       192.31.80.30 |    L.GTLD-SERVERS.NET.     172800  IN      A       192.41.162.30 |    F.GTLD-SERVERS.NET.     172800  IN      A       192.35.51.30 |    J.GTLD-SERVERS.NET.     172800  IN      A       210.132.100.101 |    K.GTLD-SERVERS.NET.     172800  IN      A       213.177.194.5 |    E.GTLD-SERVERS.NET.     172800  IN      A       192.12.94.30 |    M.GTLD-SERVERS.NET.     172800  IN      A       202.153.114.101 | |    ;; Query time: 819 msec |    ;; SERVER: 192.203.230.10#53(e.root-servers.net) |    ;; WHEN: Wed Sep 26 10:05:08 2001 |    ;; MSG SIZE  rcvd: 461 | ---------- 

The QUERY: 1, ANSWER: 0 in the response means that e.root-servers.net didn't know the answer to your question. It does know the authoritative nameservers for the com TLD, and it refers your query to them in the AUTHORITY section. Not too long ago, all the root-servers.net nameservers were themselves authoritative for the com TLD, but additional delegations were recently introduced.

The resolver's next step would be to select one of these listed servers at random, to use the IP addresses mentioned in the ADDITIONAL section of the response to connect to the server, and to repeat the question. This is what we do now, having chosen i.gtld-servers.net:

 ---------- |   $ dig @i.gtld-servers.net www.ibm.com A +norec |   ; <<>> DiG 9.1.3 <<>> @i.gtld-servers.net www.ibm.com A +norec |   ;; global options:  printcmd |   ;; Got answer: |   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61562 |   ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 5 | |   ;; QUESTION SECTION: |   ;www.ibm.com.              IN      A | |   ;; AUTHORITY SECTION: |   ibm.com.           172800  IN      NS      INTERNET-SERVER.ZURICH.ibm.com. |    ibm.com.                172800  IN      NS      NS.WATSON.ibm.com. |    ibm.com.                172800  IN      NS      NS.ERS.ibm.com. |    ibm.com.                172800  IN      NS      NS.ALMADEN.ibm.com. |    ibm.com.                172800  IN      NS      NS.AUSTIN.ibm.com. | |    ;; ADDITIONAL SECTION: |    INTERNET-SERVER.ZURICH.ibm.com. 172800 IN A     195.212.119.252 |    NS.WATSON.ibm.com.      172800  IN      A       198.81.209.2 |    NS.ERS.ibm.com.         172800  IN      A       204.146.173.35 |    NS.ALMADEN.ibm.com.     172800  IN      A       198.4.83.35 |    NS.AUSTIN.ibm.com.      172800  IN      A       192.35.232.34 | |    ;; Query time: 8337 msec |    ;; SERVER: 192.36.144.133#53(i.gtld-servers.net) |    ;; WHEN: Wed Sep 26 10:06:46 2001 |    ;; MSG SIZE  rcvd: 240 ---------- 

We still have 0 ANSWERs, but we are clearly getting closer. The response lists the names and IP addresses of five authoritative nameservers for the ibm.com domain. Notice the abnormally large query time this tells us that our choice of i.gtld-servers.net was, for some reason, a poor one. Intelligent resolvers remember this fact, and would pick a different server in future. BIND only does this for the root servers, though.

We choose NS.WATSON.ibm.com, and repeat our question:

 ---------- |    $ dig @NS.WATSON.ibm.com www.ibm.com A +norec | |    ; <<>> DiG 9.1.3 <<>> @NS.WATSON.ibm.com www.ibm.com A +norec |    ;; global options:  printcmd |    ;; Got answer: |    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32287 |    ;; flags: qr aa ra; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 5 | |    ;; QUESTION SECTION: |    ;www.ibm.com.                   IN      A | |    ;; ANSWER SECTION: |    www.ibm.com.            1800    IN      A       129.42.18.99 |    www.ibm.com.            1800    IN      A       129.42.19.99 |    www.ibm.com.            1800    IN      A       129.42.16.99 |    www.ibm.com.            1800    IN      A       129.42.17.99 | |    ;; AUTHORITY SECTION: |    ibm.com.                600     IN      NS      ns.watson.ibm.com. |    ibm.com.                600     IN      NS      ns.austin.ibm.com. |    ibm.com.                600     IN      NS      ns.almaden.ibm.com. |    ibm.com.                600     IN      NS      ns.ers.ibm.com. |    ibm.com.                600     IN      NS      Âinternet-server.zurich.ibm.com. | |    ;; ADDITIONAL SECTION: |    ns.watson.ibm.com.      600     IN      A       198.81.209.2 |    ns.austin.ibm.com.      86400   IN      A       192.35.232.34 |    ns.almaden.ibm.com.     86400   IN      A       198.4.83.35 |    ns.ers.ibm.com.         259200  IN      A       204.146.173.35 |    internet-server.zurich.ibm.com. 1800 IN A       195.212.119.252 | |    ;; Query time: 441 msec |    ;; SERVER: 198.81.209.2#53(NS.WATSON.ibm.com) |    ;; WHEN: Wed Sep 26 10:08:21 2001 |    ;; MSG SIZE  rcvd: 304 ---------- 

NS.WATSON.ibm.com knew the answer to our question, and for the first time, the response contains an ANSWER section that lists four A records for www.ibm.com. Most resolvers pick one at random and return it to the program that initiated the name resolution. This concludes our search.

Reverse Resolution

Given an IP address, it is often necessary to find the name associated with it (while writing web server logs, for example). This process is known as reverse resolution or reverse lookup, and is accomplished with the help of an elegant subterfuge. IP addresses (similar to filenames) are "backward" from the DNS point of view. Because we can only associate RRs with DNS names, we must find a way to write an IP address, with its left-to-right hierarchy (129.42.18.99 belongs to 129.*), as a DNS name with a right-to-left hierarchy (ibm.com belongs to com).

We do this by reversing the order of the octets in the address, and then appending .in-addr.arpa (a domain used exclusively to support reverse lookups) to the result. For example, 129.42.18.99 would be written as 99.18.42.129.in-addr.arpa. PTR (Pointer) records associated with this special name would then tell us the real name of the host to which the IP belongs.

We can look for PTR records in the usual fashion by following a chain of delegations from a root server. We examine this process briefly by resolving 203.200.109.66 (which is one of the dial-up IP addresses that an ISP assigns to its customers). We ask a root nameserver 66.109.200.203.in-addr.arpa:

 ---------- $ dig @a.root-servers.net 66.109.200.203.in-addr.arpa PTR +norec ; <<>> DiG 9.2.1 <<>> @a.root-servers.net 66.109.200.203.in-addr.arpa PTR +norec ;; global options:  printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64298 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 1 ;; QUESTION SECTION: ;66.109.200.203.in-addr.arpa.   IN      PTR ;; AUTHORITY SECTION: 203.in-addr.arpa.       86400   IN      NS      ns1.apnic.net. 203.in-addr.arpa.       86400   IN      NS      ns3.apnic.net. 203.in-addr.arpa.       86400   IN      NS      ns.ripe.net. 203.in-addr.arpa.       86400   IN      NS      rs2.arin.net. 203.in-addr.arpa.       86400   IN      NS      dns1.telstra.net. ;; ADDITIONAL SECTION: ns.ripe.net.            172800  IN      A       193.0.0.193 ;; Query time: 57 msec ;; SERVER: 198.41.0.4#53(a.root-servers.net) ;; WHEN: Wed Sep  4 21:15:24 2002 ;; MSG SIZE  rcvd: 178 ---------- 

Continuing with NS.TELSTRA.NET, we have

 ---------- $ dig @NS.TELSTRA.NET 66.109.200.203.in-addr.arpa PTR +norec ; <<>> DiG 9.2.1 <<>> @NS.TELSTRA.NET 66.109.200.203.in-addr.arpa PTR +norec ;; global options:  printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12099 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;66.109.200.203.in-addr.arpa.   IN      PTR ;; AUTHORITY SECTION: 200.203.in-addr.arpa.   142315  IN      NS      dns.vsnl.net.in. 200.203.in-addr.arpa.   142315  IN      NS      ns3.vsnl.com. ;; ADDITIONAL SECTION: dns.vsnl.net.in.        33557   IN      A       202.54.1.30 ns3.vsnl.com.           5370    IN      A       203.197.12.42 ;; Query time: 293 msec ;; SERVER: 203.50.0.137#53(NS.TELSTRA.NET) ;; WHEN: Wed Sep  4 21:18:09 2002 ;; MSG SIZE  rcvd: 132 ---------- 

And then,

 ---------- $ dig @ns3.vsnl.com. 66.109.200.203.in-addr.arpa PTR +norec ; <<>> DiG 9.2.1 <<>> @ns3.vsnl.com. 66.109.200.203.in-addr.arpa PTR +norec ;; global options:  printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37848 ;; flags: qr aa ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;66.109.200.203.in-addr.arpa.   IN      PTR ;; AUTHORITY SECTION: 200.203.in-addr.arpa.   86400   IN      SOA     dns.vsnl.net.in. helpdesk.giasbm01.vsnl.net.in. 200001059 86400 7200 2592000 345600 ;; Query time: 259 msec ;; SERVER: 203.197.12.42#53(ns3.vsnl.com.) ;; WHEN: Wed Sep  4 21:19:16 2002 ;; MSG SIZE  rcvd: 114 ---------- 

What happened here? In previous responses, the status has always been NOERROR, but this one has a status of NXDOMAIN (Nonexistent Domain), and the flags section has the aa (Authoritative Answer) flag. This means that the name we are looking for is known not to exist. In contrast, the response from the root nameservers did not have the aa flag set, and said "We do not know about this name: Ask somebody else." The authoritative answer from ns3.vsnl.com says "I know that this name doesn't exist, and you might as well stop looking."

The administrators at vsnl.net.in clearly have not bothered to set up PTR records for their dial-up IP address pool. If they had, the response would have looked like the ones we have seen before and would have included a PTR record. As it is, the response lists the SOA record for zone including the email address of the domain contact, [e-mail], should we choose to complain about broken reverse resolution.

What Did the Resolver Learn?

Based on the work we have done up to this point, we have a list of names and addresses of the authoritative nameservers for the com TLD. In the future, if we are asked to resolve, say www.samspublishing.com, we can direct our query to gtld-servers.net from the start instead of wasting one query on a root server. However, the NS records have an expiry time (also known as Time To Live, or TTL, which you learn about in "The Zone File," later in this chapter) of 2D, meaning that the information is only guaranteed as accurate for two days. This lag time for updates is why you will see announcements made that it might take a few days for DNS changes to propagate throughout the Internet.

Similarly, we know the authoritative nameservers for ibm.com, which are for use in queries involving ibm.com during the next two days. For instance, a web browser might ask for the IP address of commerce.ibm.com when a user clicks on a link on the IBM web page. We can save two queries by asking NS.WATSON.ibm.com again. Of course, we also have the four A records for www.ibm.com in our cache, and we can return one of them if the browser asks us to resolve the name again.

All this information (including that gleaned from the reverse resolution process) can be cached by your computer until expiry and used to speed up further queries.

You have also learned some things that a resolver cannot remember or use. You can guess from the names, for instance, that the DNS administrators at IBM have, as recommended, delegated their DNS service to servers that are distant both geographically and on the network. You can see that IBM runs four web servers on the same network perhaps to gracefully handle the load. We know that the DNS administrators at VSNL (a large ISP) are not as conscientious as they could be because they have only two nameservers for their entire domain and don't have correct reverse mappings.

DNS is endlessly fascinating, and a few hours of playing with dig is well rewarded. By doing so, you can learn some interesting things about DNS and you gain familiarity with dig queries and responses that will prove very useful in debugging problems with your own DNS setup.