M.I.T. DEPARTMENT OF EECS
6.033 - Computer System Engineering | DNS Hands-On Assignment |
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.
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.
Be sure and explicitly use /usr/athena/bin/dig when running dig;
the dig we will use in this assignment is 9.2.1
Here is an example usage of dig
:
athena% /usr/athena/bin/dig slashdot.org
; <<>> DiG 9.2.1 <<>> slashdot.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51894 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5
;; QUESTION SECTION: ;slashdot.org. IN A
;; ANSWER SECTION: slashdot.org. 4388 IN A 66.35.250.150
;; AUTHORITY SECTION: slashdot.org. 4388 IN NS ns1.vasoftware.com. slashdot.org. 4388 IN NS ns2.osdn.com. slashdot.org. 4388 IN NS ns2.vasoftware.com. slashdot.org. 4388 IN NS ns3.vasoftware.com. slashdot.org. 4388 IN NS ns1.osdn.com.
;; ADDITIONAL SECTION: ns1.osdn.com. 169988 IN A 66.35.250.10 ns1.vasoftware.com. 169988 IN A 12.152.184.135 ns2.osdn.com. 169988 IN A 66.35.250.11 ns2.vasoftware.com. 169988 IN A 12.152.184.136 ns3.vasoftware.com. 169988 IN A 66.35.250.12
;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Mar 24 10:44:03 2005 ;; MSG SIZE rcvd: 235
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 2 msecs 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 "4388" indicates that this record/entry
is valid for about 4388 seconds (slightly more than 1 hour). 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. (1) Why?)
We can ask a specific server (instead of the default) for information about a host by using the following syntax:
athena% /usr/athena/bin/dig @redlab.lcs.mit.edu slashdot.org
; <<>> DiG 9.2.1 <<>> @redlab.lcs.mit.edu slashdot.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35814 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5
;; QUESTION SECTION: ;slashdot.org. IN A
;; ANSWER SECTION: slashdot.org. 3936 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 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% /usr/athena/bin/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: 62049 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6
;; QUESTION SECTION: ;www.slashdot.org. IN A
;; AUTHORITY SECTION: org. 172800 IN NS TLD1.ULTRADNS.NET. org. 172800 IN NS TLD2.ULTRADNS.NET. org. 172800 IN NS TLD3.ULTRADNS.org. org. 172800 IN NS TLD4.ULTRADNS.org. org. 172800 IN NS TLD5.ULTRADNS.INFO. org. 172800 IN NS TLD6.ULTRADNS.CO.UK.
;; ADDITIONAL SECTION: TLD1.ULTRADNS.NET. 172800 IN A 204.74.112.1 TLD2.ULTRADNS.NET. 172800 IN A 204.74.113.1 TLD3.ULTRADNS.org. 172800 IN A 199.7.66.1 TLD4.ULTRADNS.org. 172800 IN A 199.7.67.1 TLD5.ULTRADNS.INFO. 172800 IN A 192.100.59.11 TLD6.ULTRADNS.CO.UK. 172800 IN A 198.133.199.11
;; Query time: 15 msec ;; SERVER: 198.41.0.4#53(a.ROOT-SERVERS.NET) ;; WHEN: Thu Mar 24 10:57:02 2005 ;; MSG SIZE rcvd: 292As 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.
(2) What is the IP address of thyme.lcs.mit.edu
? (3) What
command did you use to find this address? (4) What is the expiration time for
this record? (5) The "dig" answer for thyme contains the string CNAME.
In the terminology of chapter 4, what does CNAME mean?
(6) What are the IP addresses for ai and ai. (note the dot at the end) respectively?
(use the command nslookup
instead of dig
for this exercise).
(7) Examine the local machine's /etc/resolv.conf
file, what can you say
about the context of DNS searches for ai and ai.?
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
(8) Why does this particular command return the names of the root nameservers?
(9) Use dig
to ask amsterdam.lcs.mit.edu
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.
ad.doubleclick.net
. If you look at this, do you notice
anything else interesting about the responses that you get back?
Go to 6.033 Home Page |