M.I.T. DEPARTMENT OF EECS

6.033 - Computer System Engineering DNS Hands-On Assignment

Hands-on 4: 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 4-A 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. dig should be available on all recent Athena workstations. It should work by default, but if it does not, 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.3.1 <<>> slashdot.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1483
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;slashdot.org. IN A
;; ANSWER SECTION:
slashdot.org.           7132    IN      A       66.35.250.150             (*)
;; AUTHORITY SECTION:
slashdot.org.           7132    IN      NS      ns2.ostg.com.
slashdot.org.           7132    IN      NS      ns2.vasoftware.com.
slashdot.org.           7132    IN      NS      ns3.vasoftware.com.
slashdot.org.           7132    IN      NS      ns1.ostg.com.
slashdot.org.           7132    IN      NS      ns1.vasoftware.com.

;; ADDITIONAL SECTION:
ns1.ostg.com.           19140   IN      A       66.35.250.10
ns1.vasoftware.com.     170637  IN      A       12.152.184.135
ns2.ostg.com.           19140   IN      A       66.35.250.11
ns2.vasoftware.com.     170637  IN      A       12.152.184.136
ns3.vasoftware.com.     170637  IN      A       66.35.250.12
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Mar 18 12:28:16 2008
;; MSG SIZE rcvd: 156

The output tells us a lot of information about our DNS request and the response to it. At the bottom, we can see that the query was sent to our default server (127.0.0.1), and that it took roughly 2 msecs to respond. Most of the information we are interested in is in the ANSWER section, marked with a (*) above. Let's examine that section more closely:

        ;; ANSWER SECTION:
        slashdot.org.    7132    IN      A    66.35.250.150 
          name         expire   class  type     data (IP)
We can see that this result is of type A, an address record: it is telling us that the IP address for the name "slashdot.org" is 66.35.250.150. The expiry time field "7132" indicates that this record/entry is valid for 7132 seconds (slightly less than 2 hours). You can ignore the "class" field; this is nearly always IN for Internet.

The authority section contains records of type NS, which give the names of DNS servers that have name records for a particular domain. Here, we can see that five DNS servers (ns2.ostg.com., ns2.vasoftware.com., etc.) 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.)

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

athena% dig @amsterdam.lcs.mit.edu slashdot.org
; <<>> DiG 9.3.1 <<>> @amsterdam.lcs.mit.edu slashdot.org
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 555
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;slashdot.org. IN A
;; ANSWER SECTION:
slashdot.org. 4521 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 4-A of the notes by examining the flags line. The rd (recursion desired) flag indicates that dig requested a recursive lookup, and the ra (recursion available) flag indicates that the server permits recursive lookups (some do not).

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
; <<>> DiG 9.3.1 <<>> @a.ROOT-SERVERS.NET www.slashdot.org +norecurs
;; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 375
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 11
;; QUESTION SECTION:
;www.slashdot.org. IN A
;; AUTHORITY SECTION:
org.                    172800  IN      NS      A0.ORG.AFILIAS-NST.INFO.
org.                    172800  IN      NS      B0.ORG.AFILIAS-NST.org.
org.                    172800  IN      NS      C0.ORG.AFILIAS-NST.INFO.
org.                    172800  IN      NS      D0.ORG.AFILIAS-NST.org.
org.                    172800  IN      NS      TLD1.ULTRADNS.NET.
org.                    172800  IN      NS      TLD2.ULTRADNS.NET.

;; ADDITIONAL SECTION:
A0.ORG.AFILIAS-NST.INFO. 172800 IN      A       199.19.56.1
A0.ORG.AFILIAS-NST.INFO. 172800 IN      AAAA    2001:500:e::1
B0.ORG.AFILIAS-NST.org. 172800  IN      A       199.19.54.1
B0.ORG.AFILIAS-NST.org. 172800  IN      AAAA    2001:500:c::1
C0.ORG.AFILIAS-NST.INFO. 172800 IN      A       199.19.53.1
C0.ORG.AFILIAS-NST.INFO. 172800 IN      AAAA    2001:500:b::1
D0.ORG.AFILIAS-NST.org. 172800  IN      A       199.19.57.1
D0.ORG.AFILIAS-NST.org. 172800  IN      AAAA    2001:500:f::1
TLD1.ULTRADNS.NET.      172800  IN      A       204.74.112.1
TLD1.ULTRADNS.NET.      172800  IN      AAAA    2001:502:d399::1
TLD2.ULTRADNS.NET.      172800  IN      A       204.74.113.1

;; Query time: 13 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Tue Mar 18 12:42:44 2008
;; MSG SIZE  rcvd: 424
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. Please turn in answers to the questions below for Tuesday's recitation. You should submit answers only to the questions asked. In particular, please do not include pages of output from dig unless specifically requested.

I. Getting started

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

III. Understanding caching

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


Go to 6.033 Home Page