Internet DRAFT - draft-jt-add-dns-server-redirection
draft-jt-add-dns-server-redirection
ADD J. Todd
Internet-Draft Quad9
Intended status: Standards Track T. Jensen
Expires: 5 September 2024 Microsoft
C. Mosher
Innate, Inc.
4 March 2024
Handling Encrypted DNS Server Redirection
draft-jt-add-dns-server-redirection-03
Abstract
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
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://example.com/LATEST. Status information for this document may
be found at https://datatracker.ietf.org/doc/draft-jt-add-dns-server-
redirection/.
Discussion of this document takes place on the WG Working Group
mailing list (mailto:add@ietf.org), which is archived at
https://example.com/WG. Subscribe at
https://www.ietf.org/mailman/listinfo/add/.
Source for this draft and an issue tracker can be found at
https://github.com/johnhtodd/draft-DOH-redirect.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Todd, et al. Expires 5 September 2024 [Page 1]
Internet-Draft EDSR March 2024
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DNS client behavior . . . . . . . . . . . . . . . . . . . . . 3
3.1. Discovering redirections . . . . . . . . . . . . . . . . 4
3.1.1. Strict Origin Redirection . . . . . . . . . . . . . . 4
3.1.2. Redirection away from DDR-discovered servers . . . . 4
3.2. Identifying self-redirections . . . . . . . . . . . . . . 5
3.3. Waiting for redirections . . . . . . . . . . . . . . . . 5
3.4. Refreshing redirections . . . . . . . . . . . . . . . . . 5
3.5. Multiple redirections . . . . . . . . . . . . . . . . . . 5
3.6. Network changes . . . . . . . . . . . . . . . . . . . . . 6
4. DNS server behavior . . . . . . . . . . . . . . . . . . . . . 6
4.1. Ensuring compatibility . . . . . . . . . . . . . . . . . 6
4.2. Dealing with persistent clients . . . . . . . . . . . . . 7
4.3. Redirection to servers controlled by third parties . . . 7
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
5.1. Large trees of redirections . . . . . . . . . . . . . . . 7
5.2. Redirection TTLs . . . . . . . . . . . . . . . . . . . . 7
5.3. Including IP addresses in EDSR responses . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Trusting the redirected connection . . . . . . . . . . . 8
6.2. Use with unencrypted DNS . . . . . . . . . . . . . . . . 8
6.3. Use with DDR-discovered resolvers . . . . . . . . . . . . 9
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
8. Data Flow Considerations . . . . . . . . . . . . . . . . . . 9
Todd, et al. Expires 5 September 2024 [Page 2]
Internet-Draft EDSR March 2024
8.1. Data Scope . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. Data Visibility . . . . . . . . . . . . . . . . . . . . . 10
8.3. Data centralization . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. 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
[I-D.ietf-add-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.
This document describes only one mode of redirection - Strict Origin
Redirection. Previous versions of this draft defined an additional
mode of redirection that allowed servers to redirect to servers that
presented a different domain name than the original server. While
the scenario's validity has some interest, there is no consensus in
the WG for how it can be addressed.
3. DNS client behavior
Todd, et al. Expires 5 September 2024 [Page 3]
Internet-Draft EDSR March 2024
3.1. Discovering redirections
When a DNS client first opens a connection to an encrypted DNS
server, it MUST send a SVCB query for the name of the resolver to
discover its encrypted DNS configuration. The DNS client SHOULD open
a connection to the server returned in the SVCB query using the
TargetName and one of the IP addresses returned in additional A/AAAA
records for the same name. Once a connection has been successfully
opened, as subsequently described by reaching a suitable server at
the end of the redirection chain, the client SHOULD close the first
connection. There are two methods defined to determine whether the
redirection was suitable.
3.1.1. Strict Origin Redirection
The default method of redirection EDSR-compliant clients and servers
MUST support is Strict Origin Redirection. Using this method, if the
returned SVCB record indicates a server with a different domain name
than the current encrypted DNS connection, the redirection MUST NOT
be followed by the client. Clients MAY choose to treat this as an
upstream attack.
The destination server MAY use delegated credentials [RFC9345]. This
is valid so long as the delegated credential is valid for the same
domain name used by the referring server. This is an encouraged
practice for servers which need to redirect clients to servers owned
by other entities, as is the case with CDN contracts.
3.1.2. Redirection away from DDR-discovered servers
Strict Origin Redirection assumes that the original server is
identified by domain name from the client's perspective. Examples
include when the client was configured with the resolver through
endpoint management or DNR discovery [RFC9463]. However, when server
was discovered using DDR [RFC9462], this is not the case. Due to the
threat model DDR operates under, where it has to start from an
unencrypted resolver, the identity of the server used for
verification is its IP address. The risks involved with using the
domain name of a DDR-discovered resolver are further explored in the
Security Considerations section Section 6.
When clients use Strict Origin redirection discovery with a DDR
discovered resolver, the only difference is that the destination
server it was redirected to MUST be able to claim the IP address of
the previous server in its SAN field. This is the equivalent of not
changing origins in the DDR threat model.
Todd, et al. Expires 5 September 2024 [Page 4]
Internet-Draft EDSR March 2024
3.2. Identifying self-redirections
If the set of IP addresses that are valid for the server being
redirected to include the IP address of the current server, the
client SHOULD ignore the redirection, treating it the same as
receiving no response or a NODATA response from the SVCB query.
However, clients receiving preferable encryption parameters as part
of the SVCB response MAY choose to reconnect to negotiate to upgrade
to the preferred encryption method. When doing so, there is no need
for the client to repeat EDSR as the redirection from the server to
itself has terminated the redirection chain.
3.3. Waiting for redirections
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.
3.4. Refreshing redirections
EDSR allows a client to be redirected from an encrypted DNS resolver
it was somehow configured to use. When the redirection TTL expires,
the client SHOULD return to using its originally configured server
unless it can refresh the redirection beforehand. This allows the
client to honor the intention of whatever configuration method was
used to instruct it to use the original encrypted DNS resolver.
If a chain of redirections was followed, the effective TTL of the
redirection is the minimum of the TTLs encountered along the chain.
Clients SHOULD however cap this value to some minimum value at their
discretion to avoid frequent redirection checking when latency plus
an incidentally low TTL along the chain results in near-zero
effective TTLs.
3.5. Multiple redirections
When clients receive more than one valid SVCB response, they SHOULD
prefer using the redirections that match their configuration (such as
supported IP address family or desired encrypted DNS protocol) in
ascending order of the SVCB priority. Once a successful connection
is made to a redirected destination, clients MAY choose to discard
other results in favor of restarting EDSR with the originally
Todd, et al. Expires 5 September 2024 [Page 5]
Internet-Draft EDSR March 2024
configured resolver.
Redirections are considered to be a one-to-one relationship (starting
with one recursive resolver and following its redirections should
result in one replacement recursive resolver). It is not expected
that a stub resolver ends up using more recursive resolvers than it
was originally configured with when using EDSR.
3.6. 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.
4. DNS server behavior
DNS resolvers who want to redirect clients to other resolvers MUST
respond to SVCB [I-D.ietf-add-svcb-dns] queries for their own domain
names with records that describe the configuration of the destination
server.
Guidance in Section 5 of [I-D.ietf-dnsop-svcb-https] to improve
performance by including additional A/AAAA records with the SVCB
response SHOULD be followed.
4.1. Ensuring compatibility
Redirections MUST only redirect to resolvers which support at least
the same protocol, address family, port, and TLS minimum versions as
the referring resolver. This ensures that redirections do not lead
clients to resolvers that are not compatible with the client. In
addition, servers SHOULD avoid redirecting to servers which will also
redirect clients unless they are actively coordinating to ensure a
positive client experience. See the Deployment Considerations
section for more details.
Todd, et al. Expires 5 September 2024 [Page 6]
Internet-Draft EDSR March 2024
4.2. Dealing with persistent clients
Servers SHOULD be prepared for clients to not follow the redirection
immediately as connection failures, other technical issues, or even
client policy affecting server choice may lead to clients being
unable to follow the redirection promptly or at all. Servers who are
redirecting due to being overloaded MAY respond as they normally
would to overwhelming traffic.
4.3. Redirection to servers controlled by third parties
Server operators ought to consider using delegated credentials
[RFC9345] when they wish to redirect general clients to other servers
operated by other entities. This allows the server operator to avoid
giving access to their domain's private key to third parties but also
ensure general clients have a secured, same-origin redirection
experience.
5. Deployment Considerations
5.1. Large trees of 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.
Servers SHOULD ensure their redirections do not create loops, where
clients are redirected to a server it already encountered earlier in
the process. Clients MAY stop following redirections when they
detect this, but MAY also take a simpler approach, following only a
maximum number of redirections.
5.2. Redirection TTLs
Servers SHOULD provide sufficiently long TTLs for clients to avoid
the need to constantly repeat EDSR queries. Server operators should
be mindful of redirection chains because unless they collaboratively
control the TTLs of one another's redirections, redirection chains
will end up with greatly reduced effective TTLs because the client
will always use the lowest.
Todd, et al. Expires 5 September 2024 [Page 7]
Internet-Draft EDSR March 2024
5.3. Including IP addresses in EDSR responses
If a recursive resolver does not include additional A/AAAA records
per Section 5 of [RFC9460], stub resolvers might end up failing the
redirection if the redirection destination name cannot be resolved.
Additionally, the recursive resolver SHOULD ensure records
conntaining the same IP version as the existing connection are
returned (if the stub is currently connected over IPv4, one or more A
records SHOULD be included, and if the stub is currently connected
over IPv6, one or more AAAA records SHOULD be included).
6. Security Considerations
6.1. 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 [RFC5280]. The DNS stub resolver implementing EDSR
SHOULD use whatever policies it uses for other TLS connections for
encrypted DNS traffic to determine if a given TLS cert chain is
trustworthy before proceeding with EDSR.
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. 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.
6.2. 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 [RFC9462].
Not following DDR opens up a DNS client to malicious redirection to
an attacker-controlled DNS server. For more information, see
Section 7 of [RFC9462].
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.
Todd, et al. Expires 5 September 2024 [Page 8]
Internet-Draft EDSR March 2024
6.3. Use with DDR-discovered resolvers
When a resolver is discovered using DDR [RFC9462], the server's
identity used for TLS purposes is its IP address, not its domain
name. This means servers and clients MUST use the original server's
IP address, not the IP address of the previous server in the event of
redirection chains, in the SAN field of destination servers to
validate the redirection.
The reason for this is due to an attack where the DDR SVCB query
response is modified by an active attacker to have a different domain
name in its "dohpath" SVCB key. When the client uses it to issue the
EDSR query to the (valid) DDR-designated resolver, it will innocently
forward the query upstream and return the result. The result may
even be DNSSEC signed since it was issued by the valid owner of the
attacker's domain name. If this redirection is then followed and
validated with the attacker's domain name, it will succeed and the
client will have been maliciously redirected to use an attacker's
server at the low cost of a port 53 attack without breaking
encryption or compromising the encrypted DNS server DDR designated.
There is no harm in using the name of the server for the EDSR query
so long as the validation of the destination server is performed
using the original IP address and not the name. This ensures EDSR
clients can consistently use the domain name of a server for
redirection discovery. Use of the DDR-defined SUDN "resolver.arpa"
was considered and rejected because this would conflate DDR
configuration and EDSR configuration by placing them in the same
zone, using the same DNS record type.
7. Privacy Considerations
A client MAY choose to not send other name queries until redirection
is complete, but there should be no privacy 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.
8. Data Flow Considerations
8.1. 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.
Todd, et al. Expires 5 September 2024 [Page 9]
Internet-Draft EDSR March 2024
8.2. 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.
8.3. 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.
9. IANA Considerations
This draft has no IANA considerations.
10. References
10.1. Normative References
[I-D.ietf-add-ddr]
Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
Jensen, "Discovery of Designated Resolvers", Work in
Progress, Internet-Draft, draft-ietf-add-ddr-10, 5 August
2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
add-ddr-10>.
Todd, et al. Expires 5 September 2024 [Page 10]
Internet-Draft EDSR March 2024
[I-D.ietf-add-svcb-dns]
Schwartz, B. M., "Service Binding Mapping for DNS
Servers", Work in Progress, Internet-Draft, draft-ietf-
add-svcb-dns-09, 26 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-add-
svcb-dns-09>.
[I-D.ietf-dnsop-svcb-https]
Schwartz, B. M., Bishop, M., and E. Nygren, "Service
Binding and Parameter Specification via the DNS (SVCB and
HTTPS Resource Records)", Work in Progress, Internet-
Draft, draft-ietf-dnsop-svcb-https-12, 11 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
svcb-https-12>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.
[RFC9462] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
Jensen, "Discovery of Designated Resolvers", RFC 9462,
DOI 10.17487/RFC9462, November 2023,
<https://www.rfc-editor.org/rfc/rfc9462>.
10.2. Informative References
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC9345] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS and DTLS", RFC 9345,
DOI 10.17487/RFC9345, July 2023,
<https://www.rfc-editor.org/rfc/rfc9345>.
Todd, et al. Expires 5 September 2024 [Page 11]
Internet-Draft EDSR March 2024
[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
and T. Jensen, "DHCP and Router Advertisement Options for
the Discovery of Network-designated Resolvers (DNR)",
RFC 9463, DOI 10.17487/RFC9463, November 2023,
<https://www.rfc-editor.org/rfc/rfc9463>.
Appendix A. Acknowledgments
The authors would like to thank the following individuals for their
invaluable feedback to this document: Ben Schwartz, Eric Orth, Erik
Nygren, Ralph Weber, Ted Hardie, Tommy Pauly, Viktor Dukhovni, and
Vittorio Bertola.
Authors' Addresses
J. Todd
Quad9
Email: jtodd@quad9.net
T. Jensen
Microsoft
Email: tojens@microsoft.com
C. Mosher
Innate, Inc.
Email: cmosher@gmail.com
Todd, et al. Expires 5 September 2024 [Page 12]
