Handling Encrypted DNS Server Redirection
draft-jt-add-dns-server-redirection-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | John Todd , Tommy Jensen | ||
| Last updated | 2022-11-07 | ||
| Replaced by | draft-ietf-add-encrypted-dns-server-redirection | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jt-add-dns-server-redirection-00
ADD J. Todd
Internet-Draft Quad9
Intended status: Standards Track T. Jensen
Expires: 12 May 2023 Microsoft
8 November 2022
Handling Encrypted DNS Server Redirection
draft-jt-add-dns-server-redirection-00
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 & Jensen Expires 12 May 2023 [Page 1]
Internet-Draft EDSR November 2022
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 12 May 2023.
Copyright Notice
Copyright (c) 2022 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. DNS client behavior . . . . . . . . . . . . . . . . . . . . . 3
2.1. Discovering redirections . . . . . . . . . . . . . . . . 3
2.2. Prioritizing redirections . . . . . . . . . . . . . . . . 3
2.3. Network changes . . . . . . . . . . . . . . . . . . . . . 4
3. DNS server behavior . . . . . . . . . . . . . . . . . . . . . 4
4. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
5.1. Chained redirections . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6.1. Trusting the redirected connection . . . . . . . . . . . 5
6.2. Use with unencrypted DNS . . . . . . . . . . . . . . . . 5
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
8. Data Flow Considerations . . . . . . . . . . . . . . . . . . 6
8.1. Data Scope . . . . . . . . . . . . . . . . . . . . . . . 6
8.2. Data Visibility . . . . . . . . . . . . . . . . . . . . . 6
8.3. Data centralization . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Todd & Jensen Expires 12 May 2023 [Page 2]
Internet-Draft EDSR November 2022
1. 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.
2. DNS client behavior
2.1. 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.
2.2. Prioritizing redirections
When clients receive more than one valid SVCB response, they SHOULD
prefer using the redirections in ascending order of the SVCB
priority.
Todd & Jensen Expires 12 May 2023 [Page 3]
Internet-Draft EDSR November 2022
2.3. 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.
3. 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
_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 Section 3 of [I-D.ietf-add-ddr] SHOULD be followed by
resolvers when responding to these special queries for
"resolver.arpa" to prevent unnecessary additional requests by the
client. See Section 5 of [I-D.ietf-dnsop-svcb-https] for more info.
DNS resolvers who want to redirect clients to other resolvers MUST
treat resolver.arpa as a locally served zone per [RFC6303]. 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.
Todd & Jensen Expires 12 May 2023 [Page 4]
Internet-Draft EDSR November 2022
4. 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.
5. Deployment Considerations
5.1. 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.
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]. 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.
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
[I-D.ietf-add-ddr]. Not following DDR opens up a DNS client to
malicious redirection to an attacker-controlled DNS server. For more
information, see Section 7 of [I-D.ietf-add-ddr].
Todd & Jensen Expires 12 May 2023 [Page 5]
Internet-Draft EDSR November 2022
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.
7. 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.
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.
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.
Todd & Jensen Expires 12 May 2023 [Page 6]
Internet-Draft EDSR November 2022
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 document has no IANA actions.
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://www.ietf.org/archive/id/draft-ietf-add-ddr-
10.txt>.
[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-07, 11 August 2022,
<https://www.ietf.org/archive/id/draft-ietf-add-svcb-dns-
07.txt>.
[I-D.ietf-dnsop-svcb-https]
Schwartz, B. M., Bishop, M., and E. Nygren, "Service
binding and parameter specification via the DNS (DNS SVCB
and HTTPS RRs)", Work in Progress, Internet-Draft, draft-
ietf-dnsop-svcb-https-11, 11 October 2022,
<https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-
https-11.txt>.
[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/info/rfc2119>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, DOI 10.17487/RFC6303, July 2011,
<https://www.rfc-editor.org/info/rfc6303>.
Todd & Jensen Expires 12 May 2023 [Page 7]
Internet-Draft EDSR November 2022
[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/info/rfc8174>.
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/info/rfc5280>.
Acknowledgments
TODO acknowledge.
Authors' Addresses
J. Todd
Quad9
Email: jtodd@quad9.net
T. Jensen
Microsoft
Email: tojens@microsoft.com
Todd & Jensen Expires 12 May 2023 [Page 8]