RFC 9462

Discovery of Designated Resolvers

📅 published November 2023, from ietf

Discovery of Designated Resolvers 🎀

Okay bestie, let's talk about RFC 9462 💅✨

Title block (the vibe check): This one is a Standards Track document 🌸 from the IETF, dated November 2023, and its ISSN is 2070-1721. The authors are T. Pauly, E. Kinnear (Apple Inc.), C. A. Wood (Cloudflare), P. McManus (Fastly), and T. Jensen (Microsoft). It doesn't say it obsoletes or updates anything, so it's its own main character 👑

It's officially called "Discovery of Designated Resolvers" (aka DDR) 🦋 and it's all about how DNS clients can use DNS records to find a resolver's encrypted DNS setup 🔐.

Abstract

This document defines Discovery of Designated Resolvers (DDR) 🧚, a whole bundle of mechanisms that let DNS clients use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver found this way is called a "Designated Resolver" 💖. The point is to help you go from unencrypted DNS to encrypted DNS when all you know is the resolver's IP address 🙈. These mechanisms are meant to stay limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are run by the same entity or by entities that cooperate, so nobody's crashing the party 🎉. They can also check whether encrypted DNS protocols are supported when you already know the name of an Encrypted DNS Resolver 🫶.

Status of This Memo

This is an Internet Standards Track document 📜.

It's a product of the Internet Engineering Task Force (IETF) 🌈 and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) ✨. If you want more on Internet Standards, check out Section 2 of RFC 7841 💜.

Info about the current status of this document, any errata, and how to give feedback can be found at https://www.rfc-editor.org/info/rfc9462 🍓.

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved 🔒.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication 📚. Please read these carefully, because they spell out your rights and restrictions for this document 🧾. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License ⚖️.

Table of Contents

  1. Introduction 1.1. Specification of Requirements
  2. Terminology
  3. DNS Service Binding Records
  4. Discovery Using Resolver IP Addresses 4.1. Use of Designated Resolvers 4.1.1. Use of Designated Resolvers across Network Changes 4.2. Verified Discovery 4.3. Opportunistic Discovery
  5. Discovery Using Resolver Names
  6. Deployment Considerations 6.1. Caching Forwarders 6.2. Certificate Management 6.3. Server Name Handling 6.4. Handling Non-DDR Queries for resolver.arpa 6.5. Interaction with Network-Designated Resolvers
  7. Security Considerations
  8. IANA Considerations 8.1. Special-Use Domain Name "resolver.arpa" 8.2. Domain Name Reservation Considerations
  9. References 9.1. Normative References 9.2. Informative References Appendix A. Rationale for Using a Special-Use Domain Name Appendix B. Rationale for Using SVCB Records Authors' Addresses

1. Introduction 🌷

Okay so when DNS clients want to use encrypted DNS protocols like DNS over TLS (DoT) [RFC7858], DNS over QUIC (DoQ) [RFC9250], or DNS over HTTPS (DoH) [RFC8484] 🔐, they might need extra info beyond the DNS server's IP address. Think the resolver's hostname, alternate IP addresses, non-standard ports, or URI Templates 🧩. The problem is that the usual configuration mechanisms only hand over the resolver's IP address during setup 😭. That includes network provisioning protocols like DHCP [RFC2132] [RFC8415] and IPv6 Router Advertisement (RA) options [RFC8106], plus manual configuration 🛠️.

This document defines two ways for clients to discover Designated Resolvers that support these encrypted protocols, using DNS server Service Binding (SVCB) records [RFC9460] 💅:

  1. When all you know is the IP address of an Unencrypted DNS Resolver, the client queries a Special-Use Domain Name (SUDN) [RFC6761] to find the DNS SVCB records tied to one or more Encrypted DNS Resolvers that the Unencrypted DNS Resolver has designated for use when DNS encryption is requested (Section 4) 🦋.
  2. When the hostname of an Encrypted DNS Resolver is known, the client asks for details by sending a query for a DNS SVCB record. This can find alternate encrypted DNS protocols that a known server supports, or fill in details when a network provisions a resolver name (Section 5) 🌈.

Both approaches let clients confirm that a discovered Encrypted DNS Resolver is designated by the resolver that was originally provisioned 🫶. "Designated" here means the resolvers are run by the same entity or cooperating entities. For example, the resolvers are reachable on the same IP address, or there's a certificate that includes the IP address of the original designating resolver 🔍.

1.1. Specification of Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📏.

2. Terminology 📖

This document defines the following terms 💜:

  • DDR: Discovery of Designated Resolvers. "DDR" refers to the mechanisms defined in this document 🦋.
  • Designated Resolver: A resolver, presumably an Encrypted DNS Resolver, that another resolver has designated to stand in for it 💖. This designation can be verified with TLS certificates 🔐.
  • Encrypted DNS Resolver: A DNS resolver using any encrypted DNS transport. That includes current mechanisms like DoH, DoT, and DoQ, plus future ones 🌸.
  • Unencrypted DNS Resolver: A DNS resolver using a transport without encryption, historically TCP or UDP port 53 🙈.

3. DNS Service Binding Records 🎀

DNS resolvers can advertise one or more Designated Resolvers that may offer support over encrypted channels and are controlled by the same entity 🧚.

When a client discovers Designated Resolvers, it learns stuff like the supported protocols and ports 👑. This info comes in ServiceMode SVCB records for DNS servers, though AliasMode SVCB records can point clients to the ServiceMode SVCB record they need, per [RFC9460] ✨. The formatting of these records, including DNS-unique parameters like "dohpath", is defined by [RFC9461] 📜.

Here's an example of an SVCB record describing a DoH server discovered by querying for _dns.example.net:

_dns.example.net.  7200  IN SVCB 1 example.net. (
     alpn=h2 dohpath=/dns-query{?dns} )

Here's an example of an SVCB record describing a DoT server discovered by querying for _dns.example.net:

_dns.example.net.  7200  IN SVCB 1 dot.example.net (
     alpn=dot port=8530 )

And here's one describing a DoQ server discovered by querying for _dns.example.net:

_dns.example.net.  7200  IN SVCB 1 doq.example.net (
     alpn=doq port=8530 )

If there are multiple Designated Resolvers available, using one or more encrypted DNS protocols, the resolver deployment can show a preference using the priority fields in each SVCB record [RFC9460] 🍓.

If the client runs into a mandatory parameter in a SVCB record that it doesn't understand, it MUST NOT use that record to discover a Designated Resolver, following Section 8 of [RFC9460] 🚫. The client can still use other records in the same response as long as it understands all of their mandatory parameters 💅. This lets future encrypted deployments support multiple protocols at once, even if a given client doesn't know about all of them 🫶. For example, say the Unencrypted DNS Resolver returns three SVCB records: one for DoH, one for DoT, and one for a yet-to-exist protocol. A client that only supports DoH and DoT should be able to use those two while safely ignoring the third 🥰.

To avoid name lookup deadlock 🔒, clients that use Designated Resolvers need to make sure that a specific Encrypted DNS Resolver isn't used for any queries needed to resolve the name of the resolver itself, or to do certificate revocation checks for the resolver, as described in Section 10 of [RFC8484] 😤. Designated Resolvers need to make sure this deadlock is avoidable, also as described in Section 10 of [RFC8484] 🙌.

This document focuses on discovering DoH, DoT, and DoQ Designated Resolvers 🌟. Other protocols can use the format defined by [RFC9461] too 💜. But if any such protocol doesn't involve some form of certificate validation, new validation mechanisms will need to be defined to support validating designation, as defined in Section 4.2 🔍.

4. Discovery Using Resolver IP Addresses ✨

okay so, when a DNS client has an Unencrypted DNS Resolver IP address set up, it SHOULD ask that resolver for SVCB records of a service with a scheme of dns and an authority of resolver.arpa before it makes any other queries 🫶. This lets the client switch over to encrypted DNS for everything else, if that's possible. 🔐 Specifically, the client sends a query for _dns.resolver.arpa. with the SVCB resource record type (64) [RFC9460] 💖.

The answers to that SVCB query for the resolver.arpa special-use domain name (SUDN) describe Designated Resolvers 👑. So different Designated Resolver setups can be told apart and matched up with the A and AAAA records for the resolver, ServiceMode SVCB responses to these queries MUST NOT use the . or resolver.arpa value for the TargetName 🙅‍♀️. Also, clients MUST NOT perform A or AAAA queries for resolver.arpa 💅.

here's an example of an SVCB record describing a DoH server found by querying _dns.resolver.arpa. 🌸:

_dns.resolver.arpa.  7200  IN SVCB 1 doh.example.net (
     alpn=h2 dohpath=/dns-query{?dns} )

and here's one for a DoT server found the same way 🦋:

_dns.resolver.arpa.  7200  IN SVCB 1 dot.example.net (
     alpn=dot port=8530 )

and a DoQ server, found via that same query 🧚:

_dns.resolver.arpa.  7200  IN SVCB 1 doq.example.net (
     alpn=doq port=8530 )

If the recursive resolver that gets this query has one or more Designated Resolvers, it will send back the matching SVCB records 🎀. When it answers these special resolver.arpa queries, the recursive resolver SHOULD include the A and AAAA records for the name of the Designated Resolver in the Additional Answers section ✨. This saves the DNS client an extra round trip just to get the address of the Designated Resolver. See Section 5 of [RFC9460] 🍓.

Designated Resolvers SHOULD be reachable over the IP address families that their associated Unencrypted DNS Resolvers support 🌈. If an Unencrypted DNS Resolver can be reached over an IPv4 address, it ought to provide an A record for an IPv4 address of the Designated Resolver. Same deal for IPv6: if it's reachable over an IPv6 address, it ought to provide a AAAA record for an IPv6 address of the Designated Resolver 🫧. The Designated Resolver MAY support more address families than the Unencrypted DNS Resolver, but it SHOULD NOT support fewer 💜. If this isn't done, clients that only have connectivity over one address family might not be able to reach the Designated Resolver at all 😭.

If the recursive resolver that gets this query has no Designated Resolvers, it SHOULD return NODATA for queries to the resolver.arpa zone 🙈. That gives clients a consistent, accurate signal that it doesn't have a Designated Resolver 🫶.

4.1. Use of Designated Resolvers

When a client discovers Designated Resolvers from an Unencrypted DNS Resolver IP address, it can choose to use them either (1) automatically or (2) based on some other policy, heuristic, or user choice 🤔.

This document defines two preferred ways to automatically use Designated Resolvers 💖:

  • Verified Discovery (Section 4.2), for when a TLS certificate can be used to validate the resolver's identity 🔒.
  • Opportunistic Discovery (Section 4.3), for when a resolver's IP address is a private or local address 🏠.

A client MAY additionally use a discovered Designated Resolver without either of these methods, based on implementation-specific policy or user input 🎀. The details of that kind of policy are out of scope for this document 🤷‍♀️. Clients MUST NOT automatically use a Designated Resolver without some sort of validation, like the two methods defined in this document or a future mechanism 🚫. Using one without validation can let an attacker send traffic to an Encrypted DNS Resolver that has nothing to do with the original Unencrypted DNS Resolver, as described in Section 7 😱.

A client MUST NOT reuse a designation discovered through the IP address of one Unencrypted DNS Resolver in place of any other Unencrypted DNS Resolver 🙅‍♀️. Instead, the client needs to repeat the discovery process to find the Designated Resolver of the other Unencrypted DNS Resolver 🔁. In other words, designations are per-resolver and MUST NOT be used to configure the client's universal DNS behavior 💅. This way, queries always go to a party that was designated by the resolver that's actually being used ✨.

4.1.1. Use of Designated Resolvers across Network Changes

If a client is configured with the same Unencrypted DNS Resolver IP address on multiple different networks, a Designated Resolver discovered on one network SHOULD NOT be reused on any of the other networks without repeating the discovery process for each network 🌐. The reason is that the same IP address might belong to different servers on different networks 👀.

4.2. Verified Discovery

Verified Discovery is a mechanism that lets the client automatically use a Designated Resolver that supports DNS encryption and performs a TLS handshake 🔐✨.

To be considered a verified Designated Resolver, the TLS certificate presented by the Designated Resolver has to pass the following checks made by the client 📋:

  1. The client MUST verify the chain of certificates up to a trust anchor, as described in Section 6 of [RFC5280]. The client SHOULD use the default system or application trust anchors, unless otherwise configured 🛡️.
  2. The client MUST verify that the certificate contains the IP address of the designating Unencrypted DNS Resolver in an iPAddress entry of the subjectAltName extension, as described in Section 4.2.1.6 of [RFC5280] 🧐.

If these checks pass, the client SHOULD use the discovered Designated Resolver for any case where it would have used the Unencrypted DNS Resolver otherwise, so it prefers encrypted DNS whenever it can 💜🔥.

If these checks fail, the client MUST NOT automatically use the discovered Designated Resolver if this designation was only discovered via a _dns.resolver.arpa. query. (If the designation was advertised directly by the network, as described in Section 6.5, the server can still be used.) 💀 Also, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted DNS Resolver for as long as the SVCB record's Time to Live (TTL) says, so it doesn't spam queries that just keep failing validation 🙃. The client MAY issue new queries if the SVCB record's TTL is excessively long (as determined by client policy), which keeps the window small for an intermittent attacker trying to block encrypted DNS 🕵️‍♀️.

If the Designated Resolver and the Unencrypted DNS Resolver share an IP address, clients MAY choose to opportunistically use the Designated Resolver even without this certificate check (Section 4.3) 🌸. If the IP address isn't shared, opportunistic use lets attackers redirect queries to an unrelated Encrypted DNS Resolver, as described in Section 7 🚨.

Connections to a Designated Resolver can use a different IP address than the Unencrypted DNS Resolver's, for example if resolving the SVCB service turns up additional addresses 🦋. Even when a different IP address is used for the connection, the TLS certificate checks described in this section still apply to the original IP address of the Unencrypted DNS Resolver 💅.

4.3. Opportunistic Discovery

Sometimes Verified Discovery of encrypted DNS configuration over unencrypted DNS just isn't possible 😔. For example, the identities of Unencrypted DNS Resolvers on private IP addresses [RFC1918], Unique Local Addresses (ULAs) [RFC4193], and Link-Local addresses [RFC3927] [RFC4291] can't be safely confirmed with TLS certificates under most conditions 🏠.

An opportunistic privacy profile is defined for DoT in Section 4.1 of [RFC7858]. In this mode, clients don't validate the name of the resolver presented in the certificate 🫣. This opportunistic privacy profile applies to DoQ [RFC9250] in the same way 🧚. For this profile, Section 4.1 of [RFC7858] explains that clients might or might not validate the resolver. Even if clients choose to do some certificate validation checks, they won't be able to validate the names in the SubjectAltName (SAN) field of the certificate for private and local IP addresses 🙈.

A client MAY use information from the SVCB record for _dns.resolver.arpa. with this opportunistic privacy profile, as long as the IP address of the Encrypted DNS Resolver doesn't differ from the IP address of the Unencrypted DNS Resolver 🎀. Clients SHOULD use this mode only for resolvers using private or local IP addresses, since resolvers using other addresses are able to get TLS certificates provisioned for their addresses 🔥.

5. Discovery Using Resolver Names ✨

okay bestie, so a DNS client that already knows the name of an Encrypted DNS Resolver can use DDR to find out about every encrypted DNS protocol that resolver supports 🔐. This can happen if a client was set up to use a specific Encrypted DNS Resolver, or if a network provisioning protocol (like DHCP or IPv6 RAs) hands over a name alongside the resolver IP address, for example by using Discovery of Network-designated Resolvers (DNR) [RFC9463] 💌.

In those cases the client just sends a DNS SVCB query using the known name of the resolver 🦋. That query can go to the named Encrypted DNS Resolver itself or to any other resolver, so it's giving flexibility. Unlike bootstrapping from an Unencrypted DNS Resolver (Section 4), these records SHOULD be available in the public DNS if the same domain name's A or AAAA records are available in the public DNS, so that any resolver can be used to discover another resolver's Designated Resolvers. When the name can only be resolved in private namespaces, these records SHOULD be available to the same audience as the A and AAAA records.

Here's an example, and it's giving main character energy 👑. If the client already knows about a DoT server resolver.example.com, it can send a SVCB query for _dns.resolver.example.com to see if there are other encrypted DNS protocols available. In the example below, the SVCB answers show that resolver.example.com supports both DoH and DoT, and that the DoH server has a higher priority than the DoT server.

_dns.resolver.example.com.  7200  IN SVCB 1 resolver.example.com. (
     alpn=h2 dohpath=/dns-query{?dns} )
_dns.resolver.example.com.  7200  IN SVCB 2 resolver.example.com. (
     alpn=dot )

Clients MUST validate that for any Encrypted DNS Resolver discovered using a known resolver name, the TLS certificate of the resolver contains the known name in a subjectAltName extension 🔒. In the example above, that means both servers need certificates that cover the name resolver.example.com. Often the various supported encrypted DNS protocols are specified so that the SVCB TargetName matches the known name, which is true in the example above. Even when the TargetName is different (say the DoH server had a TargetName of doh.example.com), clients still check for the original known resolver name in the certificate 🫶.

Note that this resolver validation is not related to the DNS resolver that provided the SVCB answer 🙈.

And here's another one, because it's so relevant 💅. Being able to discover a Designated Resolver for a known Encrypted DNS Resolver is super useful when a client has a DoT configuration for foo.resolver.example.com but is on a network that blocks DoT traffic 😭. The client can still send a query to any other accessible resolver (either the local network resolver or an accessible DoH server) to find out if there's a designated DoH server for foo.resolver.example.com.

6. Deployment Considerations 🧚

Resolver deployments that support DDR are advised to consider the following points 🌸.

6.1. Caching Forwarders

A DNS forwarder SHOULD NOT forward queries for resolver.arpa (or any subdomains) upstream. This stops a client from receiving a SVCB record that will fail to authenticate, because the forwarder's IP address isn't in the SubjectAltName (SAN) field of the upstream resolver's Designated Resolver's TLS certificate 🙅‍♀️. A DNS forwarder that already acts as a completely transparent forwarder MAY choose to forward these queries when the operator expects that this doesn't apply, because the operator either knows the upstream resolver does have the forwarder's IP address in its TLS certificate's SAN field, or expects clients to validate the connection via some future mechanism.

Operators who choose to forward queries for resolver.arpa upstream should note that client behavior is never guaranteed, and that the use of DDR by a resolver does not communicate a requirement for clients to use the SVCB record when it can't be verified 🤷‍♀️.

6.2. Certificate Management

Resolver owners that support Verified Discovery will need to list valid referring IP addresses in their TLS certificates 📜. This may pose challenges for resolvers with a large number of referring IP addresses 🥲.

6.3. Server Name Handling

Clients MUST NOT use resolver.arpa as the server name in either (1) the TLS Server Name Indication (SNI) [RFC8446] for DoT, DoQ, or DoH connections or (2) the URI host for DoH requests 🚫.

When performing discovery using resolver IP addresses, clients MUST use the original IP address of the Unencrypted DNS Resolver as the URI host for DoH requests 💖.

Note that since IP addresses aren't supported by default in the TLS SNI, resolvers that support discovery using IP addresses will need to be configured to present the appropriate TLS certificate when no SNI is present for DoT, DoQ, and DoH 🎀.

6.4. Handling Non-DDR Queries for resolver.arpa

DNS resolvers that support DDR by responding to queries for _dns.resolver.arpa. MUST treat resolver.arpa as a locally served zone per [RFC6303] 🏠. In practice, this means resolvers SHOULD respond to queries of any type other than SVCB for _dns.resolver.arpa. with NODATA, and queries of any type for any domain name under resolver.arpa with NODATA 🧹.

6.5. Interaction with Network-Designated Resolvers

DNR [RFC9463] lets a network provide designation of resolvers directly through DHCP [RFC2132] [RFC8415] and through IPv6 RA options [RFC8106] 📡. When such indications are present, clients can suppress queries for resolver.arpa to the unencrypted DNS server the network indicated over DHCP or RAs, and the DNR indications SHOULD take precedence over those discovered using resolver.arpa for the same resolver if there's a conflict, since DNR is considered a more reliable source 👑.

The Designated Resolver information in DNR might not contain a full set of SvcParams needed to connect to an Encrypted DNS Resolver 🥺. In that case, the client can use a SVCB query using a resolver name, as described in Section 5, to the Authentication Domain Name (ADN) 🔁.

7. Security Considerations 💀🔐

okay bestie, this section is SERIOUS, so pay attention 🙈. Please read every word, because implementers rely on it.

Since clients can receive DNS SVCB answers over unencrypted DNS, on-path attackers can prevent successful discovery by dropping SVCB queries or answers. That means they can stop clients from switching over to encrypted DNS 😱. Clients should be aware that it might not be possible to tell apart resolvers that don't have any Designated Resolver from this kind of active attack. To limit the impact of discovery queries being dropped, whether maliciously or unintentionally, clients can re-send their SVCB queries periodically 🔄.

Section 8.2 of [RFC9461] describes another type of downgrade attack, where an attacker can block connections to the encrypted DNS server 🚧. For DDR, clients need to validate a Designated Resolver using a connection to the server before trusting it. So attackers who can block these connections can stop clients from switching to encrypted DNS 🥀.

Encrypted DNS Resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based solely on metadata in the SVCB record, such as the HTTP path or alternate port number. Those are parameters an attacker could modify 🕵️‍♀️. For example, if a DoH resolver provides a filtering service for one URI path and a non-filtered service for another URI path, an attacker could choose which of those services gets used by modifying the dohpath parameter 😤. These attacks can be mitigated by providing separate resolver IP addresses or hostnames 🛡️.

While the IP address of the Unencrypted DNS Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such as via manual configuration, on a VPN, or on a network with protections like RA-Guard [RFC6105] 🔒. An attacker might try to direct encrypted DNS traffic to itself by causing the client to think that a discovered Designated Resolver uses a different IP address from the Unencrypted DNS Resolver. Such a Designated Resolver might have a valid certificate, but still be operated by an attacker trying to observe or modify user queries without the knowledge of the client or network 👀.

If the IP address of a Designated Resolver differs from that of an Unencrypted DNS Resolver, clients applying Verified Discovery (Section 4.2) MUST validate that the IP address of the Unencrypted DNS Resolver is covered by the SubjectAltName (SAN) of the Designated Resolver's TLS certificate 🧐. If that validation fails, the client MUST NOT automatically use the discovered Designated Resolver 🚨.

Clients using Opportunistic Discovery (Section 4.3) MUST be limited to cases where the Unencrypted DNS Resolver and Designated Resolver have the same IP address, which SHOULD be a private or local IP address 🏡. Clients that don't follow Opportunistic Discovery (Section 4.3), and instead try to connect without first checking for a designation, run the possible risk of being intercepted by an attacker hosting an Encrypted DNS Resolver on the IP address of an Unencrypted DNS Resolver, where the attacker has failed to gain control of the Unencrypted DNS Resolver 😨.

The constraints on the use of Designated Resolvers specified here apply specifically to the automatic discovery mechanisms defined in this document, which are referred to as Verified Discovery and Opportunistic Discovery 📋. Clients MAY use some other mechanism to verify and use Designated Resolvers discovered using the DNS SVCB record 🔍. However, the use of such an alternate mechanism needs to take into account the attack scenarios detailed here ⚠️.

8. IANA Considerations 📚

8.1. Special-Use Domain Name "resolver.arpa"

IANA has registered "resolver.arpa" in the "Special-Use Domain Names" registry established by [RFC6761] 🎉.

IANA has added an entry in the "Transport-Independent Locally-Served DNS Zone Registry" for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain," and listed this document as the reference 🌈.

8.2. Domain Name Reservation Considerations ✨

Okay, bestie, this part is all about how the name reservation works, and the RFC answers the standard questions from Section 5 of [RFC6761] about it. 💅 Let's go one question at a time.

1. Are human users expected to recognize these names as special and use them differently? In what way?

No. 🙈 Client devices' stub resolvers use this name automatically on behalf of users, so users will never actually see it. It's giving background process energy 🧚

2. Are writers of application software expected to make their software recognize these names as special and treat them differently? In what way?

Also no 💀 There's no use case where a non-DNS application (covered by the next question) would need to touch this name. Apps can chill.

3. Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how?

Yes! 👑 DNS client implementors are expected to query this name when they want a resolver's properties, instead of looking up records for the name itself. On the server side, DNS servers are expected to answer queries for this name with their own properties, instead of checking the matching zone the way they would for a normal domain name. Main character energy for this name, honestly. ✨

4. Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?

Yes, and this one is important 🔥 Caching domain name servers should not forward queries for this name, so they don't cause validation failures from an IP address mismatch. Iconic prevention 🫶

5. Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?

No 🌸 DDR is designed for use by recursive resolvers. In theory, an authoritative server could choose to support this name if it wanted to advertise support for encrypted DNS protocols over plaintext DNS, but that scenario is covered by other work in the IETF DNSOP Working Group. Not our lane here, babe 💜

6. Does this reserved Special-Use Domain Name have any potential impact on DNS server operators? If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid? Do DNS server operators need to know about that and understand why? Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware?

Okay, real talk, this one matters 😭 This name is locally served, and any resolver that supports it should never forward the query. DNS server operators should be aware that clients will use records for this name to change how they connect to their resolvers. So if you run a DNS server, you need to know this one, no cap 💖

7. How should DNS Registries/Registrars treat requests to register this reserved domain name? Should such requests be denied? Should such requests be allowed, but only to a specially designated entity?

IANA holds the registration for this name. Non-IANA requests to register it should always be denied by DNS Registries/Registrars. 🎀 Hands off, not yours, babe.

9. References 🦋

9.1. Normative References

Here's the normative reading list. These are the docs the spec actually leans on, so they're kinda required reading 📚

9.2. Informative References

These are the extra-credit reads 🌈 Good for context, not strictly required.

Appendix A. Rationale for Using a Special-Use Domain Name 🎀

The "resolver.arpa" SUDN is kinda like "ipv4only.arpa" 👯 In both, the querying client isn't actually after an answer from the authoritative "arpa" name servers. The whole point of this SUDN is to let clients talk to the Unencrypted DNS Resolver, similar to how "ipv4only.arpa" lets clients talk to a middlebox. If you want the full backstory on "ipv4only.arpa", check out [RFC8880] 📖

Appendix B. Rationale for Using SVCB Records 🧚‍♀️

These mechanisms use SVCB/HTTPS resource records [RFC9460] to say that a given domain designates a particular Designated Resolver that clients should use instead of an Unencrypted DNS Resolver (using a SUDN), or instead of another Encrypted DNS Resolver (using its domain name). 💜

There are other proposals that do something similar, but these mechanisms picked SVCB records for a few good reasons:

  • Discovering Encrypted DNS Resolvers using DNS records keeps client logic for DNS self-contained, and it lets a DNS resolver operator define which resolver names and IP addresses are related to one another.
  • Using DNS records also doesn't rely on bootstrapping with higher-level application operations (such as those discussed in [DoH-HINTS]).
  • SVCB records are extensible and allow the definition of parameter keys, which makes them a superior mechanism for extensibility compared to approaches like overloading TXT records. The same keys can be used for discovering Designated Resolvers of different transport types, as well as those advertised by Unencrypted DNS Resolvers or another Encrypted DNS Resolver.
  • Clients and servers that care about the privacy of names will already need to support SVCB records in order to use the TLS Encrypted ClientHello [ECH]. Without encrypting names in TLS, the value of encrypting DNS is reduced, so pairing the two solutions gives the greatest benefit. 🔒

Authors' Addresses 💌

Tommy Pauly Apple Inc. One Apple Park Way Cupertino, California 95014 United States of America Email: tpauly@apple.com

Eric Kinnear Apple Inc. One Apple Park Way Cupertino, California 95014 United States of America Email: ekinnear@apple.com

Christopher A. Wood Cloudflare 101 Townsend St San Francisco, California 94107 United States of America Email: caw@heapingbits.net

Patrick McManus Fastly Email: mcmanus@ducksong.com

Tommy Jensen Microsoft Email: tojens@microsoft.com

📦 where this page comes from