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.
|
|
|
|
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):
- Your Web browser recognizes the request
for a name and invokes your local resolver, passing to it the name www.net.compsci.googleplex.edu.
- 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.
- 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).
- 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.
- ns1.xyzindustries.com generates
an iterative request for the name and sends it to a root name server.
- The root name server does not resolve
the name. It returns the name and address of the name server for the
.edu domain.
- ns1.xyzindustries.com generates
an iterative request and sends it to the name server for .edu.
- The name server for .edu
returns the name and address of the name server for the googleplex.edu
domain.
- ns1.xyzindustries.com generates
an iterative request and sends it to the name server for googleplex.edu.
- 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.
- ns1.xyzindustries.com
generates an iterative request and sends it to the name server for compsci.googleplex.edu.
- 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.
- 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.)
- The local name server returns the
resolution to the resolver on your local machine.
- Your local resolver also caches the
information.
- The local resolver gives the address
to your browser.
- 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 machines 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 users 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 obviousif
the name was in the cache of the resolver or the local DNS server, most
of these steps would be avoided.
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! |
|
|
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.
|