RFC 9463

DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)

📅 published November 2023, from ietf

RFC 9463: DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) 🦋

Request for Comments: 9463 📜 Series: ISSN 2070-1721 Category: Standards Track 🎀 Date: November 2023 📅 Publisher: Internet Engineering Task Force (IETF) 💜 Obsoletes / Updates: the title block doesn't list anything this RFC obsoletes or updates 🤷‍♀️

Authors: M. Boucadair, Ed. (Orange), T. Reddy.K, Ed. (Nokia), D. Wing (Cloud Software Group), N. Cook (Open-Xchange), and T. Jensen (Microsoft) 👯‍♀️✨

Abstract 🌈

okay so this doc defines new DHCP and IPv6 Router Advertisement options 🎁 that let a device find encrypted DNS resolvers on its local network. the examples are DNS over HTTPS, DNS over TLS, and DNS over QUIC 🔐. the big win is that a host can learn an Authentication Domain Name, a list of IP addresses, and a set of service parameters, all it needs to reach those encrypted resolvers 💖

Status of This Memo 📌

this one is an Internet Standards Track document 🔥

it's a product of the IETF, so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 7841 🧚

for the current status, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc9463 🦋

copyright is 2023, held by the IETF Trust and the people listed as authors. all rights reserved 💅

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they were on the publication date. please read those carefully, because they spell out your rights and restrictions 📖

one more thing: any Code Components pulled out of this doc must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. they come with no warranty, same as the Revised BSD License says 🫶

Table of Contents 🗂️

   1.  Introduction
   2.  Terminology
   3.  Overview
     3.1.  Configuration Data for Encrypted DNS
       3.1.1.  ADN as Reference Identifier for DNS Authentication
       3.1.2.  Avoiding Dependency on External Resolvers
       3.1.3.  Single vs. Multiple IP Addresses
       3.1.4.  Why Not Separate Options for the ADN and IP Addresses?
       3.1.5.  Service Parameters
       3.1.6.  ADN-Only Mode
       3.1.7.  Ordering of Encrypted DNS Options
       3.1.8.  DNR Validation Checks
       3.1.9.  DNR Information Using Other Provisioning Mechanisms
     3.2.  Handling Configuration Data Conflicts
     3.3.  Validating Discovered Resolvers
     3.4.  Multihoming Considerations
   4.  DHCPv6 Encrypted DNS Option
     4.1.  Option Format
     4.2.  DHCPv6 Client Behavior
   5.  DHCPv4 Encrypted DNS Option
     5.1.  Option Format
     5.2.  DHCPv4 Client Behavior
   6.  IPv6 RA Encrypted DNS Option
     6.1.  Option Format
     6.2.  IPv6 Host Behavior
   7.  Security Considerations
     7.1.  Spoofing Attacks
     7.2.  Deletion Attacks
     7.3.  Passive Attacks
     7.4.  Wireless Security - Authentication Attacks
   8.  Privacy Considerations
   9.  IANA Considerations
     9.1.  DHCPv6 Option
     9.2.  DHCPv4 Option
     9.3.  Neighbor Discovery Option
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Acknowledgments
   Contributors
   Authors' Addresses

1. Introduction 💖

this doc is all about finding encrypted DNS resolvers that run protocols like DNS over HTTPS (DoH) [RFC8484], DNS over TLS (DoT) [RFC7858], or DNS over QUIC (DoQ) [RFC9250] on a local network 🏠

specifically, it explains how connected hosts can discover a local encrypted DNS resolver through DHCPv4 [RFC2132], DHCPv6 [RFC8415], and IPv6 Router Advertisement (RA) options [RFC4861] 🎀 the options carry three things: the DNS Authentication Domain Name (ADN), a list of IP addresses, and a set of service parameters. the whole procedure is called Discovery of Network-designated Resolvers (DNR) ✨

these options fit lots of setups, like local networks with Customer Premises Equipment (CPEs) that an Internet Service Provider (ISP) may or may not manage, or local networks with or without DNS forwarders 🌸 making an inventory of those deployments is beyond the scope of this doc, so we're skipping it 🙈

resolver selection considerations are out of scope too. and so are policies, including anything about interacting with users 💅

2. Terminology 🧚

here's the BCP 14 part, so pay attention 👀 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 read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, exactly as shown here 🔥

this doc uses terms defined in [RFC8499]. it also adds a few of its own:

  • Authentication Domain Name (ADN): a domain name a DNS client uses to authenticate a DNS resolver 🔑
  • ADN-only mode: a DNS discovery mode where only the ADN of the DNS resolver gets retrieved. see Section 3.1.6 🌷
  • Do53: unencrypted DNS 🙃
  • DNR: the procedure called Discovery of Network-designated Resolvers 🦋
  • Encrypted DNS: a scheme where DNS exchanges travel over an encrypted channel. examples are DoT, DoH, and DoQ 🔐
  • Encrypted DNS resolver: a DNS resolver that supports any encrypted DNS scheme 💜
  • Encrypted DNS options: the options defined in Sections 4, 5, and 6 🎁
  • DHCP: refers to both DHCPv4 and DHCPv6 🌈

3. Overview 🌸

this section explains how a DNS client can discover local encrypted DNS resolvers. it uses the DHCP Encrypted DNS options (Sections 4 and 5) and the Neighbor Discovery protocol Encrypted DNS option (Section 6) 🧁

these options configure an ADN, a list of IP addresses, and a set of service parameters for the encrypted DNS resolver. the subsections below dig into the design 🤓

3.1. Configuration Data for Encrypted DNS 🎀

3.1.1. ADN as Reference Identifier for DNS Authentication 🪪

so, to let the client do PKIX-based authentication of the encrypted DNS resolver, the Encrypted DNS options always include an ADN. that ADN is the reference identifier used for DNS authentication 🔏 this matches today's best practices for issuing certificates, per Section 1.7.2 of [RFC6125]. the RFC6125 text says:

   |  Some certification authorities issue server certificates based
   |  on IP addresses, but preliminary evidence indicates that such
   |  certificates are a very small percentage (less than 1%) of
   |  issued certificates.

3.1.2. Avoiding Dependency on External Resolvers 🙅‍♀️

we don't want to add a dependency on another server just to resolve the ADN 💅 so the Encrypted DNS options return the IP address(es) used to locate an encrypted DNS resolver. those resolvers might sit on the same IP address or on different ones, and that's up to the deployment 🌍

early drafts of this doc thought about using the discovery mechanisms from [RFC2132], [RFC3646], and [RFC8106] to fetch a list of IP addresses for the DNS resolvers. but that means a client supporting more than one encrypted DNS protocol (like DoH and DoT) would have to probe that list, which is messy 😩 so the options in Sections 4, 5, and 6 link each encrypted DNS protocol to an IP address directly. no probing needed ✨

3.1.3. Single vs. Multiple IP Addresses 📍

an Encrypted DNS option can carry a list of IP addresses for an encrypted DNS resolver. that covers current deployments that use primary and backup resolvers 🔁 DNR also works where other DNS redundancy schemes are in play, like anycast as discussed in BCP 126 [RFC4786] 🌐

whether you get one IP address or several is up to the deployment. for example, a router that embeds a recursive server or a forwarder has to include one single IP address that points to one of its LAN-facing interfaces. that address is typically a private IPv4 address, a Link-Local address, an IPv6 Unique Local Address (ULA), or a Global Unicast Address (GUA) 🏡

if multiple IP addresses go into one Encrypted DNS option, they're listed in order of preference for the client to use 🥇

3.1.4. Why Not Separate Options for the ADN and IP Addresses? 🤔

short answer: one option carries both the ADN and the IP addresses 🎀 the reason is that if the ADN and IP addresses lived in separate options, you'd need a way to match an IP address in one option with an ADN in another. that gets necessary fast if the network supports more than one ADN 🙃

3.1.5. Service Parameters 🎛️

distinct encrypted DNS protocols, like DoT, DoH, and DoQ, may be provisioned by a network. some of them might use custom port numbers instead of the default ones. that's why the Encrypted DNS options return a set of service parameters 💜 these parameters are encoded using the same rules for encoding SvcParams, with the wire format from Section 2.2 of [RFC9460] 🧩 yes, this makes the options a bit bigger. but the upside is it relies on an existing IANA registry, so new encrypted DNS protocols and service parameters defined later can slide right in 🦋

the following service parameters MUST be supported by a DNR implementation:

  • alpn: indicates the set of supported protocols (Section 7.1 of [RFC9460]) 🗣️
  • port: indicates the target port number for the encrypted DNS connection (Section 7.2 of [RFC9460]) 🔌

and the following service parameter is RECOMMENDED to be supported by a DNR implementation:

  • dohpath: supplies a relative DoH URI Template (Section 5.1 of [RFC9461]) 🌷

that's the end of part 1! 🌈✨ hang tight, part 2 is coming and it's going to be even more iconic 💖

3.1.6. ADN-Only Mode 🦋

okay so the provisioning mode where you get an ADN, a list of IP addresses, and a set of service parameters for the encrypted DNS resolver all in one go is the one you SHOULD use 💅 because the Encrypted DNS options are totally self-contained, so no extra DNS queries are needed. if you want the deep dive on the fancy stuff DHCP servers can do to fill in config data (like issuing DNS queries), peep [RFC7969] 🤓

if it's cool for requesting hosts to take on extra complexity, returning just an ADN is also an option 🧠 the supplied ADN gets passed to a local resolution library (usually a DNS client), which then issues Service Binding (SVCB) queries [RFC9461]. those SVCB queries can go to the discovered encrypted DNS resolver itself or to the network-designated Do53 resolver. heads up though: this mode may be subject to active attacks, which can be mitigated by DNSSEC 🔐

How an ADN is passed to a local resolution library is implementation specific. 🌸

3.1.7. Ordering of Encrypted DNS Options 🎀

the DHCP options defined in Sections 4 and 5 follow the option ordering guidelines in Section 17 of [RFC7227] ✨

likewise, the RA option (Section 6) sticks to the recommendations in Section 9 of [RFC4861] 💜

3.1.8. DNR Validation Checks 🔍

okay bestie, when a DHCP client (or IPv6 host) receives an Encrypted DNS option, it runs these validation checks:

  • The ADN is present and encoded as per Section 10 of [RFC8415].
  • If additional data is supplied:
    • The service parameters are encoded following the rules specified in Section 2.2 of [RFC9460].
    • The option includes at least one valid IP address.
    • The service parameters do not include ipv4hint or ipv6hint parameters.

if any of the checks fail, the receiver discards the received Encrypted DNS option 💀 no second chances!!

3.1.9. DNR Information Using Other Provisioning Mechanisms 🌈

the provisioning mechanisms in this document may not be available on every network (for example, some cellular networks exclusively use Protocol Configuration Options (PCOs) [TS.24008]), or they may not be suitable in some contexts (like where secure discovery is needed). other mechanisms may be considered in these contexts for provisioning encrypted DNS resolvers 🫶 it is RECOMMENDED that at least the following DNR information be made available to a requesting host:

  • A service priority whenever the discovery mechanism does not rely on implicit ordering if multiple instances of the encrypted DNS are used.
  • An ADN. This parameter is mandatory.
  • A list of IP addresses to locate the encrypted DNS resolver.
  • A set of service parameters.

3.2. Handling Configuration Data Conflicts 🤝

if a host discovers encrypted DNS resolvers using both RA and DHCP, the rules discussed in Section 5.3.1 of [RFC8106] MUST be followed. no drama, just follow the rules 📜

DHCP/RA options to discover encrypted DNS resolvers (including DoH URI Templates) takes precedence over Discovery of Designated Resolvers (DDR) [RFC9462]. the reason is giving main character energy 👑 DDR uses Do53 to an external DNS resolver, which is susceptible to both internal and external attacks, whereas DHCP/RA is typically protected using the mechanisms discussed in Section 7.1.

if a client learns both Do53 and encrypted DNS resolvers from the same network, and there's no explicit configuration saying otherwise, it is RECOMMENDED that the client use the encrypted DNS resolvers for that network 🔒 if the client cannot establish an authenticated and encrypted connection with the encrypted DNS resolver, it may fall back to using the Do53 resolver.

3.3. Validating Discovered Resolvers ✅

this section describes a set of validation checks to confirm that an encrypted DNS resolver matches what was provided using DNR (for example, DHCP or RA). these checks are not meant to validate the security of the DNR provisioning mechanisms or the user's trust relationship to the network, so don't get it twisted 🙈

if the local DNS client supports one of the discovered encrypted DNS protocols identified by Application-Layer Protocol Negotiation (ALPN) protocol identifiers (or another service parameter that indicates some other protocol disambiguation mechanism), the DNS client establishes an encrypted DNS session following the service priority of the discovered encrypted resolvers 🦋

the DNS client verifies the connection based on PKIX validation [RFC5280] of the DNS resolver certificate. it uses the validation techniques described in [RFC6125] to compare the ADN conveyed in the Encrypted DNS options to the certificate provided (see Section 8.1 of [RFC8310] for more details). the DNS client uses the default system or application PKI trust anchors unless it's configured otherwise to use explicit trust anchors 🧚 ALPN-related considerations can be found in Section 7.1 of [RFC9460]. operational considerations related to checking the revocation status of the certificate of an encrypted DNS resolver are discussed in Section 10 of [RFC8484].

3.4. Multihoming Considerations 🌐

devices may be connected to multiple networks, each providing their own DNS configuration using the discovery mechanisms specified in this document. still, discussing DNS selection for multi-interfaced devices is beyond the scope of this specification. those considerations fall under the generic issue of handling multiple provisioning sources and should not be processed in each option separately, as per the recommendation in Section 12 of [RFC7227] 🫠

the reader may refer to [RFC6731] for a discussion of DNS selection issues and an example of DNS resolver selection for multi-interfaced devices. also, the reader may refer to [Local-DNS-Authority] for a discussion on how DNR and Provisioning Domain (PvD) key "dnsZones" (Section 4.3 of [RFC8801]) can be used in "split DNS" environments (Section 6 of [RFC8499]) 💜

4. DHCPv6 Encrypted DNS Option ✨

4.1. Option Format 💖

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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       OPTION_V6_DNR           |         Option-length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Service Priority        |         ADN Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                   authentication-domain-name                  ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Addr Length           |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     ~                        ipv6-address(es)                       ~
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     ~                 Service Parameters (SvcParams)                ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: DHCPv6 Encrypted DNS Option

here's how each field in Figure 1 works 🧁

  • Option-code: OPTION_V6_DNR (144; see Section 9.1).
  • Option-length: length of the enclosed data in octets. the option length is ('ADN Length' + 4) when only an ADN is included in the option.
  • Service Priority: the priority of this OPTION_V6_DNR instance compared to other instances. this 16-bit unsigned integer is interpreted following the rules specified in Section 2.4.1 of [RFC9460].
  • ADN Length: length of the authentication-domain-name field in octets.
  • authentication-domain-name (variable length): a Fully Qualified Domain Name (FQDN) of the encrypted DNS resolver. this field is formatted as specified in Section 10 of [RFC8415].

an example of the authentication-domain-name encoding is shown in Figure 2. this example conveys the FQDN "doh1.example.com.", and the resulting ADN Length field is 18 🌸

       +------+------+------+------+------+------+------+------+------+
       | 0x04 |   d  |   o  |   h  |  1   | 0x07 |   e  |   x  |   a  |
       +------+------+------+------+------+------+------+------+------+
       |   m  |   p  |   l  |   e  | 0x03 |   c  |   o  |   m  | 0x00 |
       +------+------+------+------+------+------+------+------+------+

Figure 2: An Example of the DNS authentication-domain-name Encoding

  • Addr Length: length of enclosed IPv6 addresses in octets. when present, it MUST be a multiple of 16 🧮
  • ipv6-address(es) (variable length): indicates one or more IPv6 addresses to reach the encrypted DNS resolver. an address can be a Link-Local address, a ULA, or a GUA. the format of this field 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                         ipv6-address                          |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Format of the ipv6-address(es) Field

  • Service Parameters (SvcParams) (variable length): specifies a set of service parameters that are encoded following the rules in Section 2.2 of [RFC9460]. service parameters may include, for example, a list of ALPN protocol identifiers or alternate port numbers. this field SHOULD include at least the alpn SvcParam. the alpn SvcParam may not be required in contexts such as a variant of DNS over the Constrained Application Protocol (CoAP) where messages are encrypted using Object Security for Constrained RESTful Environments (OSCORE) [RFC8613]. the service parameters MUST NOT include ipv4hint or ipv6hint SvcParams, as they are superseded by the included IP addresses 🚫

if no port service parameter is included, this indicates that default port numbers should be used. as a reminder, the default port number is 853 for DoT, 443 for DoH, and 853 for DoQ 🔢

the length of this field is ('Option-length' - 6 - 'ADN Length' - 'Addr Length') 🧠

note that the Addr Length, ipv6-address(es), and Service Parameters (SvcParams) fields are not present if the ADN-only mode is used (Section 3.1.6) 💅

4.2. DHCPv6 Client Behavior 💅

okay so bestie, the DHCPv6 client is the one doing the hunting 🎯 to find an encrypted DNS resolver. It MUST include OPTION_V6_DNR in an Option Request Option (ORO), per Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of [RFC8415] ✨.

The client MUST be prepared to receive multiple instances of OPTION_V6_DNR 🌸. Each one counts as its own separate encrypted DNS resolver. They MUST be processed in service priority order, where a smaller service priority value means a higher preference 👑.

The DHCPv6 client MUST silently discard any OPTION_V6_DNR that fails the validation steps in Section 3.1.8 🙈.

The DHCPv6 client MUST silently discard multicast and host loopback addresses conveyed in OPTION_V6_DNR 💀.

5. DHCPv4 Encrypted DNS Option 🎀

5.1. Option Format

Here's the DHCPv4 Encrypted DNS option, shown in Figure 4 🧚:

                 0                   1
                 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                | OPTION_V4_DNR |     Length    |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                ~      DNR Instance Data #1     ~
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---
                .              ...              .    |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ optional
                ~      DNR Instance Data #n     ~    |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---

Figure 4: DHCPv4 Encrypted DNS Option

Here's what each field does:

Code: OPTION_V4_DNR (162; see Section 9.2).

Length: how many octets of enclosed data there are.

DNR Instance Data: the configuration data for an encrypted DNS resolver. Its format is shown in Figure 5 💖.

                       0                   1
                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |    DNR Instance Data Length   |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |       Service Priority        |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |   ADN Length  |               |
                      +-+-+-+-+-+-+-+-+               |
                      ~  authentication-domain-name   ~
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |  Addr Length  |               |
                      +-+-+-+-+-+-+-+-+               |
                      ~        IPv4 Address(es)       ~
                      |               +-+-+-+-+-+-+-+-+
                      |               |               |
                      +-+-+-+-+-+-+-+-+               |
                      ~Service Parameters (SvcParams) ~
                      |                               |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: DNR Instance Data Format

When several encrypted DNS resolvers are included, the "DNR Instance Data" field gets repeated 🔁.

The fields in Figure 5 work like this:

DNR Instance Data Length: the length of all the data that follows, in octets. It's set to ('ADN Length' + 3) when only an ADN is provided for a DNR instance 🍓.

Service Priority: how this instance ranks against other DNR instances. It's a 16-bit unsigned integer, interpreted using the rules in Section 2.4.1 of [RFC9460].

ADN Length: the length of the authentication-domain-name field, in octets.

authentication-domain-name (variable length): the ADN of the encrypted DNS resolver. It's formatted as specified in Section 10 of [RFC8415], and there's an example in Figure 2.

Addr Length: the length of the included IPv4 addresses, in octets. When it's present, it MUST be a multiple of 4 🔢.

IPv4 Address(es) (variable length): one or more IPv4 addresses for reaching the encrypted DNS resolver. Both private and public IPv4 addresses can be included here 🌈. The format is shown in Figure 6, which assumes an IPv4 address is encoded as a1.a2.a3.a4.

                 0     8     16    24    32    40    48
                 +-----+-----+-----+-----+-----+-----+--
                 |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 | ...
                 +-----+-----+-----+-----+-----+-----+--
                   IPv4 Address 1          IPv4 Address 2 ...

Figure 6: Format of the IPv4 Address(es) Field

Service Parameters (SvcParams) (variable length): a set of service parameters encoded using the rules in Section 2.2 of [RFC9460]. These can include things like a list of ALPN protocol identifiers or alternate port numbers ✨. This field SHOULD include at least the "alpn" SvcParam. The "alpn" SvcParam may not be required in contexts such as a variant of DNS over CoAP where messages are encrypted using OSCORE. The service parameters MUST NOT include "ipv4hint" or "ipv6hint" SvcParams, because the included IP addresses supersede them 🚫.

If there's no port service parameter, default port numbers should be used 🦋.

The length of this field is ('DNR Instance Data Length' - 4 - 'ADN Length' - 'Addr Length').

Heads up: the "Addr Length", "IPv4 Address(es)", and "Service Parameters (SvcParams)" fields are NOT present if ADN-only mode is used (Section 3.1.6). Don't go looking for them! 🙈

OPTION_V4_DNR is a concatenation-requiring option 🧵. That means the mechanism in [RFC3396] MUST be used if OPTION_V4_DNR exceeds the maximum DHCPv4 option size of 255 octets.

5.2. DHCPv4 Client Behavior

To find an encrypted DNS resolver, the DHCPv4 client asks for it by including OPTION_V4_DNR in a Parameter Request List option [RFC2132] 🎯.

The DHCPv4 client MUST be prepared to receive multiple "DNR Instance Data" field entries in the OPTION_V4_DNR option 🌸. Each instance is treated as a separate encrypted DNS resolver. These instances MUST be processed following their service priority, where a smaller service priority value indicates a higher preference 👑.

The DHCPv4 client MUST silently discard any OPTION_V4_DNR that fails the validation steps in Section 3.1.8 🙈.

The DHCPv4 client MUST silently discard multicast and host loopback addresses conveyed in OPTION_V4_DNR 💀.

6. IPv6 RA Encrypted DNS Option 🦋

6.1. Option Format

This section defines a brand new Neighbor Discovery option [RFC4861]: the IPv6 RA Encrypted DNS option 🌈. It's useful in the kinds of contexts discussed in Section 1.1 of [RFC8106].

The format is shown in Figure 7 💖:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Length    |        Service Priority       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Lifetime                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          ADN Length           |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     ~                   authentication-domain-name                  ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Addr Length           |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     ~                        ipv6-address(es)                       ~
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |     SvcParams Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                 Service Parameters (SvcParams)                ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: RA Encrypted DNS Option

Here's what each field does:

Type: an 8-bit identifier for the Encrypted DNS option, as assigned by IANA (144; see Section 9.3) 🔖.

Length: an 8-bit unsigned integer. The length of the option, including the Type and Length fields, is measured in units of 8 octets.

Service Priority: a 16-bit unsigned integer showing how this Encrypted DNS option instance ranks against other instances. It's interpreted using the rules in Section 2.4.1 of [RFC9460].

Lifetime: a 32-bit unsigned integer. It's the maximum time in seconds (counted from when the packet is received) during which the discovered ADN is valid ⏳.

The value of Lifetime SHOULD by default be at least 3 * MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA interval defined in [RFC4861].

A value of all one bits (0xffffffff) means infinity ♾️.

A value of zero means this ADN MUST no longer be used 🛑.

ADN Length: a 16-bit unsigned integer giving the length of the authentication-domain-name field, in octets.

authentication-domain-name (variable length): the ADN of the encrypted DNS resolver. It's formatted as specified in Section 10 of [RFC8415].

Addr Length: a 16-bit unsigned integer giving the length of the enclosed IPv6 addresses, in octets. When it's present, it MUST be a multiple of 16 🧮.

ipv6-address(es) (variable length): one or more IPv6 addresses of the encrypted DNS resolver. An address can be a Link-Local address, a ULA, or a GUA 🌐.

All of the addresses share the same Lifetime value. As also discussed in [RFC8106], if you want different Lifetime values per IP address, you can use multiple Encrypted DNS options 💜. The format of this field is shown in Figure 3.

SvcParams Length: a 16-bit unsigned integer giving the length of the "Service Parameters (SvcParams)" field, in octets.

Service Parameters (SvcParams) (variable length): a set of service parameters encoded using the rules in Section 2.2 of [RFC9460]. These can include things like a list of ALPN protocol identifiers or alternate port numbers ✨. This field SHOULD include at least the "alpn" SvcParam. The "alpn" SvcParam may not be required in contexts such as a variant of DNS over CoAP where messages are encrypted using OSCORE. The service parameters MUST NOT include "ipv4hint" or "ipv6hint" SvcParams, because the included IP addresses supersede them 🚫.

If there's no port service parameter, default port numbers should be used 🦋.

Note that the "Addr Length", "ipv6-address(es)", and "Service Parameters (SvcParams)" fields are NOT present if ADN-only mode is used (Section 3.1.6). 🙈

The option MUST be padded with zeros so that the full enclosed data is a multiple of 8 octets (Section 4.6 of [RFC4861]) 🎀.

6.2. IPv6 Host Behavior

Okay so the DNS configuration procedure is the same as it is for any other Neighbor Discovery option [RFC4861] 🫶. On top of that, the host follows the same procedure as Section 5.3.1 of [RFC8106] for processing received Encrypted DNS options 💅. The difference is that the formatting requirements from Section 6.1 and the validation checks from Section 3.1.8 get swapped in for the length and field validations ✨.

The host MUST be prepared to receive multiple Encrypted DNS options in RAs 🎀. These instances MUST be processed following their service priority, i.e., a smaller service priority value indicates a higher preference 👑.

The host MUST silently discard multicast and host loopback addresses conveyed in the Encrypted DNS options 🙈.

7. Security Considerations 🔥

7.1. Spoofing Attacks

Okay, this section is serious, bestie 😭. DHCP and RA messages are NOT encrypted or protected against modification within the LAN 💀. Unless spoofing attacks are mitigated as described below, the content of DHCP and RA messages can be spoofed or modified by active attackers, like compromised devices sitting on the local network 👀. An active attacker (Section 3.3 of [RFC3552]) can spoof the DHCP/RA response to hand out the attacker's own encrypted DNS resolver 😈. Note that this kind of attacker can launch other attacks too, as discussed in Section 22 of [RFC8415] 🚨. The attacker can also get a domain name with a domain-validated public certificate from a Certificate Authority (CA) and host an encrypted DNS resolver 🥀.

Attacks using spoofed or modified DHCP responses and RA messages from attackers within the local network may be mitigated by using the following mechanisms 🛡️:

  • DHCPv6-Shield [RFC7610]: The network access node (e.g., a border router, a CPE, an Access Point (AP)) discards DHCP response messages received from any local endpoint 🚫.
  • RA-Guard [RFC7113]: The network access node discards RA messages received from any local endpoint 🚫.
  • Source Address Validation Improvement (SAVI) solution for DHCP [RFC7513]: The network access node filters packets with forged source IP addresses 🧹.

The above mechanisms would ensure that the endpoint receives the correct configuration information of the encrypted DNS resolvers selected by the DHCP server (or RA sender). BUT these mechanisms cannot provide any information about the DHCP server or the entity hosting the DHCP server (or RA sender) 🫠.

Encrypted DNS sessions with rogue resolvers that spoof the IP address of a DNS resolver will fail, because the DNS client will fail to authenticate that rogue resolver based upon PKIX authentication [RFC6125], particularly the ADN in the Encrypted DNS option 🔐. DNS clients that ignore authentication failures and accept spoofed certificates will be subject to attacks, like attacks that redirect to malicious resolvers or intercept sensitive data 😱.

7.2. Deletion Attacks

If the DHCP responses or RAs are dropped by the attacker, the client can fall back to using a preconfigured encrypted DNS resolver 🌸. However, the use of policies to select resolvers is beyond the scope of this document 🤷‍♀️.

Note that deletion attacks are not specific to DHCP/RA 🙃.

7.3. Passive Attacks

A passive attacker (Section 3.2 of [RFC3552]) can determine that a host is using DHCP/RA to discover an encrypted DNS resolver, and can infer that the host is capable of using DoH/DoT/DoQ to encrypt DNS messages 👀. HOWEVER, a passive attacker cannot spoof or modify DHCP/RA messages 🙌.

7.4. Wireless Security - Authentication Attacks

Wireless LANs (WLANs), which are frequently deployed in local networks (e.g., home networks), are vulnerable to various attacks (e.g., [Evil-Twin], [Krack], [Dragonblood]) 📶💥. Because of these attacks, only cryptographically authenticated communications are trusted on WLANs 🔒. This means that any information (e.g., regarding NTP servers, DNS resolvers, or domain search lists) provided by such networks via 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 to the same WLAN (e.g., Wi-Fi Protected Access Pre-Shared Key (WPA-PSK)), the shared key will be available to all nodes, attackers included 😬. So it is possible to mount an active on-path attack 🕵️. On-path attacks are possible within local networks because this form of WLAN authentication lacks peer entity authentication 💔.

This leads to the need for provisioning unique credentials for different clients 🗝️. Endpoints can be provisioned with unique credentials (username and password, typically) provided by the local network administrator, so they can mutually authenticate to the local WLAN AP (e.g., 802.1x Wireless User Authentication on OpenWrt [dot1x], EAP-pwd [RFC8146] ("EAP" stands for "Extensible Authentication Protocol")) ✨. Not all endpoint devices (e.g., Internet of Things (IoT) devices) support 802.1x supplicants, and they need an alternate mechanism to connect to the local network 🔌. To address this limitation, unique PSKs can be created for each such device, and WPA-PSK is used (e.g., [IPSK]) 🧩.

8. Privacy Considerations 🕊️

Privacy considerations that are also specific to DNR provisioning mechanisms are discussed in Section 23 of [RFC8415] and in [RFC7824] 🌈. Anonymity profiles for DHCP clients are discussed in [RFC7844] 🎭. The mechanisms defined in this document can be used to infer that a DHCP client or IPv6 host supports Encrypted DNS options, BUT these mechanisms do not explicitly reveal whether local DNS clients are able to consume these options, or infer their encryption capabilities 🙈. Other than that, this document does not expose more privacy information compared to Do53 discovery options 💜.

As discussed in [RFC9076], the use of encrypted DNS does not reduce 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 discussion on specific privacy considerations for encrypted DNS 📚.

9. IANA Considerations 📋

9.1. DHCPv6 Option

IANA has assigned the following new DHCPv6 Option Code in the "Option Codes" registry maintained at [DHCPV6] 🎀.

+=======+===============+============+==================+===========+
| Value | Description   | Client ORO | Singleton        | Reference |
|       |               |            | Option           |           |
+=======+===============+============+==================+===========+
| 144   | OPTION_V6_DNR | Yes        | No               | RFC 9463  |
+-------+---------------+------------+------------------+-----------+

                 Table 1: DHCPv6 Encrypted DNS Option

9.2. DHCPv4 Option

IANA has assigned the following new DHCP Option Code in the "BOOTP Vendor Extensions and DHCP Options" registry maintained at [BOOTP] 🦋.

   +=====+===============+=============+============+===========+
   | Tag | Name          | Data Length | Meaning    | Reference |
   +=====+===============+=============+============+===========+
   | 162 | OPTION_V4_DNR | N           | Encrypted  | RFC 9463  |
   |     |               |             | DNS Server |           |
   +-----+---------------+-------------+------------+-----------+

                Table 2: DHCPv4 Encrypted DNS Option

9.3. Neighbor Discovery Option

IANA has assigned the following new IPv6 Neighbor Discovery Option type in the "IPv6 Neighbor Discovery Option Formats" subregistry under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry maintained at [ND] 🧚.

             +======+======================+===========+
             | Type | Description          | Reference |
             +======+======================+===========+
             | 144  | Encrypted DNS Option | RFC 9463  |
             +------+----------------------+-----------+

                Table 3: Neighbor Discovery Encrypted
                              DNS Option

10. References 📚

10.1. Normative References

10.2. Informative References ✨

okay bestie, these are the "go read this if you want the deep dive" sources 📚🫶 everything below is a reference, so every label, title, and link is copied exactly as written

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-Opt]. 🦋

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. The whole review squad is iconic 🌈👑

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

These are the brilliant people who wrote the thing, so here's where to find them 💜

Mohamed Boucadair (editor)
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com


Tirumaleswar Reddy.K (editor)
Nokia
India
Email: kondtir@gmail.com


Dan Wing
Cloud Software Group Holdings, Inc.
United States of America
Email: dwing-ietf@fuggles.com


Neil Cook
Open-Xchange
United Kingdom
Email: neil.cook@noware.co.uk


Tommy Jensen
Microsoft
United States of America
Email: tojens@microsoft.com
📦 where this page comes from