You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When responding to a query for something that was not in the cache, the TTL of the normal records is limited by the max-cache-ttl setting. However, the original TTL of RRSIG records is used.
If the response is later reused by the packet cache, the TTLs are decremented as appropriate (of course) but the RRSIG TTL is still not limited.
When the records come from the record cache, the TTLs are both capped.
Mainly this surprised me! I'm not aware of it doing any harm.
Short description
When responding to a query for something that was not in the cache, the TTL of the normal records is limited by the
max-cache-ttl
setting. However, the original TTL ofRRSIG
records is used.If the response is later reused by the packet cache, the TTLs are decremented as appropriate (of course) but the
RRSIG
TTL is still not limited.When the records come from the record cache, the TTLs are both capped.
Mainly this surprised me! I'm not aware of it doing any harm.
I think it violates RFC 4034, which says, "The TTL value of an RRSIG RR MUST match the TTL value of the RRset it covers." However, I'm not certain of the context. It might just mean "in an authoritative zone". It might not apply to resolvers.
Environment
Steps to reproduce
dig +dnssec +nocookie us ns
dig +dnssec +nocookie us ns
dig +dnssec us ns
Expected behaviour
max-cache-ttl
for everything.Actual behaviour
Original TTLs for
RRSIG
records.(I have
max-cache-ttl=172800
. Personal preference.)Other information
On the other hand, it is called
max-cache-ttl
, notmax-not-actually-from-the-cache-ttl
. ;-)Configuration:
Includes/Lua are the package defaults.
The text was updated successfully, but these errors were encountered: