]> Quad9

jtodd@quad9.net

Microsoft

tojens@microsoft.com

Internet ADD Internet-Draft This document defines Encrypted DNS Server Redirection (EDSR), a mechanism for encrypted DNS servers to redirect clients to other encrypted DNS servers. This enables dynamic routing to geo-located or otherwise more desirable encrypted DNS servers without modifying DNS client endpoint configurations or the use of anycast by the DNS server. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the WG Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Encrypted DNS Server Redirection (EDSR) is a protocol that allows an encrypted DNS resolver whose configuration is well known to clients to redirect them to other, more desirable resolvers without having to support anycast and without having to configure clients with these other resolvers ahead of time. It uses the mechanism defined by DDR to redirect an encrypted DNS client from one encrypted DNS resolver to another encrypted DNS resolver. Where DDR uses a threat model that presumes the initial DNS traffic is unencrypted, EDSR applies when the initial DNS traffic is already encrypted. One example of what makes redirection to another resolver desirable is geolocation. A DNS service may document one or a few well known resolver configurations even though it routes traffic to hundreds or thousands of resolvers that are closer to the client, reducing latency and making DNS resolutions more applicable to the client.

DNS client behavior

Discovering redirections When a DNS client first opens a connection to an encrypted DNS server, it MUST send a SVCB query for _dns.resolver.arpa to discover its encrypted DNS configuration. If the configuration returned differs from the current connection, the DNS client SHOULD close the connection in favor of a connection to the one returned in the SVCB query. The client does not need to wait for the results of the redirection discovery query before sending other DNS queries on the connection, though they SHOULD gracefully close the connection as soon as it has successfully established a connection to the server it was redirected to and received or timed out the outstanding queries on the original connection. See the considerations section for reasons a client MAY choose to decline a redirection.

Prioritizing redirections When clients receive more than one valid SVCB response, they SHOULD prefer using the redirections in ascending order of the SVCB priority.

Network changes When a client device changes what network it is connected to, it SHOULD forget pre-existing redirections and start EDSR over with the originally configured resolvers. This ensures that a resolver which redirects clients based on their source network can behave accordingly. Note that this is unrelated to what resolvers a client is originally configured with. For example, a client which is configured to always used the resolvers advertised by DHCP will likely start with different original resolvers when changing networks. How a client is configured with DNS resolvers is out of scope for this document. EDSR only provides a mechanism for clients to discover redirections from resolvers they were previously configured to use.

DNS server behavior DNS resolvers who want to redirect clients to other resolvers MUST respond to SVCB queries for _dns.resolver.arpa. with records that describe the configuration of the destination server. Servers SHOULD be prepared for clients to not follow the redirection immediately as connection failures or other issues may lead to clients being unable to follow the redirection. Servers who are redirecting due to being overloaded MAY respond as they normally would to overwhelming traffic. Guidance in SHOULD be followed by resolvers when responding to these special queries for "resolver.arpa" to prevent unnecessary additional requests by the client. See for more info. DNS resolvers who want to redirect clients to other resolvers MUST treat resolver.arpa as a locally served zone per . In practice, this means that resolvers SHOULD respond to queries of any type other than SVCB for _dns.resolver.arpa with NODATA and queries of any type for any domain name under resolver.arpa with NODATA. Redirections MUST only redirect to resolvers which support at least the same protocol, address family, and port as the referring resolver. This ensures that redirections do not lead clients to resolvers that are not compatible with the client.

Conventions and Definitions 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.

Deployment Considerations

Chained redirections It is possible for DNS servers to redirect clients to DNS servers which also redirect clients. Clients which are presented with long chains of redirections MAY choose to stop following redirections to reduce connection thrashing. DNS server operators SHOULD deploy redirection behavior mindfully to avoid long chains of redirection.

Security Considerations

Trusting the redirected connection EDSR does not provide novel authentication or security mechanisms. Redirection is trusted by virtue of the server authentication via PKI through TLS . EDSR MUST NOT be used with encrypted DNS protocols that are not based on TLS. This scenario will require future standards work. EDSR should not introduce any additional security considerations beyond use of the original encrypted resolver prior to redirection. Because the original connection was trusted, information sent over it about a new connection to use should be as trusted. This is analogous to the use of 3xx codes in HTTP to redirect HTTP clients to other servers. However, clients that wish to time bound vulnerabilities to attackers who compromise the original resolver MAY choose to implement a maximum TTL to honor on SVCB records that redirect to other servers.

Use with unencrypted DNS EDSR MUST NOT be used to redirect unencrypted DNS traffic to any other resolver. This use case is called designation and is covered by Discovery of Designated Resolvers (DDR) as defined in . Not following DDR opens up a DNS client to malicious redirection to an attacker-controlled DNS server. For more information, see . EDSR also MUST NOT be used to redirect encrypted DNS traffic to a resolver that advertises support for unencrypted DNS. This would reduce the security posture of the client. Clients MUST NOT follow an encrypted DNS redirection and then send unencrypted DNS traffic to the new resolver.

Privacy Considerations A client MAY choose to not send other name queries until redirection is complete, but there should be no issue with sending queries to intermediate resolvers before redirection takes place. This is because the intermediate resolvers are considered to be appropriate destinations by the client even if the resolver wants to substitute another resolver for reasons other than name resolution results such as latency optimization or load balancing.

Data Flow Considerations

Data Scope EDSR does not result in any additional data being shared by the end user, as the DNS queries going to the new resolver were already going to go to the original resolver.

Data Visibility EDSR results in a 1:1 replacement of DNS resolvers used (future queries sent to the new resolver will not be sent to the original resolver anymore). This means the number of servers which see any given query remain the same. This is only true if clients only use one redirected DNS server per original DNS server. If the DNS server offers more than one redirection, and the client validates and uses two or more of those redirections, then there will be greater data visibility (more destinations). This is however entirely within the client's choice following their own policy as a redundancy versus volume of exhausted data trade-off. EDSR requires the redirection to another server to also use encrypted DNS, so no third-party will be introduced to the data flow unless the encryption is broken.

Data centralization EDSR can only increase data centralization if multiple resolver operators choose to redirect DNS clients to the same, other DNS resolver. To prevent the reduction of their resolution redundancy, DNS clients MAY choose to ignore redirections if they find that they point to resolvers they are already configured to use, by a previous redirection or some other configuration.

IANA Considerations This document has no IANA actions.

References Normative References Apple Inc. Apple Inc. Cloudflare Fastly Microsoft This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An encrypted DNS resolver discovered in this manner is referred to as a "Designated Resolver". This mechanism can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. This mechanism is designed to be limited to cases where unencrypted DNS resolvers and their designated resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an encrypted DNS resolver is known. Google LLC The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols. Google Akamai Technologies Akamai Technologies This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones that all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well-known zones with similar characteristics. This memo documents an Internet Best Current Practice. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]

Acknowledgments TODO acknowledge.