| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
DNS Name Resolution Efficiency Improvements: Caching and Local Resolution (Page 2 of 3) Name Resolver Caching These two phenomena are the rationale for caching in the computer world in general, and as we have seen, in DNS servers in particular. The same advantages applies to resolvers, and so many of them perform caching also, in a way rather similar to how it is done in servers. On a particular client computer, once a particular name is resolved, it is cached and remains ready for the next time it is needed. Again, this eliminates traffic and load on DNS servers. (Note however that not all resolvers perform caching.) You might be wondering why we bother having caching on both resolvers and servers. This is not redundant, as it may appear. Or rather, it's redundant, but in a good way. To understand why, we much recognize that a fundamental trade-off in caching is that a cache provides better performance the closer it is the requestor of the data, but better coverage the further it is from the user. If resolvers didn't cache results but our local server did, we could get the information from the server's cache, but it would require waiting for the exchange of a query and response. The resolver's cache is closer to the user and so more efficient. At the same time, this doesn't obviate the need for caching at our network's local DNS server. The server is further away from the user than the resolver, but its cache is shared by many machines. They can all benefit from its cache, so that if I look up a particular name and then someone else does a few minutes later, they can use my cached resolution even though they are typing it for the first time. Caching by name resolvers follows the same general principles and rules as caching by name servers. The amount of time a resource record is specified by its Time To Live figure. Also, resolvers will not cache the results of certain queries, such as reverse lookups, and may also not cache a resolution if they suspect that for whatever reason the data returned is unreliable or corrupted.
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. |