Expiration TTLs

[Chris Buxton]

On Dec 2, 2012, at 6:10 PM, Paul Romano wrote:

> Chris.
> Thanks for the correction on the term TTL instead of timer. The engineer I inherited this environment from has the refresh set to 40 minutes and the zone expiration set to 2 hours. The explanation I got was that since we are authoritative for AD we want ensure that some kind of scavenging is in place. Your explanation suggests that the refresh time is strictly survivability and will not force an update if the serial numbers do not increment enough to implement the refresh.
> Am I stating this correctly? Any suggestions?

No, that's not quite right. Here are some definitions:

- Refresh timer: Controls how often a slave or stub server will check in with its configured master(s) to see if the zone has been updated, in the absence of a notify message. This check is an SOA query. This is related to master/slave and master/stub zone replication. If the serial number in the retrieved SOA record is larger than the serial number the server currently has -- even by 1 -- it triggers either a zone transfer (slave) or further queries for NS and A records (stub).

- Retry timer: If a refresh check fails, the slave or stub server will start the retry timer instead of the refresh timer. When it runs out, the server tries again to refresh from its master(s). The purpose is to control how often a slave or stub server refreshes while the master is unavailable.

- Expire timer: At every successful refresh check, this timer is reset. If the zone has not been refreshed by the time this timer runs out, the zone is expired. The server will not respond authoritatively (for slave zones); I'm not sure exactly what happens with stub servers, or whether they use this timer at all.

Typically, the refresh timer is set to the longest amount of time the organization will permit a slave to be out of date compared to its master -- depending on the usage, usually somewhere between 1 hour and 1 day. The retry timer is often set to a smaller value -- often between 10 minutes and 2 hours -- but I've seen installations where it is set longer (and not due to misunderstanding). The expire timer is generally set to between 1 and 6 weeks, to allow time for a problem with a master to be noticed and corrected before a slave stops responding authoritatively.

The notify mechanism, whereby an authoritative server proactively notifies other authoritative servers (typically a primary master notifying its slaves) when a zone is updated, augments this system of timers. When a notify is received, it causes a refresh check to occur immediately; this resets the timers.

Note that there is no scavenging function in BIND (nothing similar to MS DNS' aging and scavenging feature set), and no way to really implement it purely in DNS. Any attempt to use the expire timer to achieve this is evidence of a profound misunderstanding of the use of these timers.

Regards,
Chris Buxton
BlueCat Networks


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20121203/82a9f9c4/attachment.bin>