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

[Mark Nottingham <[e-mail]>]

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/