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

[Ben Schwartz <[e-mail]>]

On Tue, May 8, 2018 at 12:25 PM, Patrick McManus <[e-mail]>
wrote:

> On Tue, May 8, 2018 at 1:54 PM, Mark Nottingham <[e-mail]> wrote:
>
>>
>> > This text reads more fluidly, and that is nice. OTOH it doesn't do much
>> to resolve the core tension in https://github.com/dohwg/draft
>> -ietf-doh-dns-over-https/issues/153. The current ID uses normative
>> language for creating http freshness lifetimes from DNS sets.
>>
>> Well, Paul asked for text...
>>
>> I forgot to say thank you for the text - I just was trying to communicate
> that I think the rationale is more of the blocker for this issue than the
> text. So that's what I'm trying to drill down on here..
>
>
>
>> > Comments from you and Martin (and this text suggestion) support
>> changing this from normative language to advice. The other comments favor
>> the more deterministic behavior we currently have.
>> >
>> > Can you help me understand the argument you are making? Martin
>> primarily suggests having the DNS code check the TTL before use rather than
>> relying on the cache to serve fresh responses - but I think that particular
>> point has met significant pushback largely from the DNS experts in the
>> community..
>>
>> I'm not hearing pushback to this approach on this thread so far, so I'd
>> like to hear (here) what the issue is.
>>
>
> Ben and Dave pushed back in the github - it would be helpful to hear them
> here as well, I agree.
>

As a standards matter, it seems to me that the DNS experts are still
working out the details of when it might be OK to go past the end of TTL
(e.g. https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale-00).
Allowing DOH to violate TTL would risk pre-empting that DNS discussion.  I
think it's worthwhile for us to be conservative in what we send until
serve-stale and related DNS issues are resolved.


>
>>
>> HTTP caches can and do serve stale content even without those "fancy"
>> things (e.g., when the origin server is disconnected). If you're using HTTP
>> and caching has taken place, you fundamentally need to understand how old
>> the response you're using is if it's time-sensitive -- which this is. That
>> means checking the Age.
>>
>>
> This text doesn't prevent you from serving anything - it just defines how
> you set the freshness lifetime so that an Age calculation at the HTTP level
> actually reflects the fresh/stale status of the DNS content in a
> conservative fashion. A client very concerned about that could make the
> calculation or it can assume that the server did the best it could do (i.e.
> its either fresh, or stale in extremis so use it anyhow) and use it once
> for record types like A.
>
> > The existing draft seems to have caused a little bit of confusion by
>> saying SHOULD match rather than MUST match.. The intent for that was to
>> allow for http lifetimes less than DNS lifetimes (particularly max-age:0 if
>> you cannot figure out the DNS lifetime from your HTTP server code). The
>> subsequent sentence enforced the >= property.
>> >
>> > Is there another aspect to the question I'm missing?
>>
>> It looks like you're using RFC2119 requirements to bring attention to
>> important parts of the specification ("we really mean that this could trip
>> you up"), rather than stating actual requirements for interoperability.
>> These MUSTs aren't testable, and they may be too confining in some
>> deployments. This stuff really is advice, of the "if it hurts, don't do
>> that" sort -- not requirements.
>>
>>
> I must be misunderstanding what you mean by not testable - the alignment
> of expiration information seems pretty observable. And there is an
> operational impact to terminal clients without caches (either DNS or HTTP)
> which simply want to lookup a record and use it having to retry to get
> non-expired info (and the rather large risk of them not trying and using
> old data instead). So I guess you can argue that without 2119 language the
> DOH client and server can communicate, but without normative provisions
> constraining the server you can't interop well with the Internet.. seems
> 2119 in scope to me.
>
>
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>
>