| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
DNS Name Server Caching, Negative Caching and Data Persistence (Page 2 of 3) Caching Data Persistence and the Time To Live Interval Of course, things aren't entirely this simple. One very important issue that comes up with every caching system, including the one used in DNS, is the matter of the freshness of the cache. Suppose our local DNS server resolves the name www.xyzindustries.com and then caches its address. In the example above where we click a link a few seconds after the XYZ Industries home page loads, we aren't likely too concerned about how fresh the DNS data is. But how about if we shut down our computer to go on vacation for 2 weeks and then come back to work and type the name again into our browser. If our local server still has the name in its cache, how do we know the IP address of www.xyzindustries.com hasn't changed during that two-week period? Two different mechanisms are used to address this issue. The first is that when data is cached, the caching server also makes a note of the authoritative server from which it came. When a resolver (client) asks for a name resolution and the address is drawn from the cache, the server marks the answer as non-authoritative to clearly tell the client that the name came from the cache. The server also supplies the name of the authoritative server that originally supplied the data. The client then has a choice: it can either use the non-authoritative answer, or issue a request for a fresh name resolution from the authoritative server. This is a trade-off between performance (using the cached data) and currency (asking for a fresh resolution each time). Usually, the cached data can be used safely, because DNS information doesn't change very often. The second technique for ensuring that caching data doesn't get too old is a procedure for limiting the persistence of DNS cached data. Each resource record has associated with it a time interval, called the Time To Live (TTL). Whenever a resource record is read from a server, the TTL for the record is also read. Any server caching the record is supposed to discard the record after that time interval expires. Each zone also has associated with it a default value for the TTL field to be applied to all records in the zone. This allows an administrator to select a TTL value for all records in a zone without having to enter TTL numbers for each record individually. At the same time, the administrator can assign an override TTL value to any records that need a number different from the default. This default TTL was originally found in the special Start Of Authority resource record for each zone, but is now done using a special directive in the zones master file.
It's worth emphasizing that DNS gives control over caching to the owner of the record, not whoever is running the DNS server doing the caching. While it is possible for a particular caching server to override the TTL and specify how long data will be held in its own cache, DNS is not supposed to work that way. The ability to specify a TTL on a record-by-record basis allows the persistence of cache data to be tailored to the needs of the individual data elements. Data that changes often can be given a small TTL value, while infrequently-modified records can be given a higher TTL. Selecting the TTL value must be done carefully; this is another trade-off between performance (which is optimized with higher TTL values, reducing the number of queries made for cached data) and freshness of the data (which increases as TTL is lowered).
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. |