Thank you both. On Wed, Jul 24, 2019 at 6:29 PM Matthijs Mekking <matth...@pletterpet.nl> wrote:
> RFC 4035 says: > > If the resolver accepts the RRset as authentic, the validator MUST > set the TTL of the RRSIG RR and each RR in the authenticated RRset to > a value no greater than the minimum of: > > o the RRset's TTL as received in the response; > > o the RRSIG RR's TTL as received in the response; > > o the value in the RRSIG RR's Original TTL field; and > > o the difference of the RRSIG RR's Signature Expiration time and the > current time. > > That last bullet point tells that if the signature's expiration time is > smaller than the TTLs received in the response, the RRset is cached for > at most the duration until the signature expires. > > On 7/24/19 7:50 AM, Nick Johnson wrote: > > Suppose I receive a response containing an RRSET with records with > > ttl=3600, signed with an RRSIG that has an expiration timestamp 60 > > seconds from now. > > > > After validating the signature, can I cache the RRSET for 3600 seconds, > > or only for 60 seconds? If the former, and the RRSET is a DNSKEY, can I > > rely on it to validate other RRSIGs for the entire 3600 seconds? > > In your example, the RRset must be cached for at most 60 seconds. > > Best regards, > > Matthijs > > > > > > -Nick Johnson > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
