| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
DNS Name Resolution Process (Page 1 of 3) In the previous topics I have described what name resolvers do, explained the basic top-down resolution process using iterative and recursive resolution, and discussed how local resolution and caching are used to improve resolution performance. Now I would like to tie all this background material together and finally show you how the name resolution process works as a whole! As usual, the best way to do this is by example. Here, I will actually combine two examples I have used earlier: the fictitious company XYZ Industries and the non-existent college, Googleplex University. Let's say that XYZ Industries runs its own DNS servers for the xyzindustries.com zone. The master name server is called ns1.xyzindustries.com, and the slave is, ta-da, ns2.xyzindustries.com. These are also used as local DNS servers for resolvers on client machines. We'll assume for this example that as is often the case, our DNS servers will accept recursive requests from machines within our company, but will not assume other machines will accept such requests. Let's also assume that both the server and resolver perform caching, and that the caches are empty. Let's say that Googleplex University runs its own DNS servers for the googleplex.edu domain, as I gave in the example in the topic describing DNS zones. There are three subdomains: finearts.googleplex.edu, compsci.googleplex.edu, and admin.googleplex.edu. Of these, compsci.googleplex.edu is in a separate zone with dedicated servers, while the other subdomains are in the googleplex.edu zone (this is shown in Figure 240.)
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. |