]> Meta Platforms, Inc.

ietf@bemasc.net

Google

puneets@google.com

Quad9

jtodd@quad9.net

Domain Name System Operations This specification standardizes DNS names that should be used for checking connectivity to a DNS server. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction In the Domain Name System (DNS, ), clients normally send queries to a recursive resolver in order to receive the resolution results. However, some clients also send queries merely to check that a response is received at all. We call these queries "DNS probes". DNS probes are used for many reasons:

• To determine if the network is working at all.
• To detect if a particular address family is connected to the global internet.
• To check that the client is able to reach the resolver's IP address.
• To assess the reliability and performance of the network path between the client and the resolver.
• To establish which transport protocols (e.g., UDP, TCP, TLS , QUIC ) are available.
• To confirm that the DNS resolver itself is operational.

When sending a DNS query, the client must choose a QNAME. Popular QNAME values for probes include:

• Names owned by the entity performing the probe.
• Names used by prominent, high-reliability internet services.
• Names operated at the direction of prominent internet organizations such as the IETF (e.g., "example.com", ).
• Names that form an essential part of the internet infrastructure.

These choices are pragmatic, but they also present a number of downsides for the client:

• The response could be delayed if the selected name is not in cache.
• The probe will return unneeded RDATA, wasting bandwidth.
• Depending on the success criteria, the probe could report a spurious failure
  • if the selected name is removed, or experiences an outage.
  • if the resolver experiences an interruption on its outbound link.
• A distinctive QNAME could enable unwanted fingerprinting of the client by the resolver or a network adversary.

These popular types of QNAME also present some downsides for the resolver operator:

• The probe may cause the resolver to do more work than necessary, especially when the selected name is not in cache.
• The operator cannot distinguish probe queries from ordinary queries, limiting their understanding of how their service is being used.

This specification registers a Special-Use Domain Name for DNS probing to avoid these downsides.

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

Client Requirements Clients SHOULD set the QNAME on probe queries to "probe.resolver.arpa.". Clients SHOULD set the QTYPE to A or AAAA. Clients that use other QTYPEs are at a higher risk of implementation fingerprinting due to the distinctive QTYPE. Clients SHOULD NOT set the "DNSSEC OK" flag. Setting this bit causes more work for the resolver, but does not provide any benefit to the client. Clients SHOULD avoid any stub caching, as this would cause probe results to be out of date. Clients MAY set the "Recursion Desired" flag to either value. Setting this flag to 0 reduces load on resolvers that do not implement this specification.

Using getaddrinfo Clients MAY perform probe queries using a high-level DNS query interface such as getaddrinfo (). Note that implementations of getaddrinfo and similar interfaces often employ a stub cache, resulting in probe results that may not be fresh. These implementations typically retry queries across several servers until one responds successfully, so the result may not be attributable to a specific resolver and cannot be used to assess the network's latency or packet loss rate. Clients that use getaddrinfo for probes SHOULD call it with the following input parameters:

• nodename = "probe.resolver.arpa."
• servname = null
• hints = null or all zeros except for .ai_family

Clients SHOULD interpret the getaddrinfo return value as follows:

• EAI_NONAME: The probe has succeeded.
• EAI_AGAIN: The probe has failed.
• 0: The resolver is misconfigured (returning addresses where there should be none).
• Any other error: The client system is misconfigured.

Server Requirements Upon receiving a query with a QNAME of "probe.resolver.arpa.", DNS servers MUST return a valid NXDOMAIN response from the "resolver.arpa." locally-served zone .

Security Considerations If a resolver operator applies rate limits to queries, it SHOULD NOT exclude "probe.resolver.arpa" from such limits. Queries for this name could still be used as part of a high query rate attack.

IANA Considerations

Special Use Domain Name "probe.resolver.arpa" This document calls for the addition of "probe.resolver.arpa" to the Special-Use Domain Names (SUDN) registry established by .

Domain Name Reservation Considerations In accordance with , the answers to the following questions are provided for this document: 1) Are human users expected to recognize these names as special and use them differently? In what way? No. This name is principally intended to be useful to resolver operators, and should never be seen by ordinary users. 2) Are writers of application software expected to make their software recognize these names as special and treat them differently? In what way? Yes. Writers of DNS resolver monitoring software are expected to categorize queries for this name as distinct from ordinary user-generated queries. 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? No. Stub resolvers process this name in the ordinary fashion. 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? No. This name is subject to ordinary caching logic. 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. Queries for this name are not intended to reach authoritative domain name servers. 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? This name has no special impact on DNS server operators beyond those already implied by the status of "resolver.arpa." as a Locally Served Zone. 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? This name is inside an existing Locally Served Zone ("resolver.arpa."), so the question of registration requests is moot.

References Normative References This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names. Informative References This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This memo provides information for the Internet community. This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver". These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNS Resolver is known.

Acknowledgments TODO acknowledge.