Requesting tips on setting TTLs so that expired RRSIG data doesn't stay in the zone

[Chris Buxton]

On Dec 14, 2012, at 2:48 AM, GS Bryan wrote:
> Reference: http://dnssec-debugger.verisignlabs.com/imouto.my
> 
> How to configure named (version BIND 9.9.2-P1-RedHat-9.9.2-2.P1.el5)
> so that expired RRSIG data doesn't stay in the zone? I heard it has
> omething to do with the TTL of the zone (the expiry timer in that
> zone's SOA).

In DNS, it's important to correctly understand the terminology and use it with precision. Failure to do so leads to misunderstandings like the one displayed above.

A zone doesn't have a TTL. It might have a default TTL expressed in the master copy of the zone, but this only has an effect on the way the zone is loaded by the primary master name server. As far as all other name servers are concerned, there is no default TTL, and every record has an explicit TTL.

The expire timer value in the zone's SOA record is not a TTL. Its only effect is on slave servers that fail to successfully refresh the zone from their master server(s) within that period.

The existence of records in an authoritative zone is not affected by TTLs. However, the caching of records by other name servers is affected by TTLs. Perhaps you were really trying to ask how to make sure stale RRSIG records are removed from the caches of other name servers in a timely manner; in that case, the TTLs of the specific records could come into play.

However, expired RRSIGs are discarded by validating resolvers. The validating resolver, on encountering a stale RRSIG, would typically query one of the zone's authoritative servers directly (in the absence of forwarding configuration) to get a current RRSIG record. Therefore, the only problem these expired RRSIGs might cause is a little bit of wasted bandwidth.

Chris Buxton
BlueCat Networks