CIT 361 RSS feeds and podcasts by Ed Nickel are licensed
under a Creative Commons Attribution 3.0 United States License
based on a work at http://cot.gbcnv.edu/~ed/class/syllabi.html.

CIT 361: Week 7
DNS in Depth

To automatically receive new feeds and podcasts you can copy this link: http://cot.gbcnv.edu/~ed/class/cit361/cit361.xml to your RSS reader and/or your iTunes/mp3 software. If you prefer getting the new feeds and podcasts manually you can read these files directly as you are reading this one or download the audio mp3 file which constitutes the podcast and listen to it using your favorite media software, such as Windows Media Player. Please note, iTunes is available free from Apple and can be used on your PC or Mac even if you do not have an iPod.

As all of you know by now, the Internet accesses websites by IP address number and not by name. This is somewhat analogous to dropping a letter in a mail box somewhere in the world that is simply addressed to "Ed Nickel" which, of course would never get to me. However, if you include the address and zip code for my office at GBC I would get it. So, "cot.gbcnv.edu" somehow needs to be translated into for you to access the GBC, COT Department's web server. This is the job of DNS, domain name service.

Although there have been a number of diagrams in each chapter showing how various protocols establish their connections and communicate from client to server and back, so far we have not gone into detail about how any of these transactions take place. I have been saving that for this chapter because I have found most students understand it better here since DNS is basically already familiar to them. Let us start with a hypothetical situation where you are trying to access the COT web server from home and use Frontier Communications as your ISP, Internet service provider. The first step in a DNS look up starts when you tell your web browser to find and utilize the uniform resource indentifier usually called the URI by its name "http://cot.gbcnv.edu/~ed/class/syllabi.html" so you can use it.

Before we go any farther, let us review the components of this URI to be sure we are all clear about which parts do what. The first part of a URI specifies the service to use when accessing a particular resource, for example: http:// (hypertext transfer protocol), ftp:// (file transfer protocol), tel:// (telnet to access software on a remote computer), or file:// to access a file on the local computer. Next is the host computer's name which in this case it is "cot" but in web browsing it is often a server named "www". The next two parts together make up to domain name with "gbcnv" being the secondary level domain and "edu" the top level domain. The domain name is followed by the specific folder and file to be accessed on that server, which in this case is from the home folder of the account named "ed", folder called "class", and file named "syllabi.html" although the account name does not always show. When no file name is specified there is usually a default file name such as index.html, index.php, or default.htm which will be displayed.

The only parts of the URI this chapter deals with are cot.gbcnv.edu, the host and domain names. Since this hypothetical situation has a user accessing the Internet via "frontiernet.net" their computer will first check the internal ARP table and then if present its "hosts" file to see if it can resolve the name to its IP address. Since very few computers use a hosts file and the ARP table is only useful if the user has accessed that specific host and domain name combination very recently, the computer then initiates a DNS request.

  1. the user's computer sends an address request to the IP address of its DNS server on port number 53. (Its DNS server's IP address can either be coded statically or, these days, is usually given to the local computer when it boots up by its DHCP server which we will discuss in chapter 8.) In the case of my computer at home, using the standard Frontier DSL router settings, it sends the DNS address request to my DSL router at
  2. since my DSL router has only two IP addresses in its DNS table and those are for DNS servers operated by Frontier, it initiates a recursive request, meaning the DSL router will forward the unresolved request to one of Frontier's real DNS servers which are delegated to search until the address is resolved
  3. Frontier's DNS server sees that the TLD (top level domain) name differs from its own TLD name (Frontier is part of the .net TLD but the request is for a .edu TLD address), so it sends the address request to a root name server
  4. the root name server returns IP address of .edu TLD name server
  5. Frontier's DNS server repeats the address request to the .edu TLD name server
  6. the .edu TLD name server returns the IP address for the DNS server of the .gbcnv.edu secondary domain to Frontier's DNS server
  7. Frontier's DNS server now repeats the address request to the authoritative .gbcnv.edu secondary domain DNS server
  8. the gbcnv DNS server returns the IP address for the host "cot" in the .gbcnv.edu domain
  9. Frontier's DNS server returns the cot.gbcnv.edu IP address to my DSL router
  10. the DSL router passes the cot.gbcnv.edu IP address to my home computer
  11. my computer now uses the IP address for "cot.gbcnv.edu" to ask the COT department's web server for the web page specified at the beginning of this discussion, of course, this whole process usually only takes a fraction of a second to complete
DNS recursive communications
Illustration of a recursive DNS IP address look up
where steps 3 & 4, 5 & 6, and 7 & 8 represent the recursion,
all of which are skipped if current DNS data is cached on the first DNS server,
represented by the Frontiernet.net DNS server.

As you can tell, there is a lot of traffic going back and forth between various DNS servers just to find the address for a particular URI, in fact, there could be even more traffic if a domain were further divided into various sub-domains. If every address request outside of a TLD had to go through the top level domain DNS servers then these servers would have to handle billions of requests per hour. Fortunately considerable work over the years has been done to make DNS more efficient. Most DNS servers are now caching servers in addition to being authoritative or replicating servers for their own secondary domain. A caching DNS server automatically adds new non-authoritative entries to its DNS table each time it looks up a new address. These cached entries are kept until the time-to-live for the entry expires as specified by the authoritative DNS server for that host, usually two to four weeks. If I request data using my home computer from the COT web server every day then Frontier's DNS server will normally use the entry in its cache table and only check the IP address within the gbcnv domain's DNS server once every few weeks to make sure it is still valid. Of course that cached entry can be used by any of my students who also use Frontier Communications as their ISP.

One brief addition to the information given at the top of page 314, there are several new generic top level domain names in addition to .com, .edu, .mil, .net, and .gov which include .aero, .biz, .coop, .info, .museum, .name, and .pro among others. For a complete and current list of the TLD names go to the iana.org Root Zone Database. This includes about 200 two character country codes such as .us for the United States, .fm for Federated States of Micronesia often used by FM radio stations, .tv for Tuvalu which is popular among TV stations, and many others. In addition, the ICANN Board approved a new policy in the summer of 2008 allowing companies to register their trademarks as TLDs although I am not aware of any brand names being registered as TLDs yet.

As usual, this chapter also includes a thorough dissection of the DNS data packets as well as information about nslookup a useful diagnostic utility for DNS. Unfortunately, there is no mention of the Linux and UNIX "dig" utility for DNS which tells you more about a particular domain name than I suspect most of you knew could be so easily discovered. I suggest you try nslookup using some of the examples in the book.

As always, post your comments, ideas, and questions in the current discussion. Next week will be the mid-term exam and there will be no new lesson to allow you plenty of time to prepare for the exam. The exam will consist of true/false and multiple choice questions covering chapters 1-7, the handouts, my comments on this material, and possibly some of yours from the discussion posts.

This will be an open book and notes exam with a two hour time limit. Let me give you a few pointers on taking an open book test. Many students think instructors make open book tests harder but this is not usually true. I have found when students know a test is open book they do not study before hand and then try to look up every question to find the answer resulting in insufficient time to complete the test. So follow these simple rules and you can probably pass any test (open book or not) with a good grade:

  1. Review the material to be covered before starting the test.
  2. If open book or not, close the book then go through each question quickly and answer all that you know or think you know
  3. While going through the questions the first time make one list of those you think you know but are not sure of when you answer them, however skip those you do not know at all and put them on a second list.
  4. Spend the time it takes to consider the questions on the second list that you have no clue about and if open book look up these questions.
  5. Throw away the first list and do not be tempted to reconsider them; based on many years of test grading experience, students have a 75% chance of changing a right answer to a wrong one and only a 25% chance of helping themselves when they second guess their original answer.
  6. Save all answers in WebCampus and close the test; if you follow these rules you will probably be done in under an hour and do well on the test.