]> Supporting Redirect Responses in DNS Queries over HTTPS (DoH) Orange
Rennes 35000 France mohamed.boucadair@orange.com
UK neil.cook@noware.co.uk
McAfee, Inc.
Embassy Golf Link Business Park Bangalore Karnataka 560071 India TirumaleswarReddy_Konda@McAfee.com
Citrix Systems, Inc.
USA dwing-ietf@fuggles.com
ADD This document clarifies whether DNS-over-HTTPS (DoH) redirection is allowed and specifies how redirection is thus performed.
This document clarifies the intent of DNS-over-HTTPS (DoH) whether redirection is allowed (), and subsequently specifies how redirection is performed (). This document adheres to Section 4.3 of which discusses the need for protocols using HTTP to specify redirect handling to avoid interoperability problems.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. "A/AAAA" is used to refer to "A and/or AAAA records".
indicates that the support of HTTP redirection is one of DoH design goals (Section 1): "The described approach is more than a tunnel over HTTP. It establishes default media formatting types for requests and responses but uses normal HTTP content negotiation mechanisms for selecting alternatives that endpoints may prefer in anticipation of serving new use cases. In addition to this media type negotiation, it aligns itself with HTTP features such as caching, redirection, proxying, authentication, and compression. The integration with HTTP provides a transport suitable for both existing DNS clients and native web applications seeking access to the DNS." Nevertheless, Section 3 of indicates the following: "This specification does not extend DNS resolution privileges to URIs that are not recognized by the DoH client as configured URIs." This looks like an internal inconsistency of that is worth the clarification: is redirection allowed or not? Also, Section 3 of indicates that: "A DoH client MUST NOT use a different URI simply because it was discovered outside of the client's configuration (such as through HTTP/2 server push) or because a server offers an unsolicited response that appears to be a valid answer to a DNS query." Nevertheless, does not: specify under which conditions a discovered different URI can be used. describe how a different URI can be discovered using HTTP/2 server push. The only available example in the mailing list archives clarifies that server push is an example of unsolicited responses. The text was updated late in the publication process to address this comment: https://mailarchive.ietf.org/arch/msg/doh/f_V-tBgB-KRsLZhttx9tGt75cps/. The example provided in the thread (server push) is related to the second part of the above excerpt. clarify that unsolicited messages from a trusted DoH server should be excluded. A clarification is proposed in . This clarification focuses on a "different URI" that might be discovered while communicating with an HTTP server. Additionally, assuming that redirection is allowed, this specification recommends how it is achieved, specifically regarding inline resolution of any domain name in the redirect URI. This is required because redirection to a domain-based URI requires DNS resolution of that domain name, which creates a potential bootstrapping problem (e.g., If DoH server is the only configured DNS server, redirecting the client to a new server by presenting a name will fail).
OLD: A DoH client MUST NOT use a different URI simply because it was discovered outside of the client's configuration (such as through HTTP/2 server push) or because a server offers an unsolicited response that appears to be a valid answer to a DNS query. NEW A DoH client MUST NOT use a different URI that was discovered outside of the client's configuration when communicating with HTTP servers except via HTTP redirection from a configured URI (Section 6.4 of ). Also, a DoH client MUST ignore an unsolicited response (such as through HTTP/2 server push) that appears to be a valid answer to a DNS query unless that response comes from a configured URI (as described in Section 5.3).
Redirection in DoH is slightly different from "regular" HTTP redirection, in that the DoH server may be the only configured DNS resolver for the client (e.g., as per Section 7.1 of ). In that case, and assuming the redirect URI uses a domain name, the client will be unable to contact the URI returned in the redirect response unless the DoH server provides the resolution information for that domain as part of the response. Even if a DoH client has a plaintext DNS resolver configured, using that resolver is considered as a minimal privacy leakage . Servers supporting DoH redirect MUST support returning the redirect response body mechanism described hereafter. Note: "MUST" is used here because resolving the redirect name using Do53 (especially for the redirection discussion in ) will fail in some configurations, e.g., https://wiki.mozilla.org/Trusted_Recursive_Resolver (network.trr.mode=3). Concretely, the DoH server returns in the response body a DNS response with an 'application/dns-message' media type as specified in Section 6 of , containing any A and AAAA records for the domain name in the redirect URI, including any CNAMEs. For example, if the redirect URI contains the domain name "redirect.example.com", and "redirect.example.com" is a CNAME pointing to "real.example.com", then an example response body would contain: A CNAME record for "redirect.example.com" Any A records for "real.example.com" Any AAAA records for "real.example.com" This approach is simple; no client or server support of server push is required, and it is also more efficient in terms of the amount of data transmitted. An early version of this document considered the use of server push to provide the client with the required A/AAAA information (). Nevertheless, such proposal has issues as discussed in Section 4.14 of .
This section specifies how DoH server redirection can be safely used to present a different URI to a requesting DoH client (). To that aim, the DoH server may use HTTP redirection (Section 6.4 in or ) and the mechanism discussed in to inform the client about the new URI and location of the DoH server. The mechanism discussed in MAY be implemented by a DoH server if the DoH service is authoritatively available at a separate network location. This mechanism requires the alternative service to present a certificate for the origin's host name. Nevertheless, is not an option for some redirection scenarios (e.g., Section 7 of ). Additional complications arise to provide redirection for the latter scenarios: Every GET request with a new query name will require redirection, which is suboptimal. Indeed, a redirect will only affect a request and the DoH client will need to contact the base server for every request and get redirected. Also, permanent redirects for all these queries would also bloat the client's HTTP cache. Using POST would solve the issue. Nevertheless POST responses are not widely cached as per Section 4.2.3 of . What about relaxing so that the alternate service presents a certificate of a sub-domain of the Origin? A solution that provides the same benefits as POST but without the caching issues is needed. Such solution must then rely upon HTTP GET method. A candidate solution using GET is described hereafter. At bootstrap, the DoH client sends a GET request against a well-known URI (can also be used to retrieve the URI Templates ). The server can redirect the client to an alternate server. The server's response will include: the Authentication Domain Name (ADN) of the redirect server, a list of IP addresses to locate the redirect server, a list of URI Templates (e.g., https://cpe123.example.net/dns-query{?dns}), CNAME, etc. Subsequent queries will be sent to the redirected server.An example of such response is depicted in . The structure of the response is inspired by Section 4.4.2 of .
Unlike the GET discussed in the first bullet, this approach does not bloat the cache.
DoH-related security considerations are discussed in Section 9 of . Section 9 of describes security considerations related to the use of alternate services. DNS clients that ignore authentication failures and accept spoofed certificates will be subject to attacks (e.g., redirect to malicious servers, intercept sensitive data).
This document does not request any action from IANA.
Many thanks to Christian Jacquenet, Philippe Fouquart, and Ben Schwartz for the comments.
The DoH specification allows the use of server push to send DNS responses (Section 5.3 of ). The typical use case for server push is when the server knows that the client will need to make a request for a resource, and so provides the answer to that request via the server push mechanism. Sending answers to queries implies that the DoH server performs those queries itself, or retrieves them from its cache. In this case, the DoH server knows that the DoH client will need to resolve the domain returned in the redirect URI. Therefore, after receiving the initial request which would lead to a redirect response, but before returning the response, the server sends a push promise frame (Section 8.2.1 of ) request URL to retrieve the A/AAAA resource records for the domain in the redirect response (for example, if the domain has both A and AAAA records, two push promise frames would be sent). Any intermediate CNAME records would result in additional push promise frames. Promise requests cannot contain a request body as specified in Section 8.2.1 of , thus they use the GET method specified in Sections 4.1 and 6 of . The A/AAAA responses are then sent in separate streams as specified in Section 8.2.2 of . Finally, the redirect response itself is sent. An example of the use of server push for redirection is shown in .
| |====== DNS Request for example.com/A ==================>| |<===== Push Promise: GET redirect.example.com/A ========| |<===== Push Promise: GET redirect.example.com/AAAA =====| |<===== Redirect Response: https://redirect.example.com =| |<===== Push Response for redirect.example.com/A ========| |<===== Push Response for redirect.example.com/AAAA======| | ... | ]]>
The advantage of using server push to provide the DNS resolution information of the redirect domain is that, assuming that the DoH client already supports unsolicited server push messages, then this approach should work without any changes. Disadvantages include the possibility that DoH clients do not support server push.