rfc9463.original   rfc9463.txt 
ADD M. Boucadair, Ed. Internet Engineering Task Force (IETF) M. Boucadair, Ed.
Internet-Draft Orange Request for Comments: 9463 Orange
Intended status: Standards Track T. Reddy, Ed. Category: Standards Track T. Reddy.K, Ed.
Expires: 29 October 2023 Nokia ISSN: 2070-1721 Nokia
D. Wing D. Wing
Citrix Cloud Software Group
N. Cook N. Cook
Open-Xchange Open-Xchange
T. Jensen T. Jensen
Microsoft Microsoft
27 April 2023 November 2023
DHCP and Router Advertisement Options for the Discovery of Network- DHCP and Router Advertisement Options for the Discovery of Network-
designated Resolvers (DNR) designated Resolvers (DNR)
draft-ietf-add-dnr-16
Abstract Abstract
The document specifies new DHCP and IPv6 Router Advertisement options This document specifies new DHCP and IPv6 Router Advertisement
to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, DNS-over- options to discover encrypted DNS resolvers (e.g., DNS over HTTPS,
TLS, DNS-over-QUIC). Particularly, it allows a host to learn an DNS over TLS, and DNS over QUIC). Particularly, it allows a host to
authentication domain name together with a list of IP addresses and a learn an Authentication Domain Name together with a list of IP
set of service parameters to reach such encrypted DNS resolvers. addresses and a set of service parameters to reach such encrypted DNS
resolvers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 29 October 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9463.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview
3.1. Configuration Data for Encrypted DNS . . . . . . . . . . 4 3.1. Configuration Data for Encrypted DNS
3.1.1. ADN as the Reference Identifier for DNS 3.1.1. ADN as Reference Identifier for DNS Authentication
Authentication . . . . . . . . . . . . . . . . . . . 4 3.1.2. Avoiding Dependency on External Resolvers
3.1.2. Avoiding Dependency on External Resolvers . . . . . . 5 3.1.3. Single vs. Multiple IP Addresses
3.1.3. Single vs. Multiple IP Addresses . . . . . . . . . . 5 3.1.4. Why Not Separate Options for the ADN and IP Addresses?
3.1.4. Why Not Separate Options for ADN and IP Addresses? . 5 3.1.5. Service Parameters
3.1.5. Service Parameters . . . . . . . . . . . . . . . . . 6 3.1.6. ADN-Only Mode
3.1.6. ADN Only Mode . . . . . . . . . . . . . . . . . . . . 6 3.1.7. Ordering of Encrypted DNS Options
3.1.7. Encrypted DNS Options Ordering . . . . . . . . . . . 7 3.1.8. DNR Validation Checks
3.1.8. DNR Validation Checks . . . . . . . . . . . . . . . . 7 3.1.9. DNR Information Using Other Provisioning Mechanisms
3.1.9. DNR Information Using Other Provisioning 3.2. Handling Configuration Data Conflicts
Mechanisms . . . . . . . . . . . . . . . . . . . . . 7 3.3. Validating Discovered Resolvers
3.2. Handling Configuration Data Conflicts . . . . . . . . . . 8 3.4. Multihoming Considerations
3.3. Validating Discovered Resolvers . . . . . . . . . . . . . 8 4. DHCPv6 Encrypted DNS Option
3.4. Multihoming Considerations . . . . . . . . . . . . . . . 9 4.1. Option Format
4. DHCPv6 Encrypted DNS Option . . . . . . . . . . . . . . . . . 9 4.2. DHCPv6 Client Behavior
4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 9 5. DHCPv4 Encrypted DNS Option
4.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 12 5.1. Option Format
5. DHCPv4 Encrypted DNS Option . . . . . . . . . . . . . . . . . 12 5.2. DHCPv4 Client Behavior
5.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 12 6. IPv6 RA Encrypted DNS Option
5.2. DHCPv4 Client Behavior . . . . . . . . . . . . . . . . . 14 6.1. Option Format
6. IPv6 RA Encrypted DNS Option . . . . . . . . . . . . . . . . 15 6.2. IPv6 Host Behavior
6.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations
6.2. IPv6 Host Behavior . . . . . . . . . . . . . . . . . . . 17 7.1. Spoofing Attacks
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7.2. Deletion Attacks
7.1. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . 18 7.3. Passive Attacks
7.2. Deletion Attacks . . . . . . . . . . . . . . . . . . . . 18 7.4. Wireless Security - Authentication Attacks
7.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 19 8. Privacy Considerations
7.4. Wireless Security - Authentication Attacks . . . . . . . 19 9. IANA Considerations
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 9.1. DHCPv6 Option
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9.2. DHCPv4 Option
9.1. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 20 9.3. Neighbor Discovery Option
9.2. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . . 20 10. References
9.3. Neighbor Discovery Option . . . . . . . . . . . . . . . . 20 10.1. Normative References
10.2. Informative References
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 Acknowledgments
11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 21 Contributors
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses
12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
This document focuses on the discovery of encrypted DNS such as DNS- This document focuses on the discovery of encrypted DNS resolvers
over-HTTPS (DoH) [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS- that are using protocols such as DNS over HTTPS (DoH) [RFC8484], DNS
over-QUIC (DoQ) [RFC9250] in local networks. over TLS (DoT) [RFC7858], or DNS over QUIC (DoQ) [RFC9250] in local
networks.
In particular, the document specifies how a local encrypted DNS In particular, this document specifies how a local encrypted DNS
resolver can be discovered by connected hosts by means of DHCPv4 resolver can be discovered by connected hosts by means of DHCPv4
[RFC2132], DHCPv6 [RFC8415], and IPv6 Router Advertisement (RA) [RFC2132], DHCPv6 [RFC8415], and IPv6 Router Advertisement (RA)
[RFC4861] options. These options are designed to convey the options [RFC4861]. These options are designed to convey the
following information: the DNS Authentication Domain Name (ADN), a following information: the DNS Authentication Domain Name (ADN), a
list of IP addresses, and a set of service parameters. This list of IP addresses, and a set of service parameters. This
procedure is called Discovery of Network-designated Resolvers (DNR). procedure is called Discovery of Network-designated Resolvers (DNR).
The options defined in this document can be deployed in a variety of The options defined in this document can be deployed in a variety of
deployments (e.g., local networks with Customer Premises Equipment deployments (e.g., local networks with Customer Premises Equipment
(CPEs) that may or may not be managed by an Internet Service Provider (CPEs) that may or may not be managed by an Internet Service Provider
(ISP), or local networks with or without DNS forwarders). It is out (ISP), or local networks with or without DNS forwarders). Providing
of the scope of this document to provide an inventory of such an inventory of such deployments is beyond the scope of this
deployments. document.
Resolver selection considerations are out of scope. Likewise, Resolver selection considerations are out of scope. Likewise,
policies (including any interactions with users) are out of scope. policies (including any interactions with users) are out of scope.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document makes use of the terms defined in [RFC8499]. The This document makes use of the terms defined in [RFC8499]. The
following additional terms are used: following additional terms are used:
Authentication Domain Name (ADN): refers to a domain name that is Authentication Domain Name (ADN): Refers to a domain name that is
used by a DNS client to authenticate a DNS resolver. used by a DNS client to authenticate a DNS resolver.
ADN-only mode: refers to a DNS discovery mode where only the ADN of ADN-only mode: Refers to a DNS discovery mode where only the ADN of
the DNS resolver is retrieved. See Section 3.1.6. the DNS resolver is retrieved. See Section 3.1.6.
Do53: refers to unencrypted DNS. Do53: Refers to unencrypted DNS.
DNR: refers to the Discovery of Network-designated Resolvers DNR: Refers to the procedure called Discovery of Network-designated
procedure. Resolvers.
Encrypted DNS: refers to a scheme where DNS exchanges are Encrypted DNS: Refers to a scheme where DNS exchanges are
transported over an encrypted channel. Examples of encrypted DNS transported over an encrypted channel. Examples include DoT, DoH,
are DoT, DoH, or DoQ. and DoQ.
Encrypted DNS resolver: refers to a DNS resolver that supports any Encrypted DNS resolver: Refers to a DNS resolver that supports any
encrypted DNS scheme. encrypted DNS scheme.
Encrypted DNS options: refers to the options defined in Sections 4, Encrypted DNS options: Refers to the options defined in Sections 4,
5, and 6. 5, and 6.
DHCP: refers to both DHCPv4 and DHCPv6. DHCP: Refers to both DHCPv4 and DHCPv6.
3. Overview 3. Overview
This document describes how a DNS client can discover local encrypted This document describes how a DNS client can discover local encrypted
DNS resolvers using DHCP (Sections 4 and 5) and Neighbor Discovery DNS resolvers using DHCP (Sections 4 and 5) and Neighbor Discovery
protocol (Section 6): Encrypted DNS options. protocol (Section 6) Encrypted DNS options.
These options configure an authentication domain name, a list of IP These options configure an ADN, a list of IP addresses, and a set of
addresses, and a set of service parameters of the encrypted DNS service parameters of the encrypted DNS resolver. More information
resolver. More information about the design of these options is about the design of these options is provided in the following
provided in the following subsections. subsections.
3.1. Configuration Data for Encrypted DNS 3.1. Configuration Data for Encrypted DNS
3.1.1. ADN as the Reference Identifier for DNS Authentication 3.1.1. ADN as Reference Identifier for DNS Authentication
In order to allow for a PKIX-based authentication of the encrypted In order to allow for a PKIX-based authentication of the encrypted
DNS resolver to the DNS client, the Encrypted DNS options are DNS resolver to the DNS client, the Encrypted DNS options are
designed to always include an authentication domain name. This ADN designed to always include an ADN. This ADN is presented as a
is presented as a reference identifier for DNS authentication reference identifier for DNS authentication purposes. This design
purposes. This design accommodates the current best practices for accommodates the current best practices for issuing certificates as
issuing certificates as per Section 1.7.2 of [RFC6125]: per Section 1.7.2 of [RFC6125]:
| Some certification authorities issue server certificates based | Some certification authorities issue server certificates based
| on IP addresses, but preliminary evidence indicates that such | on IP addresses, but preliminary evidence indicates that such
| certificates are a very small percentage (less than 1%) of | certificates are a very small percentage (less than 1%) of
| issued certificates. | issued certificates.
3.1.2. Avoiding Dependency on External Resolvers 3.1.2. Avoiding Dependency on External Resolvers
To avoid adding a dependency on another server to resolve the ADN, To avoid adding a dependency on another server to resolve the ADN,
the Encrypted DNS options return the IP address(es) to locate an the Encrypted DNS options return the IP address(es) to locate an
encrypted DNS resolver. These encrypted DNS resolvers may be hosted encrypted DNS resolver. These encrypted DNS resolvers may be hosted
on the same or distinct IP addresses. Such a decision is deployment on the same IP address or distinct IP addresses. Such a decision is
specific. deployment specific.
In order to optimize the size of discovery messages when all DNS In order to optimize the size of discovery messages when all DNS
resolvers terminate on the same IP address, early versions of this resolvers terminate on the same IP address, early draft versions of
document considered relying upon the discovery mechanisms specified this document considered relying upon the discovery mechanisms
in [RFC2132][RFC3646][RFC8106] to retrieve a list of IP addresses to specified in [RFC2132], [RFC3646], and [RFC8106] to retrieve a list
reach their DNS resolvers. Nevertheless, this approach requires a of IP addresses to reach their DNS resolvers. Nevertheless, this
client that supports more than one encrypted DNS protocol (e.g., DoH approach requires a client that supports more than one encrypted DNS
and DoT) to probe that list of IP addresses. To avoid such a protocol (e.g., DoH and DoT) to probe that list of IP addresses. To
probing, the options defined in Sections 4, 5, and 6 associate an avoid such probing, the options defined in Sections 4, 5, and 6
encrypted DNS protocol with an IP address. No probing is required in associate an encrypted DNS protocol with an IP address. No probing
such a design. is required in such a design.
3.1.3. Single vs. Multiple IP Addresses 3.1.3. Single vs. Multiple IP Addresses
A list of IP addresses to reach an encrypted DNS resolver may be A list of IP addresses to reach an encrypted DNS resolver may be
returned in an Encrypted DNS option to accommodate current returned in an Encrypted DNS option to accommodate current
deployments relying upon primary and backup resolvers. Also, DNR can deployments relying upon primary and backup resolvers. Also, DNR can
be used in contexts where other DNS redundancy schemes (e.g., anycast be used in contexts where other DNS redundancy schemes (e.g., anycast
as in BCP 126 [RFC4786]) are used. as discussed in BCP 126 [RFC4786]) are used.
Whether one or more IP addresses are returned in an Encrypted DNS Whether one or more IP addresses are returned in an Encrypted DNS
option is deployment specific. For example, a router embedding a option is deployment specific. For example, a router embedding a
recursive server or a forwarder has to include one single IP address recursive server or a forwarder has to include one single IP address
pointing to one of its LAN-facing interfaces. Typically, this IP pointing to one of its LAN-facing interfaces. Typically, this IP
address can be a private IPv4 address, a link-local address, a Unique address can be a private IPv4 address, a Link-Local address, an IPv6
Local IPv6 unicast Address (ULA), or a Global Unicast Address (GUA). Unique Local Address (ULA), or a Global Unicast Address (GUA).
If multiple IP addresses are to be returned in an Encrypted DNS If multiple IP addresses are to be returned in an Encrypted DNS
option, these addresses are ordered in the preference for use by the option, these addresses are returned, ordered by preference, for use
client. by the client.
3.1.4. Why Not Separate Options for ADN and IP Addresses? 3.1.4. Why Not Separate Options for the ADN and IP Addresses?
A single option is used to convey both the ADN and IP addresses. A single option is used to convey both the ADN and IP addresses.
Otherwise, a means to correlate an IP address conveyed in an option Otherwise, a means to correlate an IP address conveyed in an option
with an ADN conveyed in another option will be required if, for with an ADN conveyed in another option will be required if, for
example, more than one ADN is supported by the network. example, more than one ADN is supported by the network.
3.1.5. Service Parameters 3.1.5. Service Parameters
Because distinct encrypted DNS protocols (e.g., DoT, DoH, and DoQ) Because distinct encrypted DNS protocols (e.g., DoT, DoH, and DoQ)
may be provisioned by a network and that some of these protocols may may be provisioned by a network and some of these protocols may make
make use of customized port numbers instead of default ones, the use of customized port numbers instead of default port numbers, the
Encrypted DNS options are designed to return a set of service Encrypted DNS options are designed to return a set of service
parameters. These parameters are encoded following the same rules parameters. These parameters are encoded following the same rules
for encoding SvcParams in Section 2.1 of [I-D.ietf-dnsop-svcb-https]. for encoding SvcParams using the wire format specified in Section 2.2
This encoding approach may increase the size of the options but it of [RFC9460]. This encoding approach may increase the size of the
has the merit of relying upon an existing IANA registry and, thus, options, but it has the merit of relying upon an existing IANA
accommodating new encrypted DNS protocols and service parameters that registry and, thus, accommodating new encrypted DNS protocols and
may be defined in the future. service parameters that may be defined in the future.
The following service parameters MUST be supported by a DNR The following service parameters MUST be supported by a DNR
implementation: implementation:
alpn: Used to indicate the set of supported protocols (Section 7.1 alpn: Used to indicate the set of supported protocols (Section 7.1
of [I-D.ietf-dnsop-svcb-https]). of [RFC9460]).
port: Used to indicate the target port number for the encrypted DNS port: Used to indicate the target port number for the encrypted DNS
connection (Section 7.2 of [I-D.ietf-dnsop-svcb-https]). connection (Section 7.2 of [RFC9460]).
In addition, the following service parameter is RECOMMENDED to be In addition, the following service parameter is RECOMMENDED to be
supported by a DNR implementation: supported by a DNR implementation:
dohpath: Used to supply a relative DoH URI Template (Section 5.1 of dohpath: Used to supply a relative DoH URI Template (Section 5.1 of
[I-D.ietf-add-svcb-dns]). [RFC9461]).
3.1.6. ADN Only Mode 3.1.6. ADN-Only Mode
The provisioning mode in which an ADN, a list of IP addresses, and a The provisioning mode in which an ADN, a list of IP addresses, and a
set of service parameters of the encrypted DNS resolver are supplied set of service parameters of the encrypted DNS resolver are supplied
to a host SHOULD be used because the Encrypted DNS options are self- to a host SHOULD be used because the Encrypted DNS options are self-
contained and do not require any additional DNS queries. The reader contained and do not require any additional DNS queries. The reader
may refer to [RFC7969] for an overview of advanced capabilities that may refer to [RFC7969] for an overview of advanced capabilities that
are supported by DHCP servers to populate configuration data (e.g., are supported by DHCP servers to populate configuration data (e.g.,
issue DNS queries). issue DNS queries).
In contexts where putting additional complexity on requesting hosts In contexts where putting additional complexity on requesting hosts
is acceptable, returning an ADN only can be considered. The supplied is acceptable, returning an ADN only can be considered. The supplied
ADN will be passed to a local resolution library (a DNS client, ADN will be passed to a local resolution library (a DNS client,
typically) which will then issue Service Binding (SVCB) queries typically), which will then issue Service Binding (SVCB) queries
[I-D.ietf-add-svcb-dns]. These SVCB queries can be sent to the [RFC9461]. These SVCB queries can be sent to the discovered
discovered encrypted DNS resolver itself or to the network-designated encrypted DNS resolver itself or to the network-designated Do53
Do53 resolver. Note that this mode may be subject to active attacks, resolver. Note that this mode may be subject to active attacks,
which can be mitigated by DNSSEC. which can be mitigated by DNSSEC.
| How an ADN is passed to a local resolution library is | How an ADN is passed to a local resolution library is
| implementation specific. | implementation specific.
3.1.7. Encrypted DNS Options Ordering 3.1.7. Ordering of Encrypted DNS Options
The DHCP options defined in Sections 4 and 5 follow the option The DHCP options defined in Sections 4 and 5 follow the option
ordering guidelines in Section 17 of [RFC7227]. ordering guidelines in Section 17 of [RFC7227].
Likewise, the RA option (Section 6) adheres to the recommendations in Likewise, the RA option (Section 6) adheres to the recommendations in
Section 9 of [RFC4861]. Section 9 of [RFC4861].
3.1.8. DNR Validation Checks 3.1.8. DNR Validation Checks
On receipt of an Encrypted DNS option, the DHCP client (or IPv6 host) On receipt of an Encrypted DNS option, the DHCP client (or IPv6 host)
makes the following validation checks: makes the following validation checks:
* The ADN is present and encoded as per Section 10 of [RFC8415]. * The ADN is present and encoded as per Section 10 of [RFC8415].
* If additional data is supplied: * If additional data is supplied:
- the service parameters are encoded following the rules - The service parameters are encoded following the rules
specified in Section 2.1 of [I-D.ietf-dnsop-svcb-https]. specified in Section 2.2 of [RFC9460].
- the option includes at least one valid IP address. - The option includes at least one valid IP address.
- the service parameters do not include "ipv4hint" or "ipv6hint" - The service parameters do not include "ipv4hint" or "ipv6hint"
service parameters. parameters.
If any of the checks fail, the receiver discards the received If any of the checks fail, the receiver discards the received
Encrypted DNS option. Encrypted DNS option.
3.1.9. DNR Information Using Other Provisioning Mechanisms 3.1.9. DNR Information Using Other Provisioning Mechanisms
The provisioning mechanisms specified in this document may not be The provisioning mechanisms specified in this document may not be
available in specific networks (e.g., some cellular networks available in specific networks (e.g., some cellular networks
exclusively use Protocol Configuration Options (PCOs) [TS.24008]) or exclusively use Protocol Configuration Options (PCOs) [TS.24008]) or
may not be suitable in some contexts (e.g., need for a secure may not be suitable in some contexts (e.g., where secure discovery is
discovery). Other mechanisms may be considered in these contexts for needed). Other mechanisms may be considered in these contexts for
the provisioning of encrypted DNS resolvers. It is RECOMMENDED that the provisioning of encrypted DNS resolvers. It is RECOMMENDED that
at least the following DNR information is made available to a at least the following DNR information be made available to a
requesting host: requesting host:
* A service priority whenever the discovery mechanism does not rely * A service priority whenever the discovery mechanism does not rely
on implicit ordering if multiple instances of the encrypted DNS on implicit ordering if multiple instances of the encrypted DNS
are used. are used.
* An authentication domain name. This parameter is mandatory. * An ADN. This parameter is mandatory.
* A list of IP addresses to locate the encrypted DNS resolver. * A list of IP addresses to locate the encrypted DNS resolver.
* A set of service parameters. * A set of service parameters.
3.2. Handling Configuration Data Conflicts 3.2. Handling Configuration Data Conflicts
If the encrypted DNS is discovered by a host using both RA and DHCP, If encrypted DNS resolvers are discovered by a host using both RA and
the rules discussed in Section 5.3.1 of [RFC8106] MUST be followed. DHCP, the rules discussed in Section 5.3.1 of [RFC8106] MUST be
followed.
DHCP/RA options to discover encrypted DNS resolvers (including, DoH DHCP/RA options to discover encrypted DNS resolvers (including DoH
URI Templates) takes precedence over Discovery of Designated URI Templates) takes precedence over Discovery of Designated
Resolvers (DDR) [I-D.ietf-add-ddr] since DDR uses Do53 to an external Resolvers (DDR) [RFC9462], since DDR uses Do53 to an external DNS
DNS resolver, which is susceptible to both internal and external resolver, which is susceptible to both internal and external attacks
attacks whereas DHCP/RA is typically protected using the mechanisms whereas DHCP/RA is typically protected using the mechanisms discussed
discussed in Section 7.1. in Section 7.1.
If a client learns both Do53 and encrypted DNS resolvers from the If a client learns both Do53 and encrypted DNS resolvers from the
same network, and absent explicit configuration otherwise, it is same network, and absent explicit configuration otherwise, it is
RECOMMENDED that the client uses the encrypted DNS resolvers for that RECOMMENDED that the client use the encrypted DNS resolvers for that
network. If the client cannot establish an authenticated and network. If the client cannot establish an authenticated and
encrypted connection with the encrypted DNS resolver, it may fall encrypted connection with the encrypted DNS resolver, it may fall
back to using the Do53 resolver. back to using the Do53 resolver.
3.3. Validating Discovered Resolvers 3.3. Validating Discovered Resolvers
This section describes a set of validation checks to confirm that an This section describes a set of validation checks to confirm that an
encrypted DNS resolver matches what is provided using DNR (e.g., DHCP encrypted DNS resolver matches what is provided using DNR (e.g., DHCP
or RA). Such validation checks do not intend to validate the or RA). Such validation checks do not intend to validate the
security of the DNR provisioning mechanisms or the user's trust security of the DNR provisioning mechanisms or the user's trust
relationship to the network. relationship to the network.
If the local DNS client supports one of the discovered encrypted DNS If the local DNS client supports one of the discovered encrypted DNS
protocols identified by Application Layer Protocol Negotiation (ALPN) protocols identified by Application-Layer Protocol Negotiation (ALPN)
protocol identifiers (or other service parameter that indicates some protocol identifiers (or another service parameter that indicates
other protocol disambiguation mechanism), the DNS client establishes some other protocol disambiguation mechanism), the DNS client
an encrypted DNS session following the service priority of the establishes an encrypted DNS session following the service priority
discovered encrypted resolvers. of the discovered encrypted resolvers.
The DNS client verifies the connection based on PKIX validation The DNS client verifies the connection based on PKIX validation
[RFC5280] of the DNS resolver certificate and uses the validation [RFC5280] of the DNS resolver certificate and uses the validation
techniques as described in [RFC6125] to compare the authentication techniques as described in [RFC6125] to compare the ADN conveyed in
domain name conveyed in the Encrypted DNS options to the certificate the Encrypted DNS options to the certificate provided (see
provided (see Section 8.1 of [RFC8310] for more details). The DNS Section 8.1 of [RFC8310] for more details). The DNS client uses the
client uses the default system or application PKI trust anchors default system or application PKI trust anchors unless configured
unless configured otherwise to use explicit trust anchors. ALPN- otherwise to use explicit trust anchors. ALPN-related considerations
related considerations can be found in Section 6.1 of can be found in Section 7.1 of [RFC9460]. Operational considerations
[I-D.ietf-dnsop-svcb-https]. Operation considerations to check the related to checking the revocation status of the certificate of an
revocation status of the certificate of an encrypted DNS resolver are encrypted DNS resolver are discussed in Section 10 of [RFC8484].
discussed in Section 10 of [RFC8484].
3.4. Multihoming Considerations 3.4. Multihoming Considerations
Devices may be connected to multiple networks; each providing their Devices may be connected to multiple networks, each providing their
own DNS configuration using the discovery mechanisms specified in own DNS configuration using the discovery mechanisms specified in
this document. Nevertheless, it is out of the scope of this this document. Nevertheless, discussing DNS selection of multi-
specification to discuss DNS selection of multi-interface devices. interfaced devices is beyond the scope of this specification. Such
Such considerations fall under the generic issue of handling multiple considerations fall under the generic issue of handling multiple
provisioning sources and which should not be dealt within each option provisioning sources and should not be processed in each option
separately as per the recommendation in Section 12 of [RFC7227]. separately, as per the recommendation in Section 12 of [RFC7227].
The reader may refer to [RFC6731] for a discussion of DNS selection The reader may refer to [RFC6731] for a discussion of DNS selection
issues and an example of DNS resolver selection for multi-interfaced issues and an example of DNS resolver selection for multi-interfaced
devices. Also, the reader may refer to devices. Also, the reader may refer to [Local-DNS-Authority] for a
[I-D.ietf-add-split-horizon-authority] for a discussion on how DNR discussion on how DNR and Provisioning Domain (PvD) key "dnsZones"
and Provisioning Domains (PvDs) Key "dnsZones" (Section 4.3 of (Section 4.3 of [RFC8801]) can be used in "split DNS" environments
[RFC8801]) can be used in Split DNS environments (Section 6 of (Section 6 of [RFC8499]).
[RFC8499]).
4. DHCPv6 Encrypted DNS Option 4. DHCPv6 Encrypted DNS Option
4.1. Option Format 4.1. Option Format
The format of the DHCPv6 Encrypted DNS option is shown in Figure 1. The format of the DHCPv6 Encrypted DNS option is shown in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V6_DNR | Option-length | | OPTION_V6_DNR | Option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Priority | ADN Length | | Service Priority | ADN Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ authentication-domain-name ~ ~ authentication-domain-name ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Length | | | Addr Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
skipping to change at page 10, line 26 skipping to change at line 420
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Service Parameters (SvcParams) ~ ~ Service Parameters (SvcParams) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DHCPv6 Encrypted DNS Option Figure 1: DHCPv6 Encrypted DNS Option
The fields of the option shown in Figure 1 are as follows: The fields of the option shown in Figure 1 are as follows:
Option-code: OPTION_V6_DNR (TBA1, see Section 9.1) Option-code: OPTION_V6_DNR (144; see Section 9.1).
Option-length: Length of the enclosed data in octets. The option Option-length: Length of the enclosed data in octets. The option
length is ('ADN Length' + 4) when only an ADN is included in the length is ('ADN Length' + 4) when only an ADN is included in the
option. option.
Service Priority: The priority of this OPTION_V6_DNR instance Service Priority: The priority of this OPTION_V6_DNR instance
compared to other instances. This 16-bit unsigned integer is compared to other instances. This 16-bit unsigned integer is
interpreted following the rules specified in Section 2.4.1 of interpreted following the rules specified in Section 2.4.1 of
[I-D.ietf-dnsop-svcb-https]. [RFC9460].
ADN Length: Length of the authentication-domain-name field in ADN Length: Length of the authentication-domain-name field in
octets. octets.
authentication-domain-name (variable length): A fully qualified authentication-domain-name (variable length): A Fully Qualified
domain name of the encrypted DNS resolver. This field is Domain Name (FQDN) of the encrypted DNS resolver. This field is
formatted as specified in Section 10 of [RFC8415]. formatted as specified in Section 10 of [RFC8415].
An example of the authentication-domain-name encoding is shown in An example of the authentication-domain-name encoding is shown in
Figure 2. This example conveys the FQDN "doh1.example.com.", and Figure 2. This example conveys the FQDN "doh1.example.com.", and
the resulting Option-length field is 18. the resulting ADN Length field is 18.
+------+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+------+
| 0x04 | d | o | h | 1 | 0x07 | e | x | a | | 0x04 | d | o | h | 1 | 0x07 | e | x | a |
+------+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+------+
| m | p | l | e | 0x03 | c | o | m | 0x00 | | m | p | l | e | 0x03 | c | o | m | 0x00 |
+------+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+------+
Figure 2: An Example of the DNS authentication-domain-name Figure 2: An Example of the DNS authentication-domain-name
Encoding Encoding
Addr Length: Length of enclosed IPv6 addresses in octets. When Addr Length: Length of enclosed IPv6 addresses in octets. When
present, it MUST be a multiple of 16. present, it MUST be a multiple of 16.
ipv6-address(es) (variable length): Indicates one or more IPv6 ipv6-address(es) (variable length): Indicates one or more IPv6
addresses to reach the encrypted DNS resolver. An address can be addresses to reach the encrypted DNS resolver. An address can be
link-local, ULA, or GUA. The format of this field is shown in a Link-Local address, a ULA, or a GUA. The format of this field
Figure 3. is shown in Figure 3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| ipv6-address | | ipv6-address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of the IPv6 Addresses Field Figure 3: Format of the ipv6-address(es) Field
Service Parameters (SvcParams) (variable length): Specifies a set of Service Parameters (SvcParams) (variable length): Specifies a set of
service parameters that are encoded following the rules in service parameters that are encoded following the rules in
Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters Section 2.2 of [RFC9460]. Service parameters may include, for
may include, for example, a list of ALPN protocol identifiers or example, a list of ALPN protocol identifiers or alternate port
alternate port numbers. This field SHOULD include at least "alpn" numbers. This field SHOULD include at least the "alpn" SvcParam.
SvcParam. The "alpn" SvcParam may not be required in contexts The "alpn" SvcParam may not be required in contexts such as a
such as a variant of DNS over CoAP where messages are encrypted variant of DNS over the Constrained Application Protocol (CoAP)
using Object Security for Constrained RESTful Environments where messages are encrypted using Object Security for Constrained
(OSCORE) [RFC8613]. The service parameters MUST NOT include RESTful Environments (OSCORE) [RFC8613]. The service parameters
"ipv4hint" or "ipv6hint" SvcParams as they are superseded by the MUST NOT include "ipv4hint" or "ipv6hint" SvcParams, as they are
included IP addresses. superseded by the included IP addresses.
If no port service parameter is included, this indicates that If no port service parameter is included, this indicates that
default port numbers should be used. As a reminder, the default default port numbers should be used. As a reminder, the default
port number is 853 for DoT, 443 for DoH, and 853 for DoQ. port number is 853 for DoT, 443 for DoH, and 853 for DoQ.
The length of this field is ('Option-length' - 6 - 'ADN Length' - The length of this field is ('Option-length' - 6 - 'ADN Length' -
'Addr Length'). 'Addr Length').
Note that "Addr Length", "ipv6-address(es)", and "Service Parameters Note that the "Addr Length", "ipv6-address(es)", and "Service
(SvcParams)" fields are not present if the ADN-only mode is used Parameters (SvcParams)" fields are not present if the ADN-only mode
(Section 3.1.6). is used (Section 3.1.6).
4.2. DHCPv6 Client Behavior 4.2. DHCPv6 Client Behavior
To discover an encrypted DNS resolver, the DHCPv6 client MUST include To discover an encrypted DNS resolver, the DHCPv6 client MUST include
OPTION_V6_DNR in an Option Request Option (ORO), as in Sections OPTION_V6_DNR in an Option Request Option (ORO), per Sections 18.2.1,
18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of [RFC8415]. 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of [RFC8415].
The DHCPv6 client MUST be prepared to receive multiple instances of The DHCPv6 client MUST be prepared to receive multiple instances of
the OPTION_V6_DNR option; each option is to be treated as a separate the OPTION_V6_DNR option; each option is to be treated as a separate
encrypted DNS resolver. These instances MUST be processed following encrypted DNS resolver. These instances MUST be processed following
their service priority (i.e., smaller service priority indicates a their service priority (i.e., a smaller service priority value
higher preference). indicates a higher preference).
The DHCPv6 client MUST silently discard any OPTION_V6_DNR that fails The DHCPv6 client MUST silently discard any OPTION_V6_DNR that fails
to pass the validation steps defined in Section 3.1.8. to pass the validation steps defined in Section 3.1.8.
The DHCPv6 client MUST silently discard multicast and host loopback The DHCPv6 client MUST silently discard multicast and host loopback
addresses conveyed in OPTION_V6_DNR. addresses conveyed in OPTION_V6_DNR.
5. DHCPv4 Encrypted DNS Option 5. DHCPv4 Encrypted DNS Option
5.1. Option Format 5.1. Option Format
The format of the DHCPv4 Encrypted DNS option is illustrated in The format of the DHCPv4 Encrypted DNS option is illustrated in
Figure 4. Figure 4.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V4_DNR | Length | | OPTION_V4_DNR | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ DNR Instance Data #1 ~ ~ DNR Instance Data #1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
. ... . | . ... . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ optional +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ optional
~ DNR Instance Data #n ~ | ~ DNR Instance Data #n ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 4: DHCPv4 Encrypted DNS Option Figure 4: DHCPv4 Encrypted DNS Option
The fields of the option shown in Figure 4 are as follows: The fields of the option shown in Figure 4 are as follows:
Code: OPTION_V4_DNR (TBA2, see Section 9.2). Code: OPTION_V4_DNR (162; see Section 9.2).
Length: Indicates the length of the enclosed data in octets. Length: Indicates the length of the enclosed data in octets.
DNR Instance Data: Includes the configuration data of an encrypted DNR Instance Data: Includes the configuration data of an encrypted
DNS resolver. The format of this field is shown in Figure 5. DNS resolver. The format of this field is shown in Figure 5.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DNR Instance Data Length | | DNR Instance Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Priority | | Service Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADN Length | | | ADN Length | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
~ authentication-domain-name ~ ~ authentication-domain-name ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 38 skipping to change at line 577
Instance Data" field is repeated. Instance Data" field is repeated.
The fields shown in Figure 5 are as follows: The fields shown in Figure 5 are as follows:
DNR Instance Data Length: Length of all following data in octets. DNR Instance Data Length: Length of all following data in octets.
This field is set to ('ADN Length' + 3) when only an ADN is This field is set to ('ADN Length' + 3) when only an ADN is
provided for a DNR instance. provided for a DNR instance.
Service Priority: The priority of this instance compared to other Service Priority: The priority of this instance compared to other
DNR instances. This 16-bit unsigned integer is interpreted DNR instances. This 16-bit unsigned integer is interpreted
following the rules specified in Section 2.4.1 of following the rules specified in Section 2.4.1 of [RFC9460].
[I-D.ietf-dnsop-svcb-https].
ADN Length: Length of the authentication-domain-name in octets. ADN Length: Length of the authentication-domain-name field in
octets.
authentication-domain-name (variable length): The authentication authentication-domain-name (variable length): The ADN of the
domain name of the encrypted DNS resolver. This field is encrypted DNS resolver. This field is formatted as specified in
formatted as specified in Section 10 of [RFC8415]. An example is Section 10 of [RFC8415]. An example is provided in Figure 2.
provided in Figure 2.
Addr Length: Length of included IPv4 addresses in octets. When Addr Length: Length of included IPv4 addresses in octets. When
present, it MUST be a multiple of 4. present, it MUST be a multiple of 4.
IPv4 Address(es) (variable length): Indicates one or more IPv4 IPv4 Address(es) (variable length): Indicates one or more IPv4
addresses to reach the encrypted DNS resolver. Both private and addresses to reach the encrypted DNS resolver. Both private and
public IPv4 addresses can be included in this field. The format public IPv4 addresses can be included in this field. The format
of this field is shown in Figure 6. This format assumes that an of this field is shown in Figure 6. This format assumes that an
IPv4 address is encoded as a1.a2.a3.a4. IPv4 address is encoded as a1.a2.a3.a4.
0 8 16 24 32 40 48 0 8 16 24 32 40 48
+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+--
| a1 | a2 | a3 | a4 | a1 | a2 | ... | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+--
IPv4 Address 1 IPv4 Address 2 ... IPv4 Address 1 IPv4 Address 2 ...
Figure 6: Format of the IPv4 Addresses Field Figure 6: Format of the IPv4 Address(es) Field
Service Parameters (SvcParams) (variable length): Specifies a set of Service Parameters (SvcParams) (variable length): Specifies a set of
service parameters that are encoded following the rules in service parameters that are encoded following the rules in
Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters Section 2.2 of [RFC9460]. Service parameters may include, for
may include, for example, a list of ALPN protocol identifiers or example, a list of ALPN protocol identifiers or alternate port
alternate port numbers. This field SHOULD include at least "alpn" numbers. This field SHOULD include at least the "alpn" SvcParam.
SvcParam. The "alpn" SvcParam may not be required in contexts The "alpn" SvcParam may not be required in contexts such as a
such as a variant of DNS over CoAP where messages are encrypted variant of DNS over CoAP where messages are encrypted using
using OSCORE. The service parameters MUST NOT include "ipv4hint" OSCORE. The service parameters MUST NOT include "ipv4hint" or
or "ipv6hint" SvcParams as they are superseded by the included IP "ipv6hint" SvcParams, as they are superseded by the included IP
addresses. addresses.
If no port service parameter is included, this indicates that If no port service parameter is included, this indicates that
default port numbers should be used. default port numbers should be used.
The length of this field is ('DNR Instance Data Length' - 4 - 'ADN The length of this field is ('DNR Instance Data Length' - 4 - 'ADN
Length' - 'Addr Length'). Length' - 'Addr Length').
Note that "Addr Length", "IPv4 Address(es)", and "Service Parameters Note that the "Addr Length", "IPv4 Address(es)", and "Service
(SvcParams)" fields are not present if the ADN-only mode is used Parameters (SvcParams)" fields are not present if the ADN-only mode
(Section 3.1.6). is used (Section 3.1.6).
OPTION_V4_DNR is a concatenation-requiring option. As such, the OPTION_V4_DNR is a concatenation-requiring option. As such, the
mechanism specified in [RFC3396] MUST be used if OPTION_V4_DNR mechanism specified in [RFC3396] MUST be used if OPTION_V4_DNR
exceeds the maximum DHCPv4 option size of 255 octets. exceeds the maximum DHCPv4 option size of 255 octets.
5.2. DHCPv4 Client Behavior 5.2. DHCPv4 Client Behavior
To discover an encrypted DNS resolver, the DHCPv4 client requests the To discover an encrypted DNS resolver, the DHCPv4 client requests the
encrypted DNS resolver by including OPTION_V4_DNR in a Parameter encrypted DNS resolver by including OPTION_V4_DNR in a Parameter
Request List option [RFC2132]. Request List option [RFC2132].
The DHCPv4 client MUST be prepared to receive multiple DNR instance The DHCPv4 client MUST be prepared to receive multiple "DNR Instance
data in the OPTION_V4_DNR option; each instance is to be treated as a Data" field entries in the OPTION_V4_DNR option; each instance is to
separate encrypted DNS resolver. These instances MUST be processed be treated as a separate encrypted DNS resolver. These instances
following their service priority (i.e., smaller service priority MUST be processed following their service priority (i.e., a smaller
indicates a higher preference). service priority value indicates a higher preference).
The DHCPv4 client MUST silently discard any OPTION_V4_DNR that fails The DHCPv4 client MUST silently discard any OPTION_V4_DNR that fails
to pass the validation steps defined in Section 3.1.8. to pass the validation steps defined in Section 3.1.8.
The DHCPv4 client MUST silently discard multicast and host loopback The DHCPv4 client MUST silently discard multicast and host loopback
addresses conveyed in OPTION_V4_DNR. addresses conveyed in OPTION_V4_DNR.
6. IPv6 RA Encrypted DNS Option 6. IPv6 RA Encrypted DNS Option
6.1. Option Format 6.1. Option Format
This section defines a new Neighbor Discovery option [RFC4861]: IPv6 This section defines a new Neighbor Discovery option [RFC4861]: the
RA Encrypted DNS option. This option is useful in contexts similar IPv6 RA Encrypted DNS option. This option is useful in contexts
to those discussed in Section 1.1 of [RFC8106]. similar to those discussed in Section 1.1 of [RFC8106].
The format of the IPv6 RA Encrypted DNS option is illustrated in The format of the IPv6 RA Encrypted DNS option is illustrated in
Figure 7. Figure 7.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA3 | Length | Service Priority | | Type | Length | Service Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADN Length | | | ADN Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ authentication-domain-name ~ ~ authentication-domain-name ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Length | | | Addr Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ipv6-address(es) ~ ~ ipv6-address(es) ~
skipping to change at page 16, line 6 skipping to change at line 682
| | SvcParams Length | | | SvcParams Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Service Parameters (SvcParams) ~ ~ Service Parameters (SvcParams) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: RA Encrypted DNS Option Figure 7: RA Encrypted DNS Option
The fields of the option shown in Figure 7 are as follows: The fields of the option shown in Figure 7 are as follows:
Type: 8-bit identifier of the Encrypted DNS option as assigned by Type: 8-bit identifier of the Encrypted DNS option as assigned by
IANA (TBA3, see Section 9.3). IANA (144; see Section 9.3).
Length: 8-bit unsigned integer. The length of the option (including Length: 8-bit unsigned integer. The length of the option (including
the Type and Length fields) is in units of 8 octets. the Type and Length fields) is in units of 8 octets.
Service Priority: 16-bit unsigned integer. The priority of this Service Priority: 16-bit unsigned integer. The priority of this
Encrypted DNS option instance compared to other instances. This Encrypted DNS option instance compared to other instances. This
field is interpreted following the rules specified in field is interpreted following the rules specified in
Section 2.4.1 of [I-D.ietf-dnsop-svcb-https]. Section 2.4.1 of [RFC9460].
Lifetime: 32-bit unsigned integer. The maximum time in seconds Lifetime: 32-bit unsigned integer. This represents the maximum time
(relative to the time the packet is received) over which the in seconds (relative to the time the packet is received) over
discovered Authentication Domain Name is valid. which the discovered ADN is valid.
The value of Lifetime SHOULD by default be at least 3 * The value of Lifetime SHOULD by default be at least 3 *
MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA
interval as defined in [RFC4861]. interval as defined in [RFC4861].
A value of all one bits (0xffffffff) represents infinity. A value of all one bits (0xffffffff) represents infinity.
A value of zero means that this Authentication Domain Name MUST no A value of zero means that this ADN MUST no longer be used.
longer be used.
ADN Length: 16-bit unsigned integer. This field indicates the ADN Length: 16-bit unsigned integer. This field indicates the
length of the authentication-domain-name field in octets. length of the authentication-domain-name field in octets.
authentication-domain-name (variable length): The authentication authentication-domain-name (variable length): The ADN of the
domain name of the encrypted DNS resolver. This field is encrypted DNS resolver. This field is formatted as specified in
formatted as specified in Section 10 of [RFC8415]. Section 10 of [RFC8415].
Addr Length: 16-bit unsigned integer. This field indicates the Addr Length: 16-bit unsigned integer. This field indicates the
length of enclosed IPv6 addresses in octets. When present, it length of enclosed IPv6 addresses in octets. When present, it
MUST be a multiple of 16. MUST be a multiple of 16.
ipv6-address(es) (variable length): One or more IPv6 addresses of ipv6-address(es) (variable length): One or more IPv6 addresses of
the encrypted DNS resolver. An address can be link-local, ULA, or the encrypted DNS resolver. An address can be a Link-Local
GUA. address, a ULA, or a GUA.
All of the addresses share the same Lifetime value. Similar to All of the addresses share the same Lifetime value. As also
[RFC8106], if it is desirable to have different Lifetime values discussed in [RFC8106], if it is desirable to have different
per IP address, multiple Encrypted DNS options may be used. Lifetime values per IP address, multiple Encrypted DNS options may
be used.
The format of this field is shown in Figure 3. The format of this field is shown in Figure 3.
SvcParams Length: 16-bit unsigned integer. This field indicates the SvcParams Length: 16-bit unsigned integer. This field indicates the
length of the Service Parameters field in octets. length of the "Service Parameters (SvcParams)" field in octets.
Service Parameters (SvcParams) (variable length): Specifies a set of Service Parameters (SvcParams) (variable length): Specifies a set of
service parameters that are encoded following the rules in service parameters that are encoded following the rules in
Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters Section 2.2 of [RFC9460]. Service parameters may include, for
may include, for example, a list of ALPN protocol identifiers or example, a list of ALPN protocol identifiers or alternate port
alternate port numbers. This field SHOULD include at least "alpn" numbers. This field SHOULD include at least the "alpn" SvcParam.
SvcParam. The "alpn" SvcParam may not be required in contexts The "alpn" SvcParam may not be required in contexts such as a
such as a variant of DNS over CoAP where messages are encrypted variant of DNS over CoAP where messages are encrypted using
using OSCORE. The service parameters MUST NOT include "ipv4hint" OSCORE. The service parameters MUST NOT include "ipv4hint" or
or "ipv6hint" SvcParams as they are superseded by the included IP "ipv6hint" SvcParams, as they are superseded by the included IP
addresses. addresses.
If no port service parameter is included, this indicates that If no port service parameter is included, this indicates that
default port numbers should be used. default port numbers should be used.
Note that "Addr Length", "ipv6-address(es)", and "Service Parameters Note that the "Addr Length", "ipv6-address(es)", and "Service
(SvcParams)" fields are not present if the ADN-only mode is used Parameters (SvcParams)" fields are not present if the ADN-only mode
(Section 3.1.6). is used (Section 3.1.6).
The option MUST be padded with zeros so that the full enclosed data The option MUST be padded with zeros so that the full enclosed data
is a multiple of 8 octets (Section 4.6 of [RFC4861]). is a multiple of 8 octets (Section 4.6 of [RFC4861]).
6.2. IPv6 Host Behavior 6.2. IPv6 Host Behavior
The procedure for DNS configuration is the same as it is with any The procedure for DNS configuration is the same as it is with any
other Neighbor Discovery option [RFC4861]. In addition, the host other Neighbor Discovery option [RFC4861]. In addition, the host
follows the same procedure as the one described in Section 5.3.1 of follows the same procedure as the procedure described in
[RFC8106] for processing received Encrypted DNS options with the Section 5.3.1 of [RFC8106] for processing received Encrypted DNS
formatting requirements in Section 6.1 and validation checks in options, with the formatting requirements listed in Section 6.1 and
Section 3.1.8 substituted for the length and fields validation. the validation checks listed in Section 3.1.8 substituted for length
and field validations.
The host MUST be prepared to receive multiple Encrypted DNS options The host MUST be prepared to receive multiple Encrypted DNS options
in RAs. These instances MUST be processed following their service in RAs. These instances MUST be processed following their service
priority (i.e., smaller service priority indicates a higher priority (i.e., a smaller service priority value indicates a higher
preference). preference).
The host MUST silently discard multicast and host loopback addresses The host MUST silently discard multicast and host loopback addresses
conveyed in the Encrypted DNS options. conveyed in the Encrypted DNS options.
7. Security Considerations 7. Security Considerations
7.1. Spoofing Attacks 7.1. Spoofing Attacks
DHCP/RA messages are not encrypted or protected against modification DHCP/RA messages are not encrypted or protected against modification
within the LAN. Unless mitigated (described below), the content of within the LAN. Unless spoofing attacks are mitigated as described
DHCP and RA messages can be spoofed or modified by active attackers, below, the content of DHCP and RA messages can be spoofed or modified
such as compromised devices within the local network. An active by active attackers, such as compromised devices within the local
attacker (Section 3.3 of [RFC3552]) can spoof the DHCP/RA response to network. An active attacker (Section 3.3 of [RFC3552]) can spoof the
provide the attacker's encrypted DNS resolver. Note that such an DHCP/RA response to provide the attacker's encrypted DNS resolver.
attacker can launch other attacks as discussed in Section 22 of Note that such an attacker can launch other attacks as discussed in
[RFC8415]. The attacker can get a domain name with a domain- Section 22 of [RFC8415]. The attacker can get a domain name with a
validated public certificate from a CA and host an encrypted DNS domain-validated public certificate from a Certificate Authority (CA)
resolver. and host an encrypted DNS resolver.
Attacks of spoofed or modified DHCP responses and RA messages by Attacks of spoofed or modified DHCP responses and RA messages by
attackers within the local network may be mitigated by making use of attackers within the local network may be mitigated by making use of
the following mechanisms: the following mechanisms:
* DHCPv6-Shield [RFC7610]: the network access node (e.g., a border DHCPv6-Shield [RFC7610]: The network access node (e.g., a border
router, a CPE, an Access Point (AP)) discards DHCP response router, a CPE, an Access Point (AP)) discards DHCP response
messages received from any local endpoint. messages received from any local endpoint.
* RA-Guard [RFC7113]: the network access node discards RAs messages RA-Guard [RFC7113]: The network access node discards RA messages
received from any local endpoint. received from any local endpoint.
* Source Address Validation Improvement (SAVI) solution for DHCP Source Address Validation Improvement (SAVI) solution for DHCP
[RFC7513]: the network access node filters packets with forged [RFC7513]: The network access node filters packets with forged
source IP addresses. source IP addresses.
The above mechanisms would ensure that the endpoint receives the The above mechanisms would ensure that the endpoint receives the
correct configuration information of the encrypted DNS resolvers correct configuration information of the encrypted DNS resolvers
selected by the DHCP server (or RA sender), but cannot provide any selected by the DHCP server (or RA sender), but these mechanisms
information about the DHCP server or the entity hosting the DHCP cannot provide any information about the DHCP server or the entity
server (or RA sender). hosting the DHCP server (or RA sender).
Encrypted DNS sessions with rogue resolvers that spoof the IP address Encrypted DNS sessions with rogue resolvers that spoof the IP address
of a DNS resolver will fail because the DNS client will fail to of a DNS resolver will fail because the DNS client will fail to
authenticate that rogue resolver based upon PKIX authentication authenticate that rogue resolver based upon PKIX authentication
[RFC6125], particularly the authentication domain name in the [RFC6125], particularly the ADN in the Encrypted DNS option. DNS
Encrypted DNS Option. DNS clients that ignore authentication clients that ignore authentication failures and accept spoofed
failures and accept spoofed certificates will be subject to attacks certificates will be subject to attacks (e.g., attacks that redirect
(e.g., redirect to malicious resolvers, intercept sensitive data). to malicious resolvers or intercept sensitive data).
7.2. Deletion Attacks 7.2. Deletion Attacks
If the DHCP responses or RAs are dropped by the attacker, the client If the DHCP responses or RAs are dropped by the attacker, the client
can fall back to use a preconfigured encrypted DNS resolver. can fall back to using a preconfigured encrypted DNS resolver.
However, the use of policies to select resolvers is out of the scope However, the use of policies to select resolvers is beyond the scope
of this document. of this document.
Note that deletion attack is not specific to DHCP/RA. Note that deletion attacks are not specific to DHCP/RA.
7.3. Passive Attacks 7.3. Passive Attacks
A passive attacker (Section 3.2 of [RFC3552]) can identify a host is A passive attacker (Section 3.2 of [RFC3552]) can determine that a
using DHCP/RA to discover an encrypted DNS resolver and can infer host is using DHCP/RA to discover an encrypted DNS resolver and can
that host is capable of using DoH/DoT/DoQ to encrypt DNS messages. infer that the host is capable of using DoH/DoT/DoQ to encrypt DNS
However, a passive attacker cannot spoof or modify DHCP/RA messages. messages. However, a passive attacker cannot spoof or modify DHCP/RA
messages.
7.4. Wireless Security - Authentication Attacks 7.4. Wireless Security - Authentication Attacks
Wireless LAN (WLAN) as frequently deployed in local networks (e.g., Wireless LANs (WLANs), frequently deployed in local networks (e.g.,
home networks) is vulnerable to various attacks (e.g., [Evil-Twin], home networks), are vulnerable to various attacks (e.g., [Evil-Twin],
[Krack], [Dragonblood]). Because of these attacks, only [Krack], [Dragonblood]). Because of these attacks, only
cryptographically authenticated communications are trusted on WLANs. cryptographically authenticated communications are trusted on WLANs.
This means that any information (e.g., NTP server, DNS resolver, This means that any information (e.g., regarding NTP servers, DNS
domain search list) provided by such networks via DHCP, DHCPv6, or RA resolvers, or domain search lists) provided by such networks via
is untrusted because DHCP and RA messages are not authenticated. DHCP, DHCPv6, or RA is untrusted because DHCP and RA messages are not
authenticated.
If the pre-shared key (PSK) is the same for all clients that connect If the pre-shared key (PSK) is the same for all clients that connect
to the same WLAN (e.g., WPA-PSK), the shared key will be available to to the same WLAN (e.g., Wi-Fi Protected Access Pre-Shared Key (WPA-
all nodes, including attackers. As such, it is possible to mount an PSK)), the shared key will be available to all nodes, including
active on-path attack. On-path attacks are possible within local attackers. As such, it is possible to mount an active on-path
networks because such a WLAN authentication lacks peer entity attack. On-path attacks are possible within local networks because
authentication. this form of WLAN authentication lacks peer entity authentication.
This leads to the need for provisioning unique credentials for This leads to the need for provisioning unique credentials for
different clients. Endpoints can be provisioned with unique different clients. Endpoints can be provisioned with unique
credentials (username and password, typically) provided by the local credentials (username and password, typically) provided by the local
network administrator to mutually authenticate to the local WLAN AP network administrator to mutually authenticate to the local WLAN AP
(e.g., 802.1x Wireless User Authentication on OpenWRT [dot1x], EAP- (e.g., 802.1x Wireless User Authentication on OpenWrt [dot1x], EAP-
pwd [RFC8146]). Not all endpoint devices (e.g., IoT devices) support pwd [RFC8146] ("EAP" stands for "Extensible Authentication
802.1x supplicant and need an alternate mechanism to connect to the Protocol")). Not all endpoint devices (e.g., Internet of Things
local network. To address this limitation, unique pre-shared keys (IoT) devices) support 802.1x supplicants and need an alternate
can be created for each such devices and WPA-PSK is used (e.g., mechanism to connect to the local network. To address this
[IPSK]). limitation, unique PSKs can be created for each such device and WPA-
PSK is used (e.g., [IPSK]).
8. Privacy Considerations 8. Privacy Considerations
Privacy considerations that are specific to DNR provisioning Privacy considerations that are also specific to DNR provisioning
mechanisms are discussed in Section 23 of [RFC8415] or [RFC7824]. mechanisms are discussed in Section 23 of [RFC8415] and in [RFC7824].
Anonymity profiles for DHCP clients are discussed in [RFC7844]. The Anonymity profiles for DHCP clients are discussed in [RFC7844]. The
mechanism defined in this document can be used to infer that a DHCP mechanisms defined in this document can be used to infer that a DHCP
client or IPv6 host support encrypted DNS options, but does not client or IPv6 host supports Encrypted DNS options, but these
explicitly reveal whether local DNS clients are able to consume these mechanisms do not explicitly reveal whether local DNS clients are
options or infer their encryption capabilities. Other than that, able to consume these options or infer their encryption capabilities.
this document does not expose more privacy information compared to Other than that, this document does not expose more privacy
Do53 discovery options. information compared to Do53 discovery options.
As discussed in [RFC9076], the use of encrypted DNS does not reduce As discussed in [RFC9076], the use of encrypted DNS does not reduce
the data available in the DNS resolver. For example, the reader may the data available in the DNS resolver. For example, the reader may
refer to Section 8 of [RFC8484] or Section 7 of [RFC9250] for a refer to Section 8 of [RFC8484] or Section 7 of [RFC9250] for a
discussion on specific privacy considerations to encrypted DNS. discussion on specific privacy considerations for encrypted DNS.
9. IANA Considerations 9. IANA Considerations
9.1. DHCPv6 Option 9.1. DHCPv6 Option
IANA is requested to assign the following new DHCPv6 Option Code in IANA has assigned the following new DHCPv6 Option Code in the "Option
the registry maintained in [DHCPV6]. Codes" registry maintained at [DHCPV6].
+=======+===============+============+===========+================+ +=======+===============+============+==================+===========+
| Value | Description | Client ORO | Singleton | Reference | | Value | Description | Client ORO | Singleton | Reference |
| | | | Option | | | | | | Option | |
+=======+===============+============+===========+================+ +=======+===============+============+==================+===========+
| TBA1 | OPTION_V6_DNR | Yes | No | [ThisDocument] | | 144 | OPTION_V6_DNR | Yes | No | RFC 9463 |
+-------+---------------+------------+-----------+----------------+ +-------+---------------+------------+------------------+-----------+
Table 1: DHCPv6 Encrypted DNS Option Table 1: DHCPv6 Encrypted DNS Option
9.2. DHCPv4 Option 9.2. DHCPv4 Option
IANA is requested to assign the following new DHCP Option Code in the IANA has assigned the following new DHCP Option Code in the "BOOTP
registry maintained in [BOOTP]. Vendor Extensions and DHCP Options" registry maintained at [BOOTP].
+======+===============+=============+============+================+ +=====+===============+=============+============+===========+
| Tag | Name | Data Length | Meaning | Reference | | Tag | Name | Data Length | Meaning | Reference |
+======+===============+=============+============+================+ +=====+===============+=============+============+===========+
| TBA2 | OPTION_V4_DNR | N | Encrypted | [ThisDocument] | | 162 | OPTION_V4_DNR | N | Encrypted | RFC 9463 |
| | | | DNS Server | | | | | | DNS Server | |
+------+---------------+-------------+------------+----------------+ +-----+---------------+-------------+------------+-----------+
Table 2: DHCPv4 Encrypted DNS Option Table 2: DHCPv4 Encrypted DNS Option
9.3. Neighbor Discovery Option 9.3. Neighbor Discovery Option
IANA is requested to assign the following new IPv6 Neighbor Discovery IANA has assigned the following new IPv6 Neighbor Discovery Option
Option type in the "IPv6 Neighbor Discovery Option Formats" sub- type in the "IPv6 Neighbor Discovery Option Formats" subregistry
registry under the "Internet Control Message Protocol version 6 under the "Internet Control Message Protocol version 6 (ICMPv6)
(ICMPv6) Parameters" registry maintained in [ND]. Parameters" registry maintained at [ND].
+======+======================+================+
| Type | Description | Reference |
+======+======================+================+
| TBA3 | Encrypted DNS Option | [ThisDocument] |
+------+----------------------+----------------+
Table 3: Neighbor Discovery Encrypted DNS Option
10. Acknowledgements
Many thanks to Christian Jacquenet and Michael Richardson for the
review.
Thanks to Stephen Farrell, Martin Thomson, Vittorio Bertola, Stephane
Bortzmeyer, Ben Schwartz, Iain Sharp, and Chris Box for the comments.
Thanks to Mark Nottingham for the feedback on HTTP redirection that
was discussed in previous versions of this specification.
The use of DHCP to retrieve an authentication domain name was
discussed in Section 7.3.1 of [RFC8310] and in an Internet-Draft
authored by Tom Pusateri and Willem Toorop
[I-D.pusateri-dhc-dns-driu].
Thanks to Bernie Volz for the review of the DHCP part.
Christian Amsuess reported a case where ALPN service parameter cannot
be used.
Thanks to Andrew Campling for the Shepherd review and Eric Vyncke for
the AD review.
Thanks to Rich Salz for the secdir reviews, Joe Clarke for the ops-
dir review, Robert Sparks for the artart review, and David Blacka for
the dnsdir review.
Thanks to Lars Eggert, Roman Danyliw, Erik Kline, Martin Duke, Robert
Wilton, Paul Wouters, and Zaheduzzaman Sarker for the IESG review.
11. Contributing Authors
Nicolai Leymann
Deutsche Telekom
Germany
Email: n.leymann@telekom.de
Zhiwei Yan
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
100190
China
Email: yan@cnnic.cn
12. References +======+======================+===========+
| Type | Description | Reference |
+======+======================+===========+
| 144 | Encrypted DNS Option | RFC 9463 |
+------+----------------------+-----------+
12.1. Normative References Table 3: Neighbor Discovery Encrypted
DNS Option
[I-D.ietf-add-svcb-dns] 10. References
Schwartz, B. M., "Service Binding Mapping for DNS
Servers", Work in Progress, Internet-Draft, draft-ietf-
add-svcb-dns-08, 14 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-add-
svcb-dns-08>.
[I-D.ietf-dnsop-svcb-https] 10.1. Normative References
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-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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/info/rfc2132>. <https://www.rfc-editor.org/info/rfc2132>.
skipping to change at page 23, line 20 skipping to change at line 960
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
12.2. Informative References [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (DNS SVCB and
HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/info/rfc9460>.
[BOOTP] "BOOTP Vendor Extensions and DHCP Options", [RFC9461] Schwartz, B., "Service Binding Mapping for DNS Servers",
<https://www.iana.org/assignments/bootp-dhcp-parameters/ RFC 9461, DOI 10.17487/RFC9461, November 2023,
bootp-dhcp-parameters.xhtml#options>. <https://www.rfc-editor.org/info/rfc9461>.
[DHCPV6] "DHCPv6 Option Codes", <https://www.iana.org/assignments/ 10.2. Informative References
dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-
parameters-2>.
[dot1x] Cisco, "Basic 802.1x Wireless User Authentication", [BOOTP] IANA, "BOOTP Vendor Extensions and DHCP Options",
<https://www.iana.org/assignments/bootp-dhcp-parameters/>.
[DHCPV6] IANA, "Option Codes",
<https://www.iana.org/assignments/dhcpv6-parameters/>.
[DNS-TLS-DHCPv6-Options]
Pusateri, T. and W. Toorop, "DHCPv6 Options for private
DNS Discovery", Work in Progress, Internet-Draft, draft-
pusateri-dhc-dns-driu-00, 2 July 2018,
<https://datatracker.ietf.org/doc/html/draft-pusateri-dhc-
dns-driu-00>.
[dot1x] OpenWrt, "Introduction to 802.1X", December 2021,
<https://openwrt.org/docs/guide-user/network/wifi/ <https://openwrt.org/docs/guide-user/network/wifi/
wireless.security.8021x>. wireless.security.8021x>.
[Dragonblood] [Dragonblood]
The Unicode Consortium, "Dragonblood: Analyzing the Vanhoef, M. and E. Ronen, "Dragonblood: Analyzing the
Dragonfly Handshake of WPA3 and EAP-pwd", Dragonfly Handshake of WPA3 and EAP-pwd", 2020 IEEE
<https://papers.mathyvanhoef.com/dragonblood.pdf>. Symposium on Security and Privacy (SP), San Francisco, pp.
517-533, DOI 10.1109/SP40000.2020.00031, May 2020,
<https://ieeexplore.ieee.org/document/9152782>.
[Evil-Twin] [Evil-Twin]
The Unicode Consortium, "Evil twin (wireless networks)", Wikipedia, "Evil twin (wireless networks)", November 2022,
<https://en.wikipedia.org/wiki/ <https://en.wikipedia.org/wiki/
Evil_twin_(wireless_networks)>. Evil_twin_(wireless_networks)>.
[I-D.ietf-add-ddr] [IPSK] Cisco, "8.5 Identity PSK Feature Deployment Guide",
Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. December 2021,
Jensen, "Discovery of Designated Resolvers", Work in <https://www.cisco.com/c/en/us/td/docs/wireless/
Progress, Internet-Draft, draft-ietf-add-ddr-10, 5 August controller/technotes/8-5/
2022, <https://datatracker.ietf.org/doc/html/draft-ietf- b_Identity_PSK_Feature_Deployment_Guide.html>.
add-ddr-10>.
[I-D.ietf-add-split-horizon-authority] [Krack] Vanhoef, M. and F. Piessens, "Key Reinstallation Attacks:
Reddy.K, T., Wing, D., Smith, K., and B. M. Schwartz, Forcing Nonce Reuse in WPA2", CCS '17: Proceedings of the
2017 ACM SIGSAC Conference on Computer and Communications
Security, pp. 1313-1328, DOI 10.1145/3133956.3134027,
October 2017,
<https://dl.acm.org/doi/10.1145/3133956.3134027>.
[Local-DNS-Authority]
Reddy, T., Wing, D., Smith, K., and B. Schwartz,
"Establishing Local DNS Authority in Validated Split- "Establishing Local DNS Authority in Validated Split-
Horizon Environments", Work in Progress, Internet-Draft, Horizon Environments", Work in Progress, Internet-Draft,
draft-ietf-add-split-horizon-authority-04, 8 March 2023, draft-ietf-add-split-horizon-authority-04, 8 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-add- <https://datatracker.ietf.org/doc/html/draft-ietf-add-
split-horizon-authority-04>. split-horizon-authority-04>.
[I-D.pusateri-dhc-dns-driu] [ND] IANA, "IPv6 Neighbor Discovery Option Formats",
Pusateri, T. and W. Toorop, "DHCPv6 Options for private <https://www.iana.org/assignments/icmpv6-parameters/>.
DNS Discovery", Work in Progress, Internet-Draft, draft-
pusateri-dhc-dns-driu-00, 2 July 2018,
<https://datatracker.ietf.org/doc/html/draft-pusateri-dhc-
dns-driu-00>.
[IPSK] Cisco, "Identity PSK Feature Deployment Guide",
<https://www.cisco.com/c/en/us/td/docs/wireless/
controller/technotes/8-5/
b_Identity_PSK_Feature_Deployment_Guide.html>.
[Krack] The Unicode Consortium, "Key Reinstallation Attacks",
2017, <https://www.krackattacks.com/>.
[ND] "IPv6 Neighbor Discovery Option Formats",
<https://www.iana.org/assignments/icmpv6-parameters/
icmpv6-parameters.xhtml#icmpv6-parameters-5>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
DOI 10.17487/RFC3646, December 2003, DOI 10.17487/RFC3646, December 2003,
<https://www.rfc-editor.org/info/rfc3646>. <https://www.rfc-editor.org/info/rfc3646>.
skipping to change at page 26, line 46 skipping to change at line 1132
[RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076, [RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076,
DOI 10.17487/RFC9076, July 2021, DOI 10.17487/RFC9076, July 2021,
<https://www.rfc-editor.org/info/rfc9076>. <https://www.rfc-editor.org/info/rfc9076>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250, Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022, DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>. <https://www.rfc-editor.org/info/rfc9250>.
[TS.24008] 3GPP, "Mobile radio interface Layer 3 specification; Core [RFC9462] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
network protocols; Stage 3 (Release 16)", December 2019, Jensen, "Discovery of Designated Resolvers", RFC 9462,
DOI 10.17487/RFC9462, November 2023,
<https://www.rfc-editor.org/info/rfc9462>.
[TS.24008] 3GPP, "Technical Specification Group Core Network and
Terminals; Mobile radio interface Layer 3 specification;
Core network protocols; Stage 3 (Release 18)", version
18.4.0, September 2023,
<https://www.3gpp.org/DynaReport/24008.htm>. <https://www.3gpp.org/DynaReport/24008.htm>.
Acknowledgments
Many thanks to Christian Jacquenet and Michael Richardson for their
reviews.
Thanks to Stephen Farrell, Martin Thomson, Vittorio Bertola, Stéphane
Bortzmeyer, Ben Schwartz, Iain Sharp, and Chris Box for their
comments.
Thanks to Mark Nottingham for the feedback on HTTP redirection that
was discussed in previous draft versions of this specification.
The use of DHCP as a candidate protocol to retrieve an ADN was
mentioned in Section 7.3.1 of [RFC8310] and in an Internet-Draft
authored by Tom Pusateri and Willem Toorop [DNS-TLS-DHCPv6-Options].
Thanks to Bernie Volz for the review of the DHCP part.
Christian Amsüss reported a case where the ALPN service parameter
cannot be used.
Thanks to Andrew Campling for the Shepherd review and Éric Vyncke for
the AD review.
Thanks to Rich Salz for the secdir reviews, Joe Clarke for the opsdir
review, Robert Sparks for the artart review, and David Blacka for the
dnsdir review.
Thanks to Lars Eggert, Roman Danyliw, Erik Kline, Martin Duke, Robert
Wilton, Paul Wouters, and Zaheduzzaman Sarker for the IESG review.
Contributors
Nicolai Leymann
Deutsche Telekom
Germany
Email: n.leymann@telekom.de
Zhiwei Yan
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
100190
China
Email: yan@cnnic.cn
Authors' Addresses Authors' Addresses
Mohamed Boucadair (editor) Mohamed Boucadair (editor)
Orange Orange
35000 Rennes 35000 Rennes
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Tirumaleswar Reddy (editor) Tirumaleswar Reddy.K (editor)
Nokia Nokia
India India
Email: kondtir@gmail.com Email: kondtir@gmail.com
Dan Wing Dan Wing
Citrix Systems, Inc. Cloud Software Group Holdings, Inc.
United States of America United States of America
Email: dwing-ietf@fuggles.com Email: dwing-ietf@fuggles.com
Neil Cook Neil Cook
Open-Xchange Open-Xchange
United Kingdom United Kingdom
Email: neil.cook@noware.co.uk Email: neil.cook@noware.co.uk
Tommy Jensen Tommy Jensen
Microsoft Microsoft
 End of changes. 133 change blocks. 
446 lines changed or deleted 451 lines changed or added

This html diff was produced by rfcdiff 1.48.