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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to