Domain Name System Operations B. M. Schwartz Internet-Draft Meta Platforms, Inc. Intended status: Standards Track P. Sood Expires: 24 August 2025 Google J. Todd Quad9 20 February 2025 Standardized Query Name for DNS Resolver Reachability Probes draft-sst-dnsop-probe-name-00 Abstract This specification standardizes DNS names that should be used for checking connectivity to a DNS server. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-sst-dnsop-probe-name/. Source for this draft and an issue tracker can be found at https://github.com/bemasc/probe-name. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 August 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Schwartz, et al. Expires 24 August 2025 [Page 1] Internet-Draft DNS Probe Name February 2025 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Client Requirements . . . . . . . . . . . . . . . . . . . . . 4 3.1. Using getaddrinfo . . . . . . . . . . . . . . . . . . . . 4 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6.1. Special Use Domain Name "probe.resolver.arpa" . . . . . . 5 6.2. Domain Name Reservation Considerations . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction In the Domain Name System (DNS, [RFC1034]), 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 [RFC7858], QUIC [RFC9250]) are available. Schwartz, et al. Expires 24 August 2025 [Page 2] Internet-Draft DNS Probe Name February 2025 * 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", [RFC2606]). * 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. Schwartz, et al. Expires 24 August 2025 [Page 3] Internet-Draft DNS Probe Name February 2025 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. 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. 3.1. Using getaddrinfo Clients MAY perform probe queries using a high-level DNS query interface such as getaddrinfo ([RFC3493], Section 6.1). 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 Schwartz, et al. Expires 24 August 2025 [Page 4] Internet-Draft DNS Probe Name February 2025 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. 4. 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 [RFC9462]. 5. 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. 6. IANA Considerations 6.1. 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 [RFC6761]. 6.2. Domain Name Reservation Considerations In accordance with Section 5 of [RFC6761], 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. Schwartz, et al. Expires 24 August 2025 [Page 5] Internet-Draft DNS Probe Name February 2025 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. 7. References 7.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . Schwartz, et al. Expires 24 August 2025 [Page 6] Internet-Draft DNS Probe Name February 2025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, . [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, DOI 10.17487/RFC3493, February 2003, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, . [RFC9462] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. Jensen, "Discovery of Designated Resolvers", RFC 9462, DOI 10.17487/RFC9462, November 2023, . Acknowledgments TODO acknowledge. Authors' Addresses Benjamin M. Schwartz Meta Platforms, Inc. Email: ietf@bemasc.net Schwartz, et al. Expires 24 August 2025 [Page 7] Internet-Draft DNS Probe Name February 2025 Puneet Sood Google Email: puneets@google.com John Todd Quad9 Email: jtodd@quad9.net Schwartz, et al. Expires 24 August 2025 [Page 8]