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 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 Name Server Concepts and Operation

DNS Root Name Servers 1 2 3 DNS Name Server Load Balancing

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 zone’s 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).

DNS Root Name Servers 1 2 3 DNS Name Server Load Balancing