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

[Ted Hardie <[e-mail]>]

Howdy,

Some comments in-line, thanks for the text.

On Mon, May 7, 2018 at 5:10 PM, 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.
>
> I think it would be useful to specify whether we are talking only about
the upstream network caches or the local caches when using phrases like
"pass through" (the use of a local HTTP cache here by a DNS API service to
furnish data to a DNS client should either be explicitly in or out of
scope, in other words).


> 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.
>
> I agree with other that the use of RFC 2119 language like SHOULD is
appropriate here.  We may want to allow for some variance, but a very clear
expectation will help more than "encouraged" will, at least in my opinion.


> 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.
>
> Again, I think "Typically...will" should transition to an RFC 2119
requirement.  This may mean making it explicit that when the HTTP responder
cannot calculate the smallest TTL it should use cache-control methods to
limit caching.


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

I'm concerned about the use of these with responses that contain multiple
records.  If this text is retained, I think it will have to specify how to
manage the multiple record case.


>
> 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.
>
>
Should a DNS API client consider such a response as equivalent to SERVFAIL?


> 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.
>
> I would have, perhaps naively, expected zone transfers to be the result of
POSTs rather than GETs.  Which types of results can be be retrieved by each
might be useful to lay out somewhere, just to forestall confusion like mine.

thanks,

Ted



>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>