| Internet-Draft | DNS Probe Name | February 2025 |
| Schwartz, et al. | Expires 24 August 2025 | [Page] |
This specification standardizes DNS names that should be used for checking connectivity to a DNS server.¶
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.¶
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 (c) 2025 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) 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.¶
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.¶
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¶
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.¶
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.¶
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.¶
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¶
Clients SHOULD interpret the getaddrinfo return value as follows:¶
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].¶
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.¶
This document calls for the addition of "probe.resolver.arpa" to the Special-Use Domain Names (SUDN) registry established by [RFC6761].¶
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.¶
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.¶
TODO acknowledge.¶