M.I.T. DEPARTMENT OF EECS

6.033 - Computer System Engineering Handout 19 - March 20, 2002

Hands-on 6: 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 8.1 <<>> slashdot.org 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
;; QUERY SECTION:
;;      slashdot.org, type = A, class = IN

;; ANSWER SECTION:
slashdot.org.           51m58s IN A     64.28.67.150

;; AUTHORITY SECTION:
slashdot.org.           51m58s IN NS    ns1.andover.net.
slashdot.org.           51m58s IN NS    ns2.andover.net.
slashdot.org.           51m58s IN NS    ns3.andover.net.

;; ADDITIONAL SECTION:
ns1.andover.net.        1d23h52m1s IN A  209.207.224.196
ns2.andover.net.        1d23h52m1s IN A  209.207.224.197

;; Total query time: 10 msec
;; FROM: triad.mit.edu to SERVER: default -- 127.0.0.1
;; WHEN: Tue Mar 20 17:32:47 2001
;; MSG SIZE  sent: 30  rcvd: 143

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.01 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 64.28.67.150. The "51m58s" indicates that it is valid for about 52 minutes. 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.1 <<>> @redlab.lcs.mit.edu slashdot.org 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;;      slashdot.org, type = A, class = IN

;; ANSWER SECTION:
slashdot.org.           58m51s IN A     64.28.67.150

... [output truncated]

We can also see that these queries are resulting in the recursive searches described on page 5-47 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

; <<>> DiG 8.1 <<>> @a.ROOT-SERVERS.NET www.slashdot.org. 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 12, ADDITIONAL: 12
;; QUERY SECTION:
;;      www.slashdot.org, type = A, class = IN

;; AUTHORITY SECTION:
ORG.                    2D IN NS        A.GTLD-SERVERS.NET.
ORG.                    2D IN NS        G.GTLD-SERVERS.NET.
ORG.                    2D IN NS        C.GTLD-SERVERS.NET.
ORG.                    2D IN NS        I.GTLD-SERVERS.NET.
ORG.                    2D IN NS        B.GTLD-SERVERS.NET.
ORG.                    2D IN NS        D.GTLD-SERVERS.NET.
ORG.                    2D IN NS        L.GTLD-SERVERS.NET.
ORG.                    2D IN NS        F.GTLD-SERVERS.NET.
ORG.                    2D IN NS        J.GTLD-SERVERS.NET.
ORG.                    2D IN NS        K.GTLD-SERVERS.NET.
ORG.                    2D IN NS        E.GTLD-SERVERS.NET.
ORG.                    2D IN NS        M.GTLD-SERVERS.NET.

;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET.     2D IN A         198.41.3.38
G.GTLD-SERVERS.NET.     2D IN A         198.41.3.101
C.GTLD-SERVERS.NET.     2D IN A         192.26.92.30
I.GTLD-SERVERS.NET.     2D IN A         192.36.144.133
B.GTLD-SERVERS.NET.     2D IN A         203.181.106.5
D.GTLD-SERVERS.NET.     2D IN A         208.206.240.5
L.GTLD-SERVERS.NET.     2D IN A         192.41.162.30
F.GTLD-SERVERS.NET.     2D IN A         192.35.51.30
J.GTLD-SERVERS.NET.     2D IN A         210.132.100.101
K.GTLD-SERVERS.NET.     2D IN A         213.177.194.5
E.GTLD-SERVERS.NET.     2D IN A         207.200.81.69
M.GTLD-SERVERS.NET.     2D IN A         202.153.114.101

;; Total query time: 48 msec
;; FROM: triad.mit.edu to SERVER: a.ROOT-SERVERS.NET  198.41.0.4
;; WHEN: Tue Mar 20 17:43:28 2001
;; MSG SIZE  sent: 34  rcvd: 437

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 ginger.lcs.mit.edu? What command did you use to find this address? What is the time to live for this record?

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 (rendezvous point). 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.
Please turn in the answers to these questions in Thursday's recitation. Also include how long it took for you to do this assignment.
Go to 6.033 Home Page Questions or Comments: 6.033-tas@mit.edu