14.4 A Simple Example

Let's start with a simple example to see the communication between a resolver and a name server. We'll run the Telnet client on the host sun to the host gemini, connecting to the daytime server:

 sun %  telnet gemini daytime  Trying 140.252.1.11 ...  first three lines of output are from Telnet client  Connected to gemini.tuc.noao.edu.     Escape character is '^]'.     Wed Mar 24 10:44:17 1993  this is the output from the daytime server  Connection closed by foreign host.  and this is from the Telnet client

For this example we direct the resolver on the host sun (where the Telnet client is run) to use the name server on the host noao.edu (140.252.1.54). Figure 14.9 shows the arrangement of the three systems.

Figure 14.9. Systems being used for simple DNS example.

As we've mentioned before, the resolver is part of the client, and the resolver contacts a name server to obtain the IP address before the TCP connection can be established between Telnet and the daytime server.

In this figure we've omitted the detail that the connection between sun and the 140.252.1 Ethernet is really a SLIP link (see the figure on the inside front cover) because that doesn't affect the discussion. We will, however, run tcpdump on the SLIP link to see the packets exchanged between the resolver and name server.

The file /etc/resolv.conf on the host sun tells the resolver what to do:

 sun %  cat /etc/resolv.conf  nameserver 140.252.1.54     domain tuc.noao.edu

The first line gives the IP address of the name server ” the host noao.edu. Up to three nameserver lines can be specified, to provide backup in case one is down or unreachable. The domain line specifies the default domain. If the name being looked up is not a fully qualified domain name (it doesn't end with a period) then the default domain .tuc.noao.edu is appended to the name. This is why we can type telnet gemini instead of telnet gemini.tuc.noao.edu.

Figure 14.10 shows the packet exchange between the resolver and name server.

Figure 14.10. `tcpdump` output for name server query of the hostname `gemini.tuc.noao.edu.`

We've instructed tcpdump not to print domain names for the source and destination IP addresses of each IP datagram. Instead it prints 140.252.1.29 for the client (the resolver) and 140.252.1.54 for the name server. Port 1447 is the ephemeral port used by the client and 53 is the well-known port for the name server. If tcpdump had tried to print names instead of IP addresses, then it would have been contacting the same name server (doing pointer queries), confusing the output.

Starting with line 1, the field after the colon ( 1+ ) means the identification field is 1, and the plus sign means the RD flag (recursion desired) is set. We see that by default, the resolver asks for recursion.

The next field, A?, means the query type is A (we want an IP address), and the question mark indicates it's a query (not a response). The query name is printed next: gemini.tuc.noao.edu. . The resolver added the final period to the query name, indicating that it's an absolute domain name.

The length of user data in the UDP datagram is shown as 37 bytes: 12 bytes are the fixed- size header (Figure 14.3); 21 bytes for the query name (Figure 14.6), and 4 bytes for the query type and query class. The odd-length UDP datagram reiterates that there is no padding in the DNS messages.

Line 2 in the tcpdump output is the response from the name server and 1* is the identification field with the asterisk meaning the AA flag ( authoritative answer) is set. (We expect this server, the primary server for the noao.edu domain, to be authoritative for names within its domain.)

The output 2/0/0 shows the number of resource records in the final three variablelength fields in the response: 2 answer RRs, 0 authority RRs, and 0 additional RRs. tcpdump only prints the first answer, which in this case has a type of A (IP address) with a value of 140.252.1.11.

Why do we get two answers to our query? Because the host gemini is multihomed . Two IP addresses are returned. Indeed, another useful tool with the DNS is a publicly available program named host. It lets us issue queries to a name server and see what comes back. If we run this program we'll see the two IP addresses for this host:

 sun %  host gemini  gemini.tuc.noao.edu     A        140.252.1.11     gemini.tuc.noao.edu     A        140.252.3.54

The first answer in Figure 14.10 and the first line of output from the host command are the IP address that shares the same subnet (140.252.1) as the requesting host. This is not an accident . If the name server and the host issuing the query are on the same network (or subnet), then BIND sorts the results so that addresses on common networks appear first.

We can still access the host gemini using the other address, but it might be less efficient. Using traceroute in this instance shows that the normal route from subnet 140.252.1 to 140.252.3 is not through the host gemini, but through another router that's connected to both networks. So in this case if we accessed gemini through the other IP address (140.252.3.54) all the packets would require an additional hop. We return to this example and explore the reason for the alternative route in Section 25.9, when we can use SNMP to look at a router's routing table.

There are other programs that provide easy interactive access to the DNS. nslookup is supplied with most implementations of the DNS. Chapter 10 of [Albitz and Liu 1992] provides a detailed description of how to use this program. The dig program ("Domain Internet Groper") is another publicly available tool that queries DNS servers. doc ("Domain Obscenity Control") is a shell script that uses dig and diagnoses misbehaving domains by sending queries to the appropriate DNS name servers, and performing simple analysis of the responses. See Appendix F for details on how to obtain these programs.

The final detail to account for in this example is the size of the UDP data in the reply: 69 bytes. We need to know two points to account for these bytes.

The question is returned in the reply.
There can be many repetitions of domain names in a reply, so a compression scheme is used. Indeed, in our example, there are three occurrences of the domain name gemini.tuc.noao.edu.

The compression scheme is simple. Anywhere the label portion of a domain name can occur, the single count byte (which is between 0 and 63) has its two high-order bits turned on instead. This means it is a 16-bit pointer and not an 8-bit count byte. The 14 bits that follow in the pointer specify an offset in the DNS message of a label to continue with. (The offset of the first byte in the identification field is 0.) We purposely said that this pointer can occur wherever a label can occur, not just where a complete domain name can occur, since it's possible for a pointer to form either a complete domain name or just the ending portion of a name. (This is because the ending labels in the names from a given domain tend to be identical.)

Figure 14.11 shows the format of the DNS reply, line 2 from Figure 14.10. We also show the IP and UDP headers to reiterate that DNS messages are normally encapsulated in UDP datagrams. We explicitly show the count bytes in the labels of the domain name in the question. The two answers returned are the same, except for the different IP addresses returned in each answer. In this example the pointer in each answer would have a value of 12, the offset from the start of the DNS header of the complete domain name.

Figure 14.11. Format of DNS reply corresponding to line 2 of Figure 14.10.

The final point to note from this example is from the second line of output from the Telnet command, which we repeat here:

 sun %  telnet gemini daytime   we only type  gemini    Trying 140.252.1.11  ...      Connected to gemini.tuc.noao.edu.  but the Telnet client outputs FQDN

We typed just the hostname ( gemini ), not the FQDN, but the Telnet client output the FQDN. What's happening is that the Telnet client looks up the name we type by calling the resolver ( gethostbyname ), which returns the IP addresses and the FQDN. Telnet then prints the IP address that it's trying to establish a TCP connection with, and when the connection is established, it outputs the FQDN.

If there is a significant pause between typing the Telnet command and printing the IP address, this delay is caused by the resolver contacting a name server to resolve the name into an IP address. A pause between printing Trying and Connected to, however, is a delay caused by the establishment of the TCP connection between the client and server, not the DNS.

14.4 A Simple Example