Draft: draft-ietf-doh-dns-over-https-latest

Commentary: There are plenty of reasons to " extend " a TTL , such as if the TTL is below a configured threshold or if one can not reach the authoritative server again . The rules for TTLs is ( again ... ) being actively debated in the DNSOP WG , and it would be inappropriate for DOH to be more restrictive than DNS itself , thus the " SHOULD " . 
 Leaving a bare " SHOULD " there asks more questions than this text answers . If the considerations for extension are equivalent to those that apply to DNS , then saying that would help a lot . 
 I hear that , but I 'm at a loss of what words to use , given that the words do n't exist in the DNS specs either . What is important to me is that we do n't do more than the DNS specs , as vague as they are . 
 If implementations routinely ( or otherwise ) ignore the TTL , why not then say MUST ? Then it 's clear what the TTL is , and now they are just ignoring the TTL ( as per normal DNS practice ) . 
 Good point , will fix before pulling . 
 can you give a review here ?  apparently wo n't let me ask you directly because you created the PR ( which I seriously amended ) 
 The draft does n't really tackle the question of caching fully right now . I think that there is an implied hierarchy of caches that are in use . The query first hits the DNS stack , which maintains its own cache . Using the DNS TTL , that cache might decide to answer the query . Then there is an HTTP stack , which might maintain its own cache . Notably , none of the HTTP cache - busting techniques work from the perspective of the DNS client , so we have to be careful to observe that . This particularly ordering makes much worse . Finally , a DNS API server might maintain its own cache . 
 worth noting that the DNS client does n't have e2e cache busters with an http cache in the chain .. but does a traditional dns client have a cache buster ? I 've only really seen them explicitly ask another resolver .. which still seems possible here . 
 Could we add a sentence saying that the gateway decapsulating DNS - over - HTTPS MUST subtract the age of the HTTP response from the TTL inside the UDP packet before forwarding or consuming it ( assuming that would n't break DNSSEC ) ? I think it would help with some of the confusion about interaction between HTTP and DNS caches . 
 probably worth noting HTTP " Age " and things like stale - while - revalidate to help the reader , but we want to be careful not to look like we 're making changes to http when we are n't . There was also a clear call to have full caching examples that illustrate the interactions at hand . I think my read of the room in Singapore was that we do n't want to encourage rewriting the DNS records . ( DNSSEC being at least one reason ) . 
 I think we do want a DOH client to rewrite TTL when it is posing as a resolver to TTL - sensitive DNS clients . TTL is excluded from DNSSEC signing , so there should n't be a problem with that . 
 on caching .... we should also clarify behaviours of caching proxies . If a caching proxy starts caching based on GET parameters , we can hit an issue when the DOH backends are providing geo - targeted based on querier IP . The first query would warm the cache and the second query from a second totally unrelated subnet would get a cached answer which is not the one it would get if it were to query the DOH server directly . It may be worth having a section about potential caching caveats . see 
 what are you thinking of saying that is not covered by the http rfc 's ? ( 723x ) . 
 The current document talks about how using an ID of 0 is cache friendly . Which would lead to believe that if you have a layer of caching proxies in front of the DOH servers , they could cache the content and distribute it without re - querying the DOH backend for TTL time . While this will work just fine in most cases , there is a caveat when the DOH servers return queries that are different / customized for different subnets such as with a DNS global load balancer . I am not sure if this is covered in some aspect in one of the 723X RFCs , but I think we should drop a “ consideration ” for people to realize when to disable caching from reverse proxies . If there is already an RFC detailing this , great let ’s link to it . If not I do n’t think it deserves a lot , but we should let people be aware of the potential issue . 
 this issue is kind of broad .. I suggest we call the base fix here , and we 'll open follow on issues as necessary . 
 Why use SHOULD ? What would cause someone to extend the TTL beyond the freshness lifetime ?
Mailing list commentary: Hi list , Should we clarify the behaviour of caching proxies ? When using a proxy in front of DOH servers and doing targeting based on resolver IP or using ECS , the returned answer for a same query ( body param ) may be different depending on the client , but if the caching proxy caches based on GET parameters , there is chances to return answers that are supposed to be correct for another client . In draft - ietf - doh - dns - over - https-02 Section 5 : Using the GET method is friendlier to many HTTP cache implementations . and In order to maximize cache friendliness , DNS API clients using media formats that include DNS ID , such as application / dns - udpwireformat , SHOULD use a DNS ID of 0 in every DNS request . As much as we may instruct the client to cache the result , if there is proxies in the middle , those should not cache the answer they received from backend DOH servers .
Paragraph (version A):
The Answer section of a DNS response contains one or more RRsets.
(RRsets are defined in RFC7719.)  According to RFC2181, each resource
record in an RRset is supposed to have the Time To Live (TTL)
freshness information.  Different RRsets in the Answer section can
have different TTLs, though it is only possible for the HTTP response
to have a single freshness lifetime.  The HTTP response freshness
lifetime (RFC7234 Section 4.2) should be coordinated with the
Resource Record bearing the smallest TTL in the Answer section of the
response.  The HTTP freshness lifetime SHOULD be set to expire at the
same time any of the DNS Records reach a 0 TTL.  The response
freshness lifetime MUST NOT be greater than that indicated by the DNS
Record with the smallest TTL in the response.
Paragraph (version B):
The Answer section of a DNS response contains one or more RRsets.
(RRsets are defined in RFC7719.)  According to RFC2181, each resource
record in an RRset is supposed to have the Time To Live (TTL)
freshness information.  Different RRsets in the Answer section can
have different TTLs, though it is only possible for the HTTP response
to have a single freshness lifetime.  The HTTP response freshness
lifetime (RFC7234 Section 4.2) should be coordinated with the
Resource Record bearing the smallest TTL in the Answer section of the
response.  Specifically, the HTTP freshness lifetime SHOULD be set to
expire at the same time any of the DNS Records reach a 0 TTL.  The
response freshness lifetime MUST NOT be greater than that indicated
by the DNS Record with the smallest TTL in the response.
Paragraph (version A):
HTTP revalidation of cached DNS information may be of limited value
as revalidation provides only a bandwidth benefit and DNS
transactions are normally latency bound instead.  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.  DNS API servers may wish to consider
whether providing these optional response headers is worthwhile.
Paragraph (version A):
This protocol MUST be used with https scheme URI RFC7230.
Paragraph (version B):
This protocol MUST be used with the https scheme URI RFC7230.
Paragraph (version B):
A DOH API Client may utilize a hierarchy of caches that include both
HTTP and DNS specific caches.  HTTP cache entries may be bypassed
with HTTP mechanisms such as the Cache-Control no-cache directive
however DNS caches do not have a similar mechanism.
Paragraph (version B):
A DOH response that was previously stored in an HTTP cache will
contain the RFC7234 Age response header indicating the elapsed time
between when the entry was placed in the HTTP cache and the current
DOH response.  DNS API clients should subtract this time from the DNS
TTL if they are re-sharing the information in a non HTTP context
(e.g. their own DNS cache) to determine the remaining time to live of
the DNS record.
Paragraph (version B):
HTTP revalidation (e.g. via If-None-Match request headers) of cached
DNS information 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.
DNS API servers may wish to consider whether providing these
validation enabling response headers is worthwhile.
Paragraph (version B):
The stale-while-revalidate and stale-if-error cache control
directives may 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 under some
extenuating circumstances defined in RFC5861.
Paragraph (version B):
All HTTP servers, including DNS API servers, need to consider cache
interaction when they generate responses that are not globally valid.
For instance, if a DNS API server customized a response based on the
client's identity then it would not want to globally allow reuse of
that response.  This could be accomplished through a variety of HTTP
techniques such as a Cache-Control max-age of 0, or perhaps by the
Vary response header.