Hands-on 5: Internet Domain Name System

Today's hands-on exercise is designed to give you a quick introduction to the Internet's Domain Name System. This is an example of a naming system which all of you use on a daily basis --- in fact you used it to get to this web-page! To prepare for this assignment, please read Appendix 5-B of the class notes, titled "Case study of the Internet Domain Name System". This should give you a good general idea of how the DNS works.

Introduction

In order to help explore the domain name system, there is a tool called dig, short for Domain Information Groper. We will be making use of dig in this assignment. This should be available on all recent Athena workstations. If it does not work by default, please try running add watchmaker first. If that still does not work, try an Athena Sun workstation. Here is an example usage of dig:

athena% dig slashdot.org

; <<>> DiG 9.2.1 <<>> slashdot.org 
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7751
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;slashdot.org.                  IN      A

;; ANSWER SECTION:
slashdot.org.           71635   IN      A       66.35.250.150

;; AUTHORITY SECTION:
slashdot.org.           71635   IN      NS      ns2.vasoftware.com.
slashdot.org.           71635   IN      NS      ns3.vasoftware.com.
slashdot.org.           71635   IN      NS      ns1.vasoftware.com.

;; ADDITIONAL SECTION:
ns1.vasoftware.com.     158035  IN      A       198.186.202.135
ns2.vasoftware.com.     158035  IN      A       198.186.202.136
ns3.vasoftware.com.     158035  IN      A       66.35.250.12

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Mar  7 22:12:09 2003
;; MSG SIZE  rcvd: 162

The tells us a lot of information about our DNS request and the response to it. We can see that we asked our default server (127.0.0.1), and that it took roughly 0.003 seconds to respond. However, for this exercise, we are mostly interested in is the answer section. We can see that the IP address for slashdot.org is 66.35.250.150. The field "The "71635" indicates that this record/entry is valid for about 71635 seconds. The authority section tells us which DNS servers are responsible for answering requests for names in the slashdot.org domain. (Note that in all of these examples, the exact results you get may be slightly different. Why?)

We can ask a specific server (instead of the default) for information about a host by using the following syntax:

athena% dig @redlab.lcs.mit.edu slashdot.org

; <<>> DiG 8.3 <<>> @redlab.lcs.mit.edu slashdot.org 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;;  ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;;      slashdot.org, type = A, class = IN

;; ANSWER SECTION:
slashdot.org.           2h10m59s IN A   66.35.250.150

...[output truncated]

We can also see that these queries are resulting in the recursive searches described in section 1 of appendix 5-B of the notes by the "recurs" text in the res options line. dig only shows us the final result of the recursive search. One way for us to mimic the individual steps of a recursive search is to send a request to a particular DNS server and ask for no recursion. For the former, we can give an @server argument to dig. For the latter, we can pass the +norecurs flag. For example, to send a non-recursive query to one of the root servers:

athena% dig @a.ROOT-SERVERS.NET www.slashdot.org. +norecurs
athena%  dig @a.ROOT-SERVERS.NET www.slashdot.org. +norecurs

; <<>> DiG 9.2.1 <<>> @a.ROOT-SERVERS.NET www.slashdot.org. +norecurs
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<< opcode: QUERY, status: NOERROR, id: 4445
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 9

;; QUESTION SECTION:
;www.slashdot.org.              IN      A

;; AUTHORITY SECTION:
org.                    172800  IN      NS      A7.NSTLD.COM.
org.                    172800  IN      NS      L7.NSTLD.COM.
org.                    172800  IN      NS      G7.NSTLD.COM.
org.                    172800  IN      NS      F7.NSTLD.COM.
org.                    172800  IN      NS      M5.NSTLD.COM.
org.                    172800  IN      NS      J5.NSTLD.COM.
org.                    172800  IN      NS      I5.NSTLD.COM.
org.                    172800  IN      NS      C5.NSTLD.COM.
org.                    172800  IN      NS      E5.NSTLD.COM.

;; ADDITIONAL SECTION:
A7.NSTLD.COM.           172800  IN      A       192.5.6.36
L7.NSTLD.COM.           172800  IN      A       192.41.162.36
G7.NSTLD.COM.           172800  IN      A       192.42.93.36
F7.NSTLD.COM.           172800  IN      A       192.35.51.36
M5.NSTLD.COM.           172800  IN      A       192.55.83.34
J5.NSTLD.COM.           172800  IN      A       192.48.79.34
I5.NSTLD.COM.           172800  IN      A       192.43.172.34
C5.NSTLD.COM.           172800  IN      A       192.26.92.34
E5.NSTLD.COM.           172800  IN      A       192.12.94.34

;; Query time: 25 msec
;; SERVER: 198.41.0.4#53(a.ROOT-SERVERS.NET)
;; WHEN: Fri Mar  7 22:31:39 2003
;; MSG SIZE  rcvd: 340

As you can see, the server does not know the answer and instead provides information about the servers most likely to be able to provide authoritative information. In this case, the best the root server knows is the identities of the servers for the .org domain.

With this in mind, let's do some simple exercises. This hands-on should be doable from any workstation that has dig or an equivalent command, but if you try it anywhere other than on an Athena workstation, and you run into something unexpected, the teaching staff may not be able to help you figure out what is going on.

I. Getting started

What is the IP address of thyme.lcs.mit.edu? What command did you use to find this address? What is the time to live for this record? The "dig" answer for thyme contains the string CNAME. In the terminology of chapter 5, what does CNAME mean?

What is the IP address for ai and ai. (note the dot at the end) respectively? (use the command nslookup instead of dig for this exercise).
Examine the local machine's /etc/resolv.conf file, what can you say about the context of DNS searches for ai and ai.?

II. Understanding hierarchy

For this problem, you will go through the steps of resolving a particular hostname, by iterating through a series of servers, just like a regular server might. Assuming it knows nothing else about a name, a DNS resolver will ask a well-known root server. The root servers on the Internet are in the domain root-servers.net. One way to get a list of them is with the command:

athena% dig . ns

Why does this particular command return the names of the root nameservers?

Use dig to ask one of the root servers the address of redlab.lcs.mit.edu without recursion. What command do you use to do this? It is unlikely that these servers actually know the answer so they will refer you to a server (or list of servers) that might know more. Go through the hierarchy from the root without recursion and following the referrals manually until you have found the address of redlab.lcs.mit.edu. What is the address? Display the output of the final command. How many iterations did it take? What commands did you use for each one?

III. Understanding caching

These few queries should show you how your local machine's cache works.

• Ask your default server for information, without recursion, about the host www.dmoz.org. What command did you use? Does it have the answer in its cache? How do you know? How long did this query take? If this information was cached, please find some other host name that is not cached and do this section with that other host.
• Now, ask your default server this same query but use recursion. It should return an answer for you. How long did this take?
• Finally, ask your default server again without recursion. How long does this request take? Has the cache served its purpose?
• Watch the TTL decrement on the cache by repeating the previous step. If you wait long enough, you can watch it return to the original state and then you can repeat this cycle. A good host to play with for this might be ad.doubleclick.net. If you look at this, do you notice anything else interesting about the responses that you get back?