Tom Pusateri wrote:
I don’t think there is a TTL issue because, as we proposed it, the record is never returned in a query. The TTL could always be set to 0 for our purposes since it never leaves the authoritative servers.
tom, (tim,) to be clear, the ttl which must decline is that of the expiring record (or its rrset, due to atomicity), and not that of the TIMEOUT RR itself. you cannot hand out an AAAA or PTR (or in the degenerate case, an A RR) with a TTL of 3600 if it is due to expire in 600 seconds. that RR has to have its TTL adjusted during its final authority-TTL interval so that noone has it in cache beyond the time of its death by expiry.
in <http://family.redbarn.org/~vixie/defupd.txt> from 1996, this is described as follows:
3.4.1 - Initial TTL Limits The TTL of all added or updated RRs in the Update Section will be maximized silently to one half of the Expiry time. This will cause downstream caching name servers to purge RRsets containing this RR at least once before expiry. 3.4.2 - TTL Half Life Each time an RR's expiry reaches half of its previous value, that RR's TTL will be reduced to half of its previous value, until the TTL reaches a value less than or equal to sixty (60), i.e., one minute of real time, at which time the TTL will not be automatically reduced further by the primary master. It should be noted that RRs held in a server's memory need not be swept for half life processing, as long as the TTL changes appear when the RR next becomes externally visible, and as long as the ``zone has changed'' processing (see below) is done at the time of the half life expiration. Whenever the TTL is automatically reduced by this process, the zone will be considered ``changed'' for the purpose of automatic SOA SERIAL increment (see [UPDATE 3.6]) and real time zone slave notification (see [NOTIFY]).
-- P Vixie _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
