Expiring Zone Data

To make all this interaction work properly there are mechanisms to help reduce the chances of having different versions of zone data cached on DNS servers around the globe. Although there are a number of aspects and solutions to this issue, the main players are expiry times.

Here are some key times recorded in the zone file:

• time to start checking for updated zones (used by Slave Server)
• time to discard zone data because it is too old and no Master could be contacted (used by Slave Server)
• time to expire cached records (used by Caching-only Server)
• time to wait before resending a failed lookup where server reported hostname does not exist (used by Caching-only Server)

The purpose of the the last item above, known as a "negative cache" time is so in cases like a typo in a web link, remote servers don't continually request the same bad hostname.

It's important to remember that a Non-Authoritative answer, even within it's expiry time, may not reflect the latest changes to the zone records if they have been recently modified.

These expiry times vary depending on the expected rate of change to data on the target server but some typical times are 1 hour or 24 hours or even two weeks. There are no set rules around these times which are set by the DNS Administrator (or possibly some BIND frontend).

It is possible for a DNS Slave (a slave is authoritative) to return the wrong information if it has not received an updated copy of the zone file from the Master, however this is not usually an issue as BIND looks after this aspect and a DNS Administrator also has a few ways to force updates of critical changes.

master and slave servers

are considered to be authoritative for the zone

any name server

can serve a mix of primary and slave roles for different zones

all name servers

cache their query results. This increases performance by magnitudes over reading a file.