[dns-operations] RRSIG expiry versus TTL

[Vladimír Čunát]

On 05/09/2021 19.31, Andrew Sullivan wrote:
> This is false in multiple ways.  First, RRSIGs are in fact resource 
> records and it _is_ possible to query for them directly:

I would not advise using QTYPE=RRSIG.  Mainly because you may get sigs 
for some other versions of RR sets than those obtained in a different 
DNS message.  Also, RRSIG queries have similar DoS potential as ANY. 
https://datatracker.ietf.org/doc/html/rfc8482#section-7

Generally I'd recommend to treat sigs as attached to their respective RR 
sets.


>>> the RRSIG TTL should match the NS record TTL, but ..., the validating
>>> resolver does not care, and should not, about RRSIG TTL. So the
>>> difference between the expiration of the rrsig and the TTL shouldn't
>>> or doesn't impact the online services.
>
> Also false.  Caches do not look at the RRTYPE to decide how to cache.  
> They just cache whatever comes along for the TTL.  If your RRSIG 
> expires while it is cached, you will go bogus.  This is discussed (IMO 
> somewhat elliptically, because there was some controversy about what 
> the Right Thing was, IIRC, and it never really got resolved) in RFC 6781.

Well, that depends on the caches.  RRSIGs do have special rules for TTL 
handling... which is surely the reason why dnsviz says "cache of 
*non-validating* resolver"  See 
https://datatracker.ietf.org/doc/html/rfc4034#section-3

> The TTL value of an RRSIG RR MUST match the TTL value of the RRset it covers.

Also, TTL should be trimmed (by signers and validators) not to go past 
RRSIG expiration (or original TTL).  I can't recall where this is stated 
and how strongly.


To be clear, I agree with dnsviz that the state was not correct. I don't 
like arguments in style "I tried it and it worked for me, so it's OK".  
They make me dislike Postel's law.


--Vladimir | knot-resolver.cz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20210906/ce7f5929/attachment.html>