Please Whitelist This Site?

I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)

If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.

If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.

Thanks for your understanding!

Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide


NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The Book is Here... and Now On Sale!

Read offline with no ads or diagram watermarks!
The TCP/IP Guide

Custom Search







Table Of Contents  The TCP/IP Guide
 9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)
      9  Name Systems and TCP/IP Name Registration and Name Resolution
           9  TCP/IP Name Systems: Host Tables and Domain Name System (DNS)
                9  TCP/IP Domain Name System (DNS)
                     9  DNS Name Servers and Name Resolution
                          9  DNS Resolution Concepts and Resolver Operations

Previous Topic/Section
DNS Name Resolution Efficiency Improvements: Caching and Local Resolution
Previous Page
Pages in Current Topic/Section
1
2
3
Next Page
DNS Reverse Name Resolution Using the IN-ADDR.ARPA Domain
Next Topic/Section

DNS Name Resolution Process
(Page 2 of 3)

Resolution Process Steps

Now, suppose you are an employee within XYZ Industries and one of your clients is in charge of the networking department at Googleplex U. You type into your Web browser the address of this department's Web server, “www.net.compsci.googleplex.edu”. In simplified terms, the procedure would involve the following set of steps (Figure 245 shows the process graphically):

  1. Your Web browser recognizes the request for a name and invokes your local resolver, passing to it the name “www.net.compsci.googleplex.edu”.

  2. The resolver checks its cache to see if it already has the address for this name. If it does, it returns it immediately to the Web browser, but in this case we are assuming that it does not. The resolver also checks to see if it has a local host table file. If so, it scans the file to see if this name has a static mapping. If so, it resolves the name using this information immediately. Again, let's assume it does not, since that would be boring.

  3. The resolver generates a recursive query and sends it to “ns1.xyzindustries.com” (using that server's IP address, of course, which the resolver knows).

  4. The local DNS server receives the request and checks its cache. Again, let's assume it doesn't have the information needed. If it did, it would return the information, marked “non-authoritative”, to the resolver. The server also checks to see if it has in its zone resource records that can resolve “www.net.compsci.googleplex.edu”. Of course it does not, in this case, since they are in totally different domains.

  5. “ns1.xyzindustries.com” generates an iterative request for the name and sends it to a root name server.

  6. The root name server does not resolve the name. It returns the name and address of the name server for the “.edu” domain.

  7. “ns1.xyzindustries.com” generates an iterative request and sends it to the name server for “.edu”.

  8. The name server for “.edu” returns the name and address of the name server for the “googleplex.edu” domain.

  9. “ns1.xyzindustries.com” generates an iterative request and sends it to the name server for “googleplex.edu”.

  10. The name server for “googleplex.edu” consults its resource records. It sees, however, that this name is in the “compsci.googleplex.edu” subdomain, which is in a separate zone. It returns the name server for that zone.

  11. “ns1.xyzindustries.com” generates an iterative request and sends it to the name server for “compsci.googleplex.edu”.

  12. The name server for “compsci.googleplex.edu” is authoritative for “www.net.compsci.googleplex.edu”. It returns the IP address for that host to “ns1.xyzindustries.com”.

  13. “ns1.xyzindustries.com” caches this resolution. (Note that it will probably also cache some of the other name server resolutions that it received in steps #6, #8 and #10; I have not shown these explicitly.)

  14. The local name server returns the resolution to the resolver on your local machine.

  15. Your local resolver also caches the information.

  16. The local resolver gives the address to your browser.

  17. Your browser commences an HTTP request to the Googleplex machine's IP address.

    Figure 245: Example Of The DNS Name Resolution Process

    This fairly complex example illustrates a typical DNS name resolution using both iterative and recursive resolution. The user types in a DNS name (“www.net.compsci.googleplex.edu”) into a Web browser, which causes a DNS resolution request to be made from her client machine’s resolver to a local DNS name server. That name server agrees to resolve the name recursively on behalf of the resolver, but uses iterative requests to accomplish it. These requests are sent to a DNS root name server, followed in turn by the name servers for “.edu”, “googleplex.edu” and ‘compsci.googleplex.edu”. The IP address is then passed to the local name server and then back to the user’s resolver and finally, her Web browser software.

     


Seems rather complicated and slow. Of course, computers work faster than you can read (or I can type, for that matter.) Even given that, the benefits of caching are obvious—if the name was in the cache of the resolver or the local DNS server, most of these steps would be avoided.


Previous Topic/Section
DNS Name Resolution Efficiency Improvements: Caching and Local Resolution
Previous Page
Pages in Current Topic/Section
1
2
3
Next Page
DNS Reverse Name Resolution Using the IN-ADDR.ARPA Domain
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



Home - Table Of Contents - Contact Us

The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005

© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.