6.033 Handout 20: Assignment 6 (03/27/00

M.I.T. DEPARTMENT OF EECS

6.033 - Computer System Engineering

Handout 20 - March 17, 2000

Assignment 6: March 27 through March 31

For Lecture: Monday, March 27

Today's lecture will be on Naming in Networks. The reading for today is chapter 5 part B and appendices A, B and C.

For Recitation: Tuesday, March 28

Read the paper by Birrell et al., "Grapevine: an exercise in distributed computing", reading #15, and write a one-pager on the following question:

At the beginning of the course, we looked at some general techniques for coping with complexity. One of these techniques was hierarchical system organization. In what specific ways does the Grapevine naming system make use of hierarchy?

For Lecture: Wednesday, March 29

Today we start a new topic in 6.033: security. As an introduction to security, we will first discuss privacy and security in society. To get prepared, read "Teaching students about responsible use of computers" by Lerman et al. (#17). (The journal incorrectly showed Saltzer as the sole author.)

Also, read Sections A and B of chapter 6 (2000 version) of the notes.

For Recitation: Thursday, March 30

Read the Appendix 6-A to the old Chapter 6 (``Case Studies of Protection System Failures''), pp. 6-34 to 6-55.

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 aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;;      slashdot.org, type = A, class = IN

;; ANSWER SECTION:
slashdot.org.           1H IN A         209.207.224.42
slashdot.org.           1H IN A         209.207.224.40
slashdot.org.           1H IN A         209.207.224.41

;; AUTHORITY SECTION:
slashdot.org.           1H IN NS        ns1.andover.net.
slashdot.org.           1H IN NS        ns2.andover.net.
slashdot.org.           1H IN NS        ns3.andover.net.

;; ADDITIONAL SECTION:
ns1.andover.net.        1w3d6m40s IN A  209.207.224.196
ns2.andover.net.        1w3d6m40s IN A  209.207.224.197
ns3.andover.net.        1w3d6m40s IN A  209.192.217.104

;; Total query time: 5056 msec
;; FROM: contents-vnder-pressvre.mit.edu to SERVER: default -- 127.0.0.1
;; WHEN: Mon Mar 13 12:39:35 2000
;; MSG SIZE  sent: 30  rcvd: 191
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 5 seconds to respond. However, for this exercise, we are mostly interested in is the answer section. We can see that there are three possible answers for the host slashdot.org: 209.207.224.40, 209.207.224.41, and 209.207.224.42. The "1H" indicates that each of these is valid for one hour. The authority section tells us which servers are actually responsible for maintaining information about 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.2 <<>> @redlab.lcs.mit.edu slashdot.org 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;;      slashdot.org, type = A, class = IN

;; ANSWER SECTION:
slashdot.org.           5m31s IN A      209.207.224.40
slashdot.org.           5m31s IN A      209.207.224.41
slashdot.org.           5m31s IN A      209.207.224.42

... [output truncated]
We can also see that these packets are doing the recursive search described in the optimizations (pg 5-43) by the "recurs" text in the res options line. We can disable this by adding +norecurs to the end of our command line:
athena% dig www.yahoo.com +norecurs
; <<>> DiG 8.1 <<>> www.yahoo.com +norecurs 
;; res options: init defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 12, ADDITIONAL: 12
;; QUERY SECTION:
;;      www.yahoo.com, type = A, class = IN

;; AUTHORITY SECTION:
COM.                    5d12h36m54s IN NS  A.ROOT-SERVERS.NET.
COM.                    5d12h36m54s IN NS  H.ROOT-SERVERS.NET.
COM.                    5d12h36m54s IN NS  C.ROOT-SERVERS.NET.
COM.                    5d12h36m54s IN NS  G.ROOT-SERVERS.NET.
COM.                    5d12h36m54s IN NS  F.GTLD-SERVERS.NET.
COM.                    5d12h36m54s IN NS  F.ROOT-SERVERS.NET.
COM.                    5d12h36m54s IN NS  B.ROOT-SERVERS.NET.
COM.                    5d12h36m54s IN NS  I.ROOT-SERVERS.NET.
COM.                    5d12h36m54s IN NS  E.ROOT-SERVERS.NET.
COM.                    5d12h36m54s IN NS  J.GTLD-SERVERS.NET.
COM.                    5d12h36m54s IN NS  K.GTLD-SERVERS.NET.
COM.                    5d12h36m54s IN NS  A.GTLD-SERVERS.NET.

;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET.     6d13h38m24s IN A  198.41.0.4
H.ROOT-SERVERS.NET.     6d13h38m24s IN A  128.63.2.53
C.ROOT-SERVERS.NET.     6d13h38m24s IN A  192.33.4.12
G.ROOT-SERVERS.NET.     6d13h38m24s IN A  192.112.36.4
F.GTLD-SERVERS.NET.     5d13h38m24s IN A  198.17.208.67
F.ROOT-SERVERS.NET.     6d13h38m24s IN A  192.5.5.241
B.ROOT-SERVERS.NET.     6d13h38m24s IN A  128.9.0.107
I.ROOT-SERVERS.NET.     6d15h42m26s IN A  192.36.148.17
E.ROOT-SERVERS.NET.     6d13h38m24s IN A  192.203.230.10
J.GTLD-SERVERS.NET.     5d13h38m24s IN A  198.41.0.21
K.GTLD-SERVERS.NET.     5d13h38m24s IN A  195.8.99.11
A.GTLD-SERVERS.NET.     5d13h38m24s IN A  198.41.3.38

;; Total query time: 4 msec
;; FROM: contents-vnder-pressvre.mit.edu to SERVER: default -- 127.0.0.1
;; WHEN: Wed Mar 15 19:27:05 2000
;; MSG SIZE  sent: 31  rcvd: 447
As you can see, in this case, the server did not know the answer and instead provides information about server most likely to actually be able to provide authoritative information. In this, the best our local server knows is the servers for the top-level .com domain.
With this in mind, let's do some simple exercises. We would prefer that you run these exercises on an Athena workstation though they should work on any Unix workstation.
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 known root server (rendezvous point). The root servers on the Internet are in the domain root-servers.net, some of which are included in the list from the response above.
Use dig to ask one of these 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 host (or list of hosts) that might know more.
Go through the hierarchy without recursion and following the referals manually until you have found the address of the machine. 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 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?

Please turn in the answers to these questions in Thursday's recitation. Also include how long it took for you to do this assignment.

System aphorism of the week

The first 80 percent of a project takes 80 percent of the effort. The last 20 percent takes another 80.

Go to 6.033 Home Page Questions or Comments: 6.033-tas@mit.edu