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

[Mark Nottingham <[e-mail]>]

> On 8 May 2018, at 9:37 pm, Patrick McManus <[e-mail]> wrote:
> 
> 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.

Well, Paul asked for text...

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

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

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.

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


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

--
Mark Nottingham   https://www.mnot.net/