How Resolution Works | The Concise Guide to DNS and BIND

After you have divided DNS into zones forward and reverse, and they all are redundant and working well, you need a way to get from one zone to another. This mechanism is vital to DNS, and it is vital that you understand it and how important it is because it will help you solve many of the DNS problems you encounter. Several of the questions found in Internet forums about DNS stem from not understanding this linkage and the importance of it being all there and working.

As mentioned earlier, DNS is similar to a tree data structure as used in programs. It has a root node and edges that are used to descend the tree from the root to other nodes and find the data requested.

When a piece of software requests a piece of information from DNS, it specifies two things: the RR (or resource record) type, which is the kind of information it needs, and the domain name of the record, which in database language is the lookup key.

A Records

To find the address of www.amazon.com, it specifies that it wants the A (address) record for www.amazon.com. Software tools are available to perform such lookups on the command line and display the results. I will use dig, which is a very powerful DNS tool. Unfortunately, dig is not ubiquitous, but it is the best tool I know for this task. If your system lacks dig, see Chapter 15, "Compiling and Maintaining BIND," for instructions on how to compile and install BIND. When you have installed a new BIND, you will also have dig.

First, use dig to find the A record for www.amazon.com:

 $dig www.amazon.com A ; <<>> DiG 8.2 <<>> www.amazon.com A ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;;    www.amazon.com type = A, class = IN ;; ANSWER SECTION: www.amazon.com.         1M IN A         208.216.182.15 ;; AUTHORITY SECTION: www.amazon.com.         1S IN NS        ns-10.amazon.com. ;; Total query time: 5248 msec ;; FROM: roke.uio.no to SERVER: default -- 127.0.0.1 ;; WHEN: Tue Feb 29 20:50:22 2000 ;; MSG SIZE  sent: 32  rcvd: 78

If you look through all that verbiage, you will find what we asked for. In the ANSWER SECTION, you see that www.amazon.com has an A record that says the address is 208.216.182.15.

Recursion

When I issued the previous query, another important thing was done for me. The DNS server I contacted recursed through the domain levels for me, hopping from server to server and caching all the results as it got them. Finally, it returned the A record I asked for, as well as another record, which we'll discuss momentarily.

To see how recursion really works, you need to tell dig to not issue recursive queries. The DNS server dig talks to will then simply give the best answer it has available. By adding +norec to the dig command, you turn off recursion:

 $ dig www.amazon.com A +norec ; <<>> DiG 8.2 <<>> www.amazon.com A +norec ;; res options: init defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45249 ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; QUERY SECTION: ;;      www.amazon.com, type = A, class = IN ;; ANSWER SECTION: www.amazon.com.         11S IN A        208.216.181.15 ;; AUTHORITY SECTION: AMAZON.COM.             1d23h59m11s IN NS  AUTH00.NS.UU.NET. AMAZON.COM.             1d23h59m11s IN NS  NS2.PNAP.NET. AMAZON.COM.             1d23h59m11s IN NS  NS1.PNAP.NET. AMAZON.COM.             1d23h59m11s IN NS  NS-1.AMAZON.COM. ;; ADDITIONAL SECTION: AUTH00.NS.UU.NET.       1d23h59m15s IN A  198.6.1.65 NS2.PNAP.NET.           1d23h59m11s IN A  206.253.194.97 NS1.PNAP.NET.           1d23h59m11s IN A  206.253.194.65 NS-1.AMAZON.COM.        1d23h59m11s IN A  209.191.164.20 ;; Total query time: 6 msec ;; FROM: roke.uio.no to SERVER: default -- 127.0.0.1 ;; WHEN: Tue Feb 29 20:51:11 2000 ;; MSG SIZE  sent: 32  rcvd: 212

But, something went wrong here! You were supposed to get the best answer, not the right answer. The answer from the previous query was cached, so you got the A record straight away this time. We'll have to use another example:

 $ dig www.math.uio.no A +norec ; <<>> DiG 8.2 <<>> www.math.uio.no A +norec ;; res options: init defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31338 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13 ;; QUERY SECTION: ;;      www.math.uio.no, type = A, class = IN ;; AUTHORITY SECTION: .                       5d23h57m29s IN NS  G.ROOT-SERVERS.NET. .                       5d23h57m29s IN NS  F.ROOT-SERVERS.NET. .                       5d23h57m29s IN NS  B.ROOT-SERVERS.NET. .                       5d23h57m29s IN NS  J.ROOT-SERVERS.NET. .                       5d23h57m29s IN NS  K.ROOT-SERVERS.NET. .                       5d23h57m29s IN NS  L.ROOT-SERVERS.NET. .                       5d23h57m29s IN NS  M.ROOT-SERVERS.NET. .                       5d23h57m29s IN NS  I.ROOT-SERVERS.NET. .                       5d23h57m29s IN NS  E.ROOT-SERVERS.NET. .                       5d23h57m29s IN NS  D.ROOT-SERVERS.NET. .                       5d23h57m29s IN NS  A.ROOT-SERVERS.NET. .                       5d23h57m29s IN NS  H.ROOT-SERVERS.NET. .                       5d23h57m29s IN NS  C.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: G.ROOT-SERVERS.NET.     6d23h57m29s IN A  192.112.36.4 F.ROOT-SERVERS.NET.     6d23h57m29s IN A  192.5.5.241 B.ROOT-SERVERS.NET.     6d23h57m29s IN A  128.9.0.107 J.ROOT-SERVERS.NET.     6d23h57m29s IN A  198.41.0.10 K.ROOT-SERVERS.NET.     6d23h57m29s IN A  193.0.14.129 L.ROOT-SERVERS.NET.     6d23h57m29s IN A  198.32.64.12 M.ROOT-SERVERS.NET.     6d23h57m29s IN A  202.12.27.33 I.ROOT-SERVERS.NET.     6d23h57m29s IN A  192.36.148.17 E.ROOT-SERVERS.NET.     6d23h57m29s IN A  192.203.230.10 D.ROOT-SERVERS.NET.     6d23h57m29s IN A  128.8.10.90 A.ROOT-SERVERS.NET.     6d23h57m29s IN A  198.41.0.4 H.ROOT-SERVERS.NET.     6d23h57m29s IN A  128.63.2.53 C.ROOT-SERVERS.NET.     6d23h57m29s IN A  192.33.4.12 ;; Total query time: 15 msec ;; FROM: roke.uio.no to SERVER: default -- 127.0.0.1 ;; WHEN: Tue Feb 29 20:51:32 2000 ;; MSG SIZE  sent: 33  rcvd: 452

In the previous code, the nameserver says it does not know the answer and to ask one of the listed servers for the answer.

NS Records

The previous listing shows two kinds of records. First, it shows NS records, which specify the names of the nameservers for a zone. All zones have NS records indicating which servers to ask for information about that zone. Each zone with a subzone must have NS records for the subzone so that interested parties can find the servers of the subzone. These NS records make up the edges in the DNS tree structure.

One obvious problem with the NS records exists, though. To query one of the nameservers, you need its address as well. Luckily, the addresses were also supplied by the server you asked so you don't need to ask for them before you can proceed. This is also good because, if you had to ask for the addresses for each partially answered query as well, the query would literally explode into numerous subqueries to find the addresses of the nameservers of this and then to find the addresses of the nameservers of them again.

As you can see, they are all rootservers. Therefore, you can ask one of them, m.root-servers.net, whether it can help you by adding @m.root-servers.net to the command line:

 $ dig @m.root-servers.net. www.math.uio.no A +norec ; <<>> DiG 8.2 <<>> @m.root-servers.net. www.math.uio.no A +norec ; (1 server found) ;; res options: init defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16796 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 5 ;; QUERY SECTION: ;;      www.math.uio.no, type = A, class = IN ;; AUTHORITY SECTION: NO.                     2D IN NS        IFI.UIO.NO. NO.                     2D IN NS        NAC.NO. NO.                     2D IN NS        NN.UNINETT.NO. NO.                     2D IN NS        NS.EU.NET. NO.                     2D IN NS        NS.UU.NET. ;; ADDITIONAL SECTION: IFI.UIO.NO.             2D IN A         129.240.64.2 NAC.NO.                 2D IN A         129.240.2.40 NN.UNINETT.NO.          2D IN A         158.38.0.181 NS.EU.NET.              2D IN A         192.16.202.11 NS.UU.NET.              2D IN A         137.39.1.3 ;; Total query time: 369 msec ;; FROM: roke.uio.no to SERVER: m.root-servers.net.  202.12.27.33 ;; WHEN: Tue Feb 29 20:52:05 2000 ;; MSG SIZE  sent: 33  rcvd: 223

The rootserver did not know the address you asked for, but it told you who might know. Next, ask nac.no:

 $ dig @nac.no. www.math.uio.no A +norec ; <<>> DiG 8.2 <<>> @nac.no. www.math.uio.no A +norec ; (1 server found) ;; res options: init defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26737 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; QUERY SECTION: ;;      www.math.uio.no, type = A, class = IN ;; AUTHORITY SECTION: uio.no.                 1D IN NS        nissen.uio.no. uio.no.                 1D IN NS        ifi.uio.no. uio.no.                 1D IN NS        nn.uninett.no. ;; ADDITIONAL SECTION: nissen.uio.no.          1D IN A         129.240.2.3 ifi.uio.no.             1D IN A         129.240.64.2 nn.uninett.no.          1D IN A         158.38.0.181 ;; Total query time: 45 msec ;; FROM: roke.uio.no to SERVER: nac.no.  129.240.2.40 ;; WHEN: Tue Feb 29 20:52:21 2000 ;; MSG SIZE  sent: 33  rcvd: 151

You're getting closer because now you know the addresses of the servers of the uio.no zone. So, you should next ask one of them:

 $ dig @ifi.uio.no www.math.uio.no A +norec ; <<>> DiG 8.2 <<>> @ifi.uio.no. www.math.uio.no A +norec ; (1 server found) ;; res options: init defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26176 ;; flags: qr aa ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3 ;; QUERY SECTION: ;;      www.math.uio.no, type = A, class = IN ;; ANSWER SECTION: www.math.uio.no.        1D IN CNAME     mnemosyne.uio.no. mnemosyne.uio.no.       1D IN A         129.240.222.126 ;; AUTHORITY SECTION: uio.no.                 1D IN NS        nissen.uio.no.  uio.no.                 1D IN NS        ifi.uio.no. uio.no.                 1D IN NS        nn.uninett.no. ;; ADDITIONAL SECTION: nissen.uio.no.          1D IN A         129.240.2.3 ifi.uio.no.             1D IN A         129.240.64.2 nn.uninett.no.          1D IN A         158.38.0.181 ;; Total query time: 57 msec ;; FROM: roke.uio.no to SERVER: ifi.uio.no.  129.240.64.2 ;; WHEN: Tue Feb 29 20:52:37 2000 ;; MSG SIZE  sent: 33  rcvd: 191

Finally, you found what you were looking for the A record of http://www.math.uio.no. Notice how ifi.uio.no was capable of answering right away? That was because it knew the answer to the question and did not have to refer you on to another server to find it.

CNAME Records

But wait, you didn't get the A record of http://www.math.uio.no; you got a CNAME record. A CNAME record is another of the most common record types, which says that the canonical name of the host you're looking for is some other name. It's an alias. If it knows the address of the other name, it will supply that too, as it did here. The canonical name of http://www.math.uio.no is mnemosyne.uio.no, which in turn has 129.240.222.126 as its address.

When you find an address from a hostname, it is called a forward lookup, or forward resolution. When you find a hostname from an IP address, it's called a reverse lookup.

PTR Records

Now you've seen DNS from the inside doing what you're used to it doing for you looking up an IP address from a DNS name. Another equally important service it performs is looking up a DNS name from an address. This is done primarily by services that want to log to whom they talk or want to check access lists against the name of the host with which they're talking.

If I were to contact the FTP server at sunsite.uio.no, it would check DNS to see whether it wants to talk to me and in which access class I should be. So, if I sit at roke.linpro.no, which I do, sunsite would know the IP address from which I'm connecting 195.0.166.250. It then would make a library call to find the DNS name that goes with the number. The library would proceed to look up 250.166.0.195.in-addr.arpa to find the name. The record type used to map addresses to names is called PTR. These records point to the right name to look at for further information about the host.

A Reverse Lookup

The following is an example of the lookup process (it's a bit abbreviated compared to the last example):

 $ dig @e.root-servers.net. 250.166.0.195.in-addr.arpa PTR +norec … ;; AUTHORITY SECTION: 195.in-addr.arpa.       6D IN NS        NS.RIPE.NET. 195.in-addr.arpa.       6D IN NS        NS.EU.NET. 195.in-addr.arpa.       6D IN NS        AUTH03.NS.UU.NET. 195.in-addr.arpa.       6D IN NS        NS2.NIC.FR. 195.in-addr.arpa.       6D IN NS        SUNIC.SUNET.SE. 195.in-addr.arpa.       6D IN NS        MUNNARI.OZ.AU. 195.in-addr.arpa.       6D IN NS        NS.APNIC.NET.  …

The previous code immediately points to the servers of 195.in-addr.arpa, without any intermediate steps to arpa or in-addr.arpa servers. From this, it is reasonable to assume that 195.in-addr.arpa is defined directly in the root zone, and no matter how it's zoned, the rootserver is authoritative. The code also shows that the servers are quite redundant at this level in the domain hierarchy and that they are located all over Europe, and in Australia as well, which is a good strategy for robustness. When you query one of them, you get the following:

 … ;; AUTHORITY SECTION: 166.0.195.in-addr.arpa.  1D IN NS  ns1-195-0-166.dns.eunet.no. 166.0.195.in-addr.arpa.  1D IN NS  ns2-195-0-166.dns.eunet.no.  …

Here, you leap directly to the zone for 195.0.166, and both of those servers are in Norway. Then, you ask one of them the following:

 $ dig @ns1-195-0-166.dns.eunet.no. 250.166.0.195.in-addr.arpa PTR +norec … ;; ANSWER SECTION: 250.166.0.195.in-addr.arpa.  1D IN PTR  roke.linpro.no.  …

And there you have it the name of 195.0.166.250 is roke.linpro.no.

Reverse lookups are often forgotten, which is why it is doubly important for the DNS administrator you to be aware of their importance and the fact that they must work.

Reverse resolution is important because even if most people don't realize it, it's performed all the time. Some services will break (or break partially) if it doesn't work, causing them to deny your users access. This will end up being your fault because setting up and checking on reverse zones is your job.

Secondly, reverse resolution is important because people don't usually perform reverse lookups; they tend to forget that they happen. So, when things start to fail in odd ways, the first thing you'll think won't be "Aha, reverse resolution must have broken!" If your reverse zones break, the problem will probably seem subtle. The first to notice it will be software, which can't tell you because it's offsite being used by remote users. And it won't all fail, or even fail all the time. An intermittent failure problem is much harder to solve than a permanent failure problem especially when the failures are on remote servers that you don't control and can't check the logs on.