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

[Patrick McManus <[e-mail]>]

Thanks Mark,

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.

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.

fwiw I think I agree with the existing normative requirement - a response
ought to be valid at the time of receipt and it is very helpful to
harmonize the concepts of DNS and HTTP valid. This doesn't preclude fancy
stuff like stale-if-error or insane client max-age headers if a client is
motivated.

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?





On Tue, May 8, 2018 at 2:10 AM, Mark Nottingham <[e-mail]> wrote:

> On 3 May 2018, at 8:23 am, Paul Hoffman <[e-mail]> wrote:
> >
> > I'm going to re-up this here on the list. Please see the discussion on
> >   https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/153
> >
> > It would be handy if people who disagree with each other offer text *on
> the list*, not pull requests, specifying what they want the text in the
> draft to say. Then, people to try to come to consensus on this. (Yes, some
> people are more comfortable with editing pull requests; I feel that this
> issue is too important to not have the discussion here on the list.)
>
> Proposal:
>
> Cache Interaction {#caching}
>
> A DNS API request can pass through a hierarchy of caches that include both
> HTTP and DNS specific caches. HTTP caches are by design generic; that is,
> they do not understand this protocol. Even if a DNS API client has modified
> its cache implementation to be aware of DOH semantics, it does not follow
> that all upstream caches (for example, in proxies, server-side gateways and
> Content Delivery Networks) will be.
>
> As a result, DNS API servers need to carefully consider the HTTP caching
> metadata they send in response to GET requests (POST requests are not
> cacheable unless specific response headers are sent; this is not widely
> implemented, and not advised for DOH).
>
> In particular, they are encouraged to assign an explicit freshness
> lifetime (Section 4.2 of {{RFC7234}}), since HTTP caches can assign
> heuristic freshness otherwise (Section x.x of {{RFC7234}}), thereby taking
> control out of the hands of the DNS API server.
>
> Typically, the assigned freshness lifetime of a given DOH HTTP response
> will use the smallest TTL in the Answer section of the DNS response as a
> maximum. For example, if a HTTP response carries three RRsets with TTLs of
> 30, 600 and 300, the HTTP freshness lifetime usually ought to be no more
> than 30 seconds (e.g., "Cache-Control: max-age=30"), so that the RRset with
> the smallest TTL is not stale when retrieved from cache.
>
> This assures that none of the RRsets contained within are served stale
> from an HTTP cache.
>
> If the DNS response has no records in the Answer section, and the DNS
> response has an SOA record in the Authority section, the response freshness
> lifetime typically ought not be greater than the MINIMUM field from that
> SOA record (see {{RFC2308}}).
>
> The stale-while-revalidate and stale-if-error Cache-Control directives
> ({{?RFC5861}}) could be well suited to a DOH implementation when allowed by
> server policy. Those mechanisms allow a client, at the server's discretion,
> to reuse a cache entry that is no longer fresh.
>
> DNS API servers also need to consider caching when generating responses
> that are not globally valid. For instance, if a DNS API server customizes a
> response based on the client's identity, it would not want to allow global
> reuse of that response. This could be accomplished through a variety of
> HTTP techniques such as a Cache-Control max-age of 0, or by using the Vary
> response header ({{RFC7231}}, Section 7.1.4) to establish a secondary cache
> key ({{RFC7234}}, Section 4.1).
>
> DNS API clients MUST account for the Age response header's value
> ({{RFC7234}}) when calculating the DNS TTL of a response. For example, if a
> RRset is received with a DNS TTL of 600, but the Age header indicates that
> the response has been cached for 250 seconds, the remaining lifetime of the
> RRset is 350 seconds.
>
> DNS API clients that encounter stale responses (either because the HTTP
> freshness lifetime has passed, or because one or more RRset's lifetime has
> passed) can request a fresh copy by using the "no-cache" request cache
> control directive ({{RFC7234}}, Section 5.2.1.4) and similar controls. Note
> that some caches might not honour these directives, depending upon their
> configuration.
>
> HTTP conditional requests ({{RFC7232}}) may be of limited value to DOH, as
> revalidation provides only a bandwidth benefit and DNS transactions are
> normally latency bound. Furthermore, the HTTP response headers that enable
> revalidation (such as "Last-Modified" and "Etag") are often fairly large
> when compared to the overall DNS response size, and have a variable nature
> that creates constant pressure on the HTTP/2 compression dictionary
> {{RFC7541}}. Other types of DNS data, such as zone transfers, may be larger
> and benefit more from revalidation.
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>