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

[Patrick McManus <[e-mail]>]

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.


>
> 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.