title: Associating a DoH Server with a Resolver abbrev: Resolver Associated DoH docname: draft-ietf-doh-resolver-associated-doh
stand_alone: true
ipr: trust200902 kw: Internet-Draft cat: std
pi: toc: yes tocdepth: 4 sortrefs: yes symrefs: yes
ins: P. Hoffman name: Paul Hoffman org: ICANN email: [email protected]
normative: I-D.nottingham-rfc5785bis: RFC1035: RFC2119: RFC6570: RFC7858: RFC8174: RFC8484: SUDN: title: "Special-Use Domain Names" target: "https://www.iana.org/assignments/special-use-domain-names/"
informative: RFC4033: RFC6761: RFC6891: RFC7231: RFC8259:
--- abstract
Browsers and web applications may want to know if there are one or more DoH servers associated with the DNS recursive resolver that the operating system is already using. This would allow them to get DNS responses from a resolver that the user (or, more likely, the user's network administrator) has already chosen. This document describes two protocols for a resolver to tell a client what its associated DoH servers are. It also describes a protocol for a client to find out the address of the resolver it is using, if it cannot find that address by an operating system API or some other means.
--- middle
DoH {{RFC8484}} requires that one or more DoH servers be configured for the DoH client. That document does not say how the DoH servers are found, nor how to select from a list of possible DoH servers, nor what the user interface (UI) for the configuration should be.
There is a use case for browsers and web applications to want the DNS recursive resolver(s) configured in the operating system to use DoH for DNS resolution instead of normal DNS, but to do so to at a DoH server specified by the configured resolver rather than configuring those applications with DoH server information.
For example, a recursive resolver configured by the operating system may know how to give correct answers to DNS queries that contain names that are only resolvable in the local context, or resolve differently in the local context. Similarly, the recursive resolver configured in the operating system may implement security policies such as malware prevention that are not implemented in the same way in DoH servers not affiliated with the user's organization. Users typically configure their DNS recursive resolvers with automatic configuration from a protocol such as DHCP; less often, they use manual configuration (such as manually editing a /etc/resolv.conf file).
The expected use cases for DoH are browsers and web applications that would otherwise get their DNS service from the resolver configured by the operating system. The user of the client might have a preference for using a DoH server for the benefits that DoH brings, and they might need to use a DoH server that is associated with the resolver that the computer is currently using for the reasons listed above. In a common scenario, users may be required to use only resolvers that are approved by their organization's network operators.
The URI templates of the DoH servers associated with a resolver might be hosted on the resolver itself, or a resolver hosted by the same operator, or even hosted somewhere else. The latter could be used by resolver operators who don't want to host DoH servers but trust another operator to do so.
To address these use cases, this document defines protocols to get the list of URI templates {{RFC6570}} or addresses for the DoH servers associated with at least one of the resolvers being used by the operating system on the system on which the application is being run.
-
"DoH servers from HTTPS", described in {{doh_from_https}}, is a well-known URI {{I-D.nottingham-rfc5785bis}} that can be resolved to return the URI templates in an HTTP response.
-
"DoH servers from DNS", described in {{doh_from_dns}}, is a new special use domain name (SUDN) {{RFC6761}} that can be queried to return the URI templates as a TXT RRset.
-
"resolver addresses from DNS", described in {{resolver_from_dns}}, is a new SUDN that that can be queried to return the addresses as A and AAAA RRsets.
For these protocols to be useful in a browser, the browser needs to have an entry in its configuration interface where the allowed DoH servers are listed that indicates that a DoH server from the configured Do53 or DoT resolver is allowed. That wording might say something like "DoH server associated with my current resolver" (or "servidor DoH asociado con mi resolución actual" or "serveur DoH associé à mon résolveur actuel"). Alternatively, these protocols might be the default for a browser, and naming specific other DoH servers might be done with a UI.
The protocols described here are meant for a browser to be able to start using DoH based on its current interactions with the resolver from the operating system on which the browser is running: they are not expected to work without being able to do DNS resolution. Even "DoH servers from HTTPS", which ostensibly only needs an IP address, is likely to need DNS resolution for things like OCSP servers during the setup of TLS.
In this document, "client" means either a browser or web application. When one or the other is named explicitly,
In this document, "browser" means any application that can open ports in the operating system. This odd usage of the term "browser" is adopted from [RFC8484].
In this document, "DoT" is used to indicate DNS over TLS as defined in {{RFC7858}}.
In this document, "Do53" is used to indicate DNS over UDP or TCP as defined in {{RFC1035}}.
"DoH client" and "DoH server" are defined in {{RFC8484}}.
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 {{RFC2119}} {{RFC8174}} when, and only when, they appear in all capitals, as shown here.
To find the URI templates for DoH servers associated with a resolver whose address is already known, a browser or web application can use the well-known URI described in this section. To find the IP address of the resolver used by the operating system on which a browser is running, a browser can use either an operating system function (if such a function is available to it) or the process described in {{resolver_from_dns}}. (A web application can also use the process described in {{resolver_from_dns}}, and thus use this well-known URI.)
To find the DoH servers associated with a resolver, the client MUST use the following query:
https://IPADDRESSGOESHERE/.well-known/doh-servers-associated/
The resolver replies with its associated DoH servers as URI templates {{RFC6570}}. The HTTP response header MUST contain an appropriate HTTP status code as defined in {{RFC7231}}. Successful responses MUST set the Content-Type set to "application/json".
The returned JSON object {{RFC8259}} MUST contain a member whose name is "associated-resolvers" and whose value is a JSON array. The array contains zero or more JSON strings, each of which is a single URI template.
If the array of URI templates returned is empty, that indicates that the resolver does not have any DoH servers associated with it.
For example, the returned object might look like:
{ "associated-resolvers":
[ "https://dnsserver.example.net/dns-query{?dns}",
"https://webhost.example.net/a/b/c/dns-query{?dns}" ]
}
If there are no associated DoH servers, the returned object would look like:
{ "associated-resolvers": [ ] }
If the TLS authentication for the query fails, the browser MUST abort the connection without sending the HTTP request, and it cannot assume anything about whether the resolver has any DoH servers associated with it.
A client using this protocol MUST try to establish a new list of DoH servers associated with a resolver every time the configured resolver in the operating system changes.
The HTTP query follows all the normal rules for HTTP. Thus, the result of sending this query can be an HTTP redirect to a different server. Also, the result of the query might be served from an HTTP cache.
To find the URI templates for DoH servers associated with a resolver, a browser sends that resolver a query for "resolver-associated-doh.arpa" in class IN with the RRtype of TXT {{RFC1035}} (that is, the query is resolver-associated-doh.arpa/IN/TXT). This protocol is most likely useful only to browsers that can call operating system functions that in turn query the DNS for text records. Web applications cannot currently call such operating system functions.
As described in {{ianacons}}, the zone resolver-associated-doh.arpa is not actually delegated and never will be. The resolver that receives this query acts as if it is delegated, and adds its own TXT records to the answer. The resolver replies with its associated DoH servers as URI templates in the TXT RRset in the Answer section. The resolver can generate this reply with special code to capture queries for "resolver-associated-doh.arpa"; if the resolver can be configured to also be authoritative for some zones, it can use that configuration to actually be authoritative for "resolver-associated-doh.arpa".
A resolver that understands this protocol MUST send a TXT RRset in the Answer section. Each TXT record contains one URI template. If a resolver that understands this protocol has no associated DoH servers, the TXT RRset contains exactly one record that has an empty string as the RDATA; that is, the RDLENGTH in that record is 1, and the RDATA contains just the byte 0x00.
An example of the TXT RRset (in DNS master file format) might be:
$ORIGIN resolver-associated-doh.arpa.
IN TXT "https://dnsserver.example.net/dns-query{?dns}"
IN TXT "https://webhost.example.net/a/b/c/dns-query{?dns}"
If there are no associated DoH servers, an example of the the TXT RRset (in DNS master file format) might be:
$ORIGIN resolver-associated-doh.arpa.
IN TXT ""
The client uses the TXT records in the response to the resolver-associated-doh.arpa/IN/TXT query as a list of the URI templates of the DoH servers associated with the resolver. Note that TXT records can contain multiple "character-strings" {{RFC1035}}; for this protocol, all characters-strings in a TXT record are concatenated to form a single URI template.
A client using this protocol MUST try to establish a new list of DoH servers associated with a resolver every time the configured resolver in the operating system changes.
Browsers which cannot get the IP address(es) of the resolver configured by the operating system using APIs are still able to use an operating system function such as getaddrinfo() or its equivalents to convert host names into IP addresses through the stub resolver in the operating system on which they are running. Web applications also can convert host names to IP addresses. Either can use a new SUDN to find the address(es) of the resolvers configured by the operating system.
A browser or web application uses it normal interface for getting IP addresses for a hostname, and uses the SUDN "resolver-addresses.arpa" as the hostname.
As described in {{ianacons}}, the zone resolver-addresses.arpa is not actually delegated and never will be. The resolver acts as if that name is delegated, and returns its own A or AAAA addresses in the records in the answer. The resolver can generate this reply with special code to capture queries for "resolver-addresses.arpa"; if the resolver can be configured to also be authoritative for some zones, it can use that configuration to actually be authoritative for "resolver-addresses.arpa".
A client using this protocol MUST try to establish a new list of DoH servers associated with a resolver every time the configured resolver in the operating system changes.
The "DoH servers from HTTPS" "DoH servers from DNS" return lists of DoH servers, and those lists can have more than one element. The DoH client can choose any of the servers in the list; that is, there is no inherent "preference" for any of the servers returned. From a mathematical viewpoint, the lists can better be considered as sets.
IANA will record the domain name "resolver-associated-doh.arpa" in the "Special-Use Domain Names" registry {{SUDN}}. IANA MUST NOT delegate resolver-associated-doh.arpa in the .arpa zone.
IANA will record the domain name "resolver-addresses.arpa" in the "Special-Use Domain Names" registry {{SUDN}}. IANA MUST NOT delegate resolver-addresses.arpa in the .arpa zone.
Before this draft is complete, mail will be sent to [email protected] in order to be registered in the "Well-Known URIs" registry at IANA. The mail will contain the following:
URI suffix: doh-servers-associated
Change controller: IETF
Specification document(s): draft-ietf-doh-resolver-associated-doh
Status: permanent
Allowing a user to use DoH to a server associated with the resolver in use by the operating system on the user's machine, instead of using Do53 to to the resolver in use by the operating system on the user's machine, can increase communication privacy (confidentiality and integrity) because of the TLS protection. However, using a DoH server can also reduce overall privacy because both TLS and HTTPS allow for user identification in ways that plain Do53 does not.
When a Do53 or DoT server indicates that a particular DoH server is associated with it, the client might assume that the DoH server has the same information privacy policies as the Do53 or DoT server. Therefore, a Do53 or DoT server SHOULD NOT recommend a DoH server unless that DoH server has the same (or better) information privacy policy as the Do53 or DoT server.
A browser that has both a stub resolver stack and a TLS stack that is independent of HTTP could make a DoT connection to the resolver being used by the operating system.
If DNS queries sent from stub resolvers to recursive resolvers are not sent over transports that assure data integrity and server authentication, the "DoH servers from DNS" and "Resolver addresses from DNS" protocols are susceptible to on-path attackers directing a user to a DoH server that is not actually associated with their resolver. Do53 is not a secure transport, and neither is DoT using the opportunistic profile.
The DNS responses used in "DoH servers from DNS" and "Resolver addresses from DNS" cannot be validated with DNSSEC {{RFC4033}}, and thus even a validating stub resolver would treat them the same as any other DNS responses in unsigned zones.
When considering whether or not to use an associated DoH server it would be helpful to understand the security and privact properties of the operating systems default stub resolver. Unfortunately, there is currently no way for an application to know whether the operating system's stub resolver is using a transport that assures data integrity such as DoT or DoH. Even if an application could determine the use of an alternative transport, the application would also need to know whether the transport was authenticated or what policies it is enforcing.
--- back
The primary use case for these protocols is a browser or web application that is getting name resolution through the stub resolver on the computer on which it is running wanting to switch its name resolution to DoH.
An earlier design suggestion was to use a new RRtype with a query to ./IN/NEWRRTYPE. However, it was pointed out that this would not work going through stub resolvers that validate DNSSEC.
An earlier design suggestion was to use DHCP to tell the operating system the DoH servers that the stub resolver might use. That protocol is orthogonal to the one in this document in that it addresses a different use case. If both the protocol in this document and a DHCP-based protocol are standardized, they could co-exist. However, there is no current mechanism for a stub resolver to tell a browser, or a web application, what DoH server the stub resolver is using, so DoH configuration in the stub resolver would not prevent the browser from trying to find a DoH server on its own.
An earlier design suggestion was to use an EDNS0 {{RFC6891}} extension. The design chosen in this document meets the use case better because applications cannot communicate EDNS0 extensions to the stub resolver.
{:numbered="false"}
The use case in this document was inspired by discussions and the DRIU BoF at IETF 102 and later in the DNSOP Working Group. Vladimír Cunat, Philip Homburg, Shumon Huque, Martin Thomson, Eric Rescorla, and Tony Finch offered useful advice to improve versions of the protocol before it came to the DOH Working Group.