Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL?

[Paul Hoffman <[e-mail]>]

On May 8, 2018, at 2:45 AM, Miek Gieben <[e-mail]> wrote:
> I like this text, but is the working-group OK with *not* mentioning DNSSEC?
> 
> If you only look a the TTL and not the inception and expiry dates of RRSIGs you can easily serve BAD data.

That's not how I read RFC 4033. It says:

8.1.  TTL Values vs. RRSIG Validity Period

   It is important to note the distinction between a RRset's TTL value
   and the signature validity period specified by the RRSIG RR covering
   that RRset.  DNSSEC does not change the definition or function of the
   TTL value, which is intended to maintain database coherency in
   caches.  A caching resolver purges RRsets from its cache no later
   than the end of the time period specified by the TTL fields of those
   RRsets, regardless of whether the resolver is security-aware.

   The inception and expiration fields in the RRSIG RR ([RFC4034]), on
   the other hand, specify the time period during which the signature
   can be used to validate the covered RRset.  The signatures associated
   with signed zone data are only valid for the time period specified by
   these fields in the RRSIG RRs in question.  TTL values cannot extend
   the validity period of signed RRsets in a resolver's cache, but the
   resolver may use the time remaining before expiration of the
   signature validity period of a signed RRset as an upper bound for the
   TTL of the signed RRset and its associated RRSIG RR in the resolver's
   cache.

To me, "may use the time remaining before expiration" does not sound a requirement, or even an expectation. 

--Paul Hoffman