A Framework for DNS Resolution Latency Measurement
draft-jwang-dnsop-dns-latency-measurement-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | wangjiushuang , Teng Wang , Qi Zhao , Huiyuan Li | ||
| Last updated | 2026-09-09 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jwang-dnsop-dns-latency-measurement-00
DNSOP J. Wang
Internet-Draft T. Wang
Intended status: Informational Q. Zhao
Expires: 13 March 2027 H. Li
China Internet Network Information Center (CNNIC)
9 September 2026
A Framework for DNS Resolution Latency Measurement
draft-jwang-dnsop-dns-latency-measurement-00
Abstract
DNS resolution latency is widely used as an operational metric for
evaluating recursive resolvers, authoritative servers, and DNS
infrastructure. However, current implementations employ different
definitions, measurement scopes, and testing methodologies, making
latency results difficult to compare across deployments.
This document identifies common sources of inconsistency, proposes a
conceptual latency decomposition model, and provides measurement
considerations intended to improve comparability of DNS latency
measurements. This document does not define protocol behavior nor
introduce new protocol mechanisms.
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 13 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang, et al. Expires 13 March 2027 [Page 1]
Internet-Draft DNS Latency Measurement September 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. DNS Resolution Latency . . . . . . . . . . . . . . . . . 5
2.2. Latency Component . . . . . . . . . . . . . . . . . . . . 5
2.3. Measurement Scope . . . . . . . . . . . . . . . . . . . . 5
2.4. Measurement Context . . . . . . . . . . . . . . . . . . . 6
2.5. Measurement Point . . . . . . . . . . . . . . . . . . . . 6
2.6. Observation Interval . . . . . . . . . . . . . . . . . . 6
2.7. Latency Distribution . . . . . . . . . . . . . . . . . . 6
2.8. Measurement Interoperability . . . . . . . . . . . . . . 6
3. Operational Background . . . . . . . . . . . . . . . . . . . 7
3.1. Latency Observation by Recursive Resolvers . . . . . . . 7
3.2. Latency Observation for Authoritative DNS Services . . . 7
3.3. Latency Observation by External Measurement Systems . . . 8
3.4. Operational Observations . . . . . . . . . . . . . . . . 8
4. Current Measurement Challenges . . . . . . . . . . . . . . . 9
4.1. Diverse Measurement Scope . . . . . . . . . . . . . . . . 9
4.2. Diverse Measurement Context . . . . . . . . . . . . . . . 9
4.3. Diverse Measurement Methodologies . . . . . . . . . . . . 10
4.4. Inconsistent Interpretation of Latency Metrics . . . . . 10
4.5. Limited Measurement Interoperability . . . . . . . . . . 10
5. DNS Resolution Latency Framework . . . . . . . . . . . . . . 11
5.1. Design Principles . . . . . . . . . . . . . . . . . . . . 11
5.2. Conceptual Measurement Model . . . . . . . . . . . . . . 12
5.3. Reference Measurement Model . . . . . . . . . . . . . . . 13
5.4. Timing Components . . . . . . . . . . . . . . . . . . . . 14
5.5. Measurement Scope . . . . . . . . . . . . . . . . . . . . 14
5.6. Applying the Framework . . . . . . . . . . . . . . . . . 15
6. Measurement Considerations . . . . . . . . . . . . . . . . . 15
6.1. General Principles . . . . . . . . . . . . . . . . . . . 16
6.2. Selecting the Measurement Scope . . . . . . . . . . . . . 16
6.3. Selecting the Measurement Point . . . . . . . . . . . . . 17
6.4. Identifying Timing Components . . . . . . . . . . . . . . 17
6.5. Describing the Measurement Context . . . . . . . . . . . 17
6.6. Statistical Representation . . . . . . . . . . . . . . . 18
6.7. Measurement Description Template . . . . . . . . . . . . 18
6.7.1. Measurement Description Elements . . . . . . . . . . 18
Wang, et al. Expires 13 March 2027 [Page 2]
Internet-Draft DNS Latency Measurement September 2026
6.7.2. Example Measurement Description . . . . . . . . . . . 20
6.7.3. Reporting Considerations . . . . . . . . . . . . . . 20
6.7.4. Interoperability Considerations . . . . . . . . . . . 21
6.8. Framework Compliance . . . . . . . . . . . . . . . . . . 21
7. Operational Considerations . . . . . . . . . . . . . . . . . 21
7.1. Incremental Deployment . . . . . . . . . . . . . . . . . 22
7.2. Compatibility with Existing Measurement Systems . . . . . 22
7.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 22
7.4. Operational Interoperability . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
The Domain Name System (DNS) is a fundamental component of the
Internet architecture and provides the naming infrastructure upon
which most Internet applications depend. DNS resolution is typically
the first network transaction performed before establishing
application connectivity, and its performance directly influences
application responsiveness, service availability, and user
experience. Consequently, DNS resolution latency has become one of
the primary operational metrics used to evaluate DNS service quality,
optimize infrastructure deployment, and monitor Internet performance.
Latency observations are widely used throughout the DNS ecosystem.
Recursive resolvers continuously monitor the response characteristics
of upstream authoritative servers to guide server selection and
improve resolution efficiency. Authoritative DNS operators evaluate
latency to assess anycast deployments, server placement, and
infrastructure optimization. Internet service providers, content
delivery networks, measurement platforms, and researchers also
collect latency measurements to analyze DNS behavior, evaluate
service quality, and compare operational performance across networks
and geographic regions. As DNS deployments continue to evolve
through large-scale anycast infrastructures, encrypted DNS
transports[RFC7858][RFC8484][RFC9250], and increasingly distributed
resolver architectures, the operational importance of latency
measurement continues to increase.
Although DNS latency is extensively measured, different
implementations frequently observe and interpret latency using
implementation-specific methodologies. Recursive resolvers typically
estimate upstream server performance using locally maintained latency
information, while authoritative server performance is commonly
Wang, et al. Expires 13 March 2027 [Page 3]
Internet-Draft DNS Latency Measurement September 2026
evaluated through active probing or distributed external
measurements. Furthermore, observed latency depends on multiple
operational factors, including cache state, transport protocol, query
type, measurement location, observation interval, and statistical
representation. Consequently, latency measurements collected from
different implementations or measurement platforms often describe
different aspects of DNS behavior and therefore cannot always be
interpreted or compared consistently.
Existing DNS specifications define protocol behavior and describe
various operational practices related to DNS resolution. Some
documents also recognize the importance of latency observations in
resolver operation and infrastructure deployment. However, these
specifications generally do not attempt to establish a common
conceptual framework for DNS latency measurement. In particular,
they do not provide a consistent description of measurement scope,
latency decomposition, measurement context, or reporting
considerations that would facilitate a common interpretation of
latency measurements across different implementations and operational
environments.
The absence of a common measurement framework presents operational
rather than protocol challenges. Without a shared understanding of
what a reported latency value represents, operators may draw
inconsistent conclusions when evaluating resolver implementations,
authoritative infrastructures, deployment strategies, or measurement
results obtained from different platforms. Improving the
comparability and interpretability of DNS latency measurements can
therefore benefit operational analysis, infrastructure optimization,
performance benchmarking, and future measurement standardization
efforts.
This document provides a conceptual framework for DNS resolution
latency measurement. It introduces common terminology for describing
DNS latency, identifies the principal latency components involved in
the DNS resolution process, and discusses operational considerations
that influence latency measurements. The framework is intended to
improve the consistency and comparability of DNS latency measurements
across recursive resolvers, authoritative servers, and external
measurement systems.
This document is informational. It does not define new DNS protocol
behavior, modify existing DNS message formats, or specify
implementation requirements for DNS software. Instead, it
establishes a common conceptual basis for describing DNS latency
measurements and is intended to support future operational guidance,
measurement methodologies, and related standardization activities.
Wang, et al. Expires 13 March 2027 [Page 4]
Internet-Draft DNS Latency Measurement September 2026
2. Terminology
This document uses the terminology defined in [RFC1034], [RFC1035]
and [RFC9499]. This section defines only the additional terminology
introduced by this document.
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.1. DNS Resolution Latency
The elapsed time required to complete a DNS resolution process within
a specified measurement scope. Depending on the observation point,
DNS resolution latency may represent end-to-end client resolution
latency, recursive resolver latency, recursive-to-authoritative
latency, or other latency measurements defined by the measurement
scope.
2.2. Latency Component
A measurable portion of DNS resolution latency associated with a
specific stage of the DNS resolution process. Individual latency
components collectively describe the overall DNS resolution latency
observed within a given measurement scope.
2.3. Measurement Scope
The portion of the DNS resolution process represented by a latency
measurement. A measurement scope defines what part of the resolution
process is included in a reported latency value and therefore
determines how that value should be interpreted.
Examples of measurement scopes include:
* End-to-end DNS resolution
* Client-to-recursive communication
* Recursive resolver processing
* Recursive-to-authoritative communication
Wang, et al. Expires 13 March 2027 [Page 5]
Internet-Draft DNS Latency Measurement September 2026
2.4. Measurement Context
The operational conditions under which latency measurements are
obtained. Measurement context describes factors that may influence
measurement results without changing the definition of the measured
latency.
Examples of measurement context include cache state, transport
protocol, query type, network connectivity, measurement location,
observation interval, and resolver configuration.
2.5. Measurement Point
The logical location at which latency is observed or measured during
the DNS resolution process.
Typical measurement points include clients, recursive resolvers,
authoritative servers, and external measurement systems.
2.6. Observation Interval
The time interval during which latency samples are collected for
operational analysis or statistical reporting.
2.7. Latency Distribution
A statistical representation of a collection of latency observations.
Latency distributions may be summarized using statistical metrics
such as median, percentiles, minimum, maximum, or other statistical
characteristics.
2.8. Measurement Interoperability
The ability to consistently interpret, compare, and analyze DNS
latency measurements obtained from different implementations,
deployments, or measurement systems through the use of common
terminology, measurement scope, and measurement context.
Measurement interoperability does not require different
implementations to produce identical latency values. Rather, it
enables latency measurements to be interpreted consistently despite
differences in implementation or deployment.
Wang, et al. Expires 13 March 2027 [Page 6]
Internet-Draft DNS Latency Measurement September 2026
3. Operational Background
DNS latency measurements are an established part of operational
practice throughout the DNS ecosystem. Rather than serving a single
purpose, latency observations are collected to support different
operational objectives, including resolver optimization,
infrastructure deployment, service monitoring, and performance
evaluation. Consequently, different operational entities observe
latency from different measurement points, under different
measurement contexts, and for different purposes.
Although these measurements are often described using the common term
DNS latency, they frequently represent different portions of the DNS
resolution process. Understanding these operational differences is
essential for interpreting reported latency values and comparing
measurement results across different environments.
3.1. Latency Observation by Recursive Resolvers
Recursive resolvers routinely observe the responsiveness of upstream
authoritative servers during iterative resolution. These
observations contribute to operational decisions such as server
selection, retry behavior, and resolution optimization. Resolver
implementations may derive latency observations from query traffic,
active probing, historical communication, or combinations thereof.
From an operational perspective, latency observations maintained by
recursive resolvers are intended to improve resolution performance
rather than to characterize authoritative server performance.
Consequently, the observed latency reflects the resolver's
operational view of upstream communication under its local operating
conditions.
Because resolver implementations employ different optimization
strategies and operate under different network conditions, latency
observations maintained by different recursive resolvers are not
expected to be identical, even when communicating with the same
authoritative service.
3.2. Latency Observation for Authoritative DNS Services
Operators of authoritative DNS services measure latency to evaluate
infrastructure performance and service quality. Such measurements
are commonly used to assess anycast deployments, server placement,
geographic coverage, traffic engineering strategies, and network
optimization.
Wang, et al. Expires 13 March 2027 [Page 7]
Internet-Draft DNS Latency Measurement September 2026
Unlike recursive resolvers, authoritative service measurements are
typically obtained from external observation points distributed
across multiple networks or geographic locations. The resulting
latency therefore represents the response characteristics of the
authoritative service as observed from specific measurement
environments rather than from within the authoritative infrastructure
itself.
Operational measurements obtained from different observation points
may legitimately differ because they reflect different network paths,
routing conditions, transport characteristics, and client
perspectives.
3.3. Latency Observation by External Measurement Systems
Internet measurement platforms, network operators, and other
operational monitoring systems also collect DNS latency measurements
to evaluate service availability, infrastructure performance, and
long-term operational behavior.
These systems generally observe DNS behavior independently of
resolver implementations and authoritative server operation. Their
measurements therefore provide an external view of DNS performance
from the perspective of measurement probes or end-user networks.
Such observations are valuable for operational monitoring,
benchmarking, troubleshooting, and longitudinal analysis.
Because external measurement systems differ in deployment topology,
observation frequency, measurement methodology, and statistical
processing, measurements obtained from different systems should be
interpreted within their corresponding measurement contexts.
3.4. Operational Observations
Current operational practice demonstrates that DNS latency is not a
single, universally defined quantity. Instead, different operational
entities measure latency to satisfy different operational objectives
and therefore observe different aspects of the DNS resolution
process.
These differences do not indicate inconsistencies in DNS
implementations. Rather, they reflect the diversity of operational
requirements across recursive resolvers, authoritative DNS services,
and external measurement systems. As a result, latency values
reported by different systems cannot be assumed to represent
equivalent performance characteristics without understanding their
associated measurement scope and measurement context.
Wang, et al. Expires 13 March 2027 [Page 8]
Internet-Draft DNS Latency Measurement September 2026
The following sections build upon these operational observations by
introducing a conceptual framework that describes DNS resolution
latency in terms of common latency components, measurement scope, and
measurement context. The framework is intended to improve the
consistency, interpretability, and measurement interoperability of
DNS latency observations across operational environments.
4. Current Measurement Challenges
Current operational practice demonstrates that DNS latency
measurements are widely used across recursive resolvers,
authoritative DNS services, and external measurement systems.
However, these measurements are often collected for different
operational objectives and under different measurement conditions.
Consequently, latency values reported by different implementations or
measurement platforms frequently represent different aspects of DNS
behavior rather than directly comparable performance metrics.
The challenges described in this section do not arise from
deficiencies in existing implementations. Instead, they reflect the
absence of a common conceptual framework for describing what a
latency measurement represents, how it is obtained, and under what
conditions it should be interpreted.
4.1. Diverse Measurement Scope
DNS latency measurements are performed at different points within the
DNS resolution process and therefore represent different measurement
scopes. For example, some measurements describe the end-to-end
latency experienced by a client, while others characterize
communication between recursive resolvers and authoritative servers
or the internal processing performed by recursive resolvers.
Although these measurements are often reported using the same term,
they quantify different portions of the DNS resolution process.
Without an explicit description of measurement scope, latency values
obtained from different systems cannot be assumed to represent
equivalent operational characteristics.
4.2. Diverse Measurement Context
Latency measurements are influenced by the operational context in
which they are obtained. Factors such as cache state, transport
protocol, query type, observation location, network connectivity,
resolver configuration, and observation interval may all affect
measured latency without changing the underlying behavior of the DNS
protocol.
Wang, et al. Expires 13 March 2027 [Page 9]
Internet-Draft DNS Latency Measurement September 2026
Because these factors are not always reported together with latency
values, measurements collected under different operational conditions
may appear inconsistent even though each accurately reflects its
respective measurement environment.
4.3. Diverse Measurement Methodologies
Operational systems employ different methodologies to observe DNS
latency according to their respective objectives. Some measurements
are derived from normal DNS query traffic, while others rely on
active probing or synthetic transactions. Measurement frequency,
sampling strategy, timeout handling, retry behavior, and statistical
processing also differ across implementations and measurement
systems.
These methodological differences are expected and often appropriate
for their intended operational purposes. However, they also make it
difficult to directly compare latency values obtained using different
measurement approaches.
4.4. Inconsistent Interpretation of Latency Metrics
Latency measurements are commonly summarized using statistical
metrics such as averages, medians, percentile values, or other
statistical representations. However, the statistical meaning of
these values depends upon the underlying measurement scope,
measurement context, sampling methodology, and observation interval.
For example, two reported median latency values may not describe
equivalent operational behavior if they were obtained under different
measurement conditions or represent different stages of the DNS
resolution process. Consequently, statistical summaries alone are
insufficient to ensure consistent interpretation of latency
measurements.
4.5. Limited Measurement Interoperability
The challenges described above collectively reduce measurement
interoperability across DNS operational environments. Measurements
obtained from different implementations, deployments, or measurement
systems frequently cannot be interpreted or compared consistently
because they lack a common description of measurement scope, latency
components, measurement context, and measurement methodology.
Wang, et al. Expires 13 March 2027 [Page 10]
Internet-Draft DNS Latency Measurement September 2026
Improving measurement interoperability does not require different
implementations to adopt identical measurement algorithms or produce
identical latency values. Rather, it requires a common conceptual
framework that enables latency measurements to be described,
interpreted, and compared in a consistent manner despite differences
in operational objectives and implementation strategies.
The following section introduces such a framework by decomposing DNS
resolution latency into a set of conceptual latency components and
defining the associated measurement scope and context.
5. DNS Resolution Latency Framework
The previous sections described current operational practices for DNS
latency measurement and identified the challenges associated with
interpreting latency measurements obtained from different operational
environments. These challenges arise because latency values are
frequently reported without a common description of what was
measured, where the measurement was performed, or under which
operational conditions the observation was obtained.
This section introduces a reference framework for describing DNS
resolution latency measurements. Rather than defining a measurement
algorithm or prescribing implementation behavior, the framework
establishes a common semantic model that enables latency measurements
to be described, interpreted, and compared consistently across
different implementations and operational environments.
The framework is based on five complementary measurement attributes:
* Measurement Objective
* Measurement Scope
* Measurement Point
* Latency Components
* Measurement Context
Collectively, these attributes describe the semantic meaning of a DNS
latency measurement and provide the foundation for measurement
interoperability.
5.1. Design Principles
The framework defined in this document is guided by the following
principles.
Wang, et al. Expires 13 March 2027 [Page 11]
Internet-Draft DNS Latency Measurement September 2026
*Implementation Agnostic*
The framework describes DNS latency measurements without assuming any
particular resolver implementation, authoritative server
implementation, transport protocol, or deployment architecture.
*Operational Relevance*
The framework reflects existing operational practices and is intended
to describe latency measurements used for resolver optimization,
infrastructure monitoring, performance evaluation, troubleshooting,
and other operational objectives.
*Measurement Interoperability*
The framework improves the consistent interpretation and comparison
of latency measurements without requiring different implementations
to adopt identical measurement algorithms or produce identical
latency values.
*Protocol Neutrality*
The framework does not modify DNS protocol behavior, define new
protocol elements, or introduce implementation requirements.
Existing DNS protocols and implementations remain unchanged.
5.2. Conceptual Measurement Model
Within this framework, a DNS resolution latency measurement is not
represented solely by an elapsed time value. Instead, its
operational meaning is determined collectively by a set of
measurement attributes.
Figure 1 illustrates the conceptual measurement model.
+--------------------------------------+
| DNS Resolution Latency Measurement |
+--------------------------------------+
|
described by the following measurement attributes
|
+-------------+-------------+-------------+-------------+
| | | | |
v v v v v
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+
|Measurement| |Measurement| |Measurement| | Timing | |Measurement|
| Objective | | Scope | | Point | |Components | | Context |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+
Wang, et al. Expires 13 March 2027 [Page 12]
Internet-Draft DNS Latency Measurement September 2026
Figure 1: Conceptual Measurement Model
A latency measurement cannot be interpreted independently of these
attributes.
Two reported latency values may be numerically similar while
representing different operational characteristics if they differ in
measurement scope, timing components, or measurement context.
Conversely, measurements obtained by different implementations may
remain operationally comparable when these attributes are
consistently described.
5.3. Reference Measurement Model
The framework models DNS resolution as a sequence of communication
and processing events between DNS entities.
Figure 2 illustrates the reference measurement model.
Client Recursive Resolver Authoritative Server
| | |
|------ DNS Query ------>| |
| | |
| |=== Local Processing =====|
| | |
| |------ DNS Query -------->|
| | |
| |<----- DNS Response ------|
| | |
|<----- DNS Response ----| |
| |
Figure 2: Reference Measurement Model
The reference measurement model is intentionally independent of
implementation details.
Operations such as cache lookup[RFC8767], recursive iteration, DNSSEC
validation, encrypted transport establishment, retry processing, or
policy evaluation are represented as processing activities within the
appropriate measurement entity and do not alter the conceptual
structure of the model.
Different latency measurements correspond to different observable
portions of the reference measurement model.
Wang, et al. Expires 13 March 2027 [Page 13]
Internet-Draft DNS Latency Measurement September 2026
5.4. Timing Components
Within the reference measurement model, DNS resolution latency is
described using three conceptual timing components.
*TC1: Client–Recursive Communication*
The elapsed time associated with communication between the client and
the recursive resolver.
*TC2: Recursive Resolver Processing*
The elapsed time during which the recursive resolver processes a DNS
query. Depending on implementation and operational conditions, this
component may include cache processing, recursive resolution, policy
evaluation, DNSSEC validation, response construction, and other
internal processing activities.
*TC3: Recursive–Authoritative Interaction*
The elapsed time associated with communication between the recursive
resolver and one or more authoritative servers, including
authoritative server processing and response delivery. Communication
may employ TCP transport as defined in [RFC7766], and may include
EDNS Client Subnet processing per [RFC7871].
These timing components are conceptual descriptions rather than
protocol events or implementation stages. Individual implementations
MAY realize these activities differently while remaining consistent
with the framework.
5.5. Measurement Scope
A measurement scope specifies which timing components are represented
by a reported latency value.
Different operational objectives require different measurement
scopes. Consequently, latency measurements are not expected to
include identical timing components.
Representative examples include:
Wang, et al. Expires 13 March 2027 [Page 14]
Internet-Draft DNS Latency Measurement September 2026
+====================================+============================+
| Measurement Scope | Included Timing Components |
+====================================+============================+
| End-to-end DNS resolution | TC1 + TC2 + TC3 |
+------------------------------------+----------------------------+
| Recursive resolver processing | TC2 |
+------------------------------------+----------------------------+
| Recursive-to-authoritative latency | TC3 |
+------------------------------------+----------------------------+
| Client-to-recursive latency | TC1 |
+------------------------------------+----------------------------+
Table 1: Measurement Scope Examples
The framework does not prescribe which measurement scope should be
used by an implementation. Instead, it provides a common vocabulary
for describing the scope associated with reported latency
measurements.
5.6. Applying the Framework
The framework introduced in this document is intended to improve the
semantic consistency of DNS latency measurements rather than
standardize measurement procedures.
Implementations and operational measurement systems may continue to
employ measurement methodologies appropriate to their operational
objectives. However, the interpretability and comparability of
latency measurements can be significantly improved when the
associated measurement objective, measurement scope, measurement
point, timing components, and measurement context are explicitly
described.
The framework therefore enables latency measurements obtained from
different implementations, deployments, and operational environments
to be interpreted within a common conceptual model while preserving
implementation flexibility.
The following section discusses operational considerations that
influence DNS latency measurements and provides guidance on applying
this framework in practice.
6. Measurement Considerations
The framework defined in Section 5 provides a common semantic
description for DNS resolution latency measurements. This section
discusses considerations for applying that framework in operational
environments.
Wang, et al. Expires 13 March 2027 [Page 15]
Internet-Draft DNS Latency Measurement September 2026
These considerations are intended to improve the interpretability and
comparability of latency measurements. They do not prescribe
measurement algorithms, implementation behavior, or reporting
requirements.
Different implementations remain free to employ measurement
methodologies appropriate to their operational objectives.
6.1. General Principles
When describing DNS latency measurements, implementations and
operational measurement systems should associate reported latency
values with the measurement attributes defined in Section 5.
A latency value, by itself, does not fully characterize DNS
performance. Its interpretation depends on the corresponding
measurement scope, measurement point, timing components, and
measurement context.
Accordingly, latency measurements should be interpreted as
descriptions of specific operational observations rather than
universal performance indicators.
6.2. Selecting the Measurement Scope
Measurement scope determines which portion of the DNS resolution
process is represented by a latency measurement.
The selected scope should correspond to the operational objective of
the measurement.
For example,
* resolver optimization may focus on recursive-to-authoritative
communication;
* client experience evaluation may require end-to-end DNS resolution
latency;
* infrastructure benchmarking may focus on authoritative service
responsiveness.
Different measurement scopes are intended to answer different
operational questions.
Consequently, latency values obtained under different scopes should
not be directly compared without considering their respective
measurement objectives.
Wang, et al. Expires 13 March 2027 [Page 16]
Internet-Draft DNS Latency Measurement September 2026
6.3. Selecting the Measurement Point
The location at which latency is observed influences the
interpretation of measurement results.
Measurements obtained by clients, recursive resolvers, authoritative
servers, and external measurement systems each provide different
operational perspectives.
Accordingly, the measurement point should be explicitly identified
whenever latency measurements are reported or exchanged.
Different observation points are not expected to produce identical
latency values, even when evaluating the same DNS service.
6.4. Identifying Timing Components
Latency measurements should identify the timing components included
within the reported latency value.
For example, an end-to-end latency measurement generally includes
client communication, recursive resolver processing, and recursive-
to-authoritative interaction, whereas resolver processing latency
excludes communication outside the recursive resolver.
Describing timing components improves the semantic clarity of latency
measurements and reduces ambiguity when comparing measurements
collected under different operational conditions.
6.5. Describing the Measurement Context
Measurement context represents the operational conditions under which
latency observations are obtained.
Relevant contextual information may include, but is not limited to,
* cache state;
* transport protocol;
* query type;
* network connectivity;
* observation location;
* observation interval;
Wang, et al. Expires 13 March 2027 [Page 17]
Internet-Draft DNS Latency Measurement September 2026
* resolver configuration;
* deployment architecture.
The framework does not require all contextual information to be
reported.
However, implementations are encouraged to describe operational
conditions that materially influence the interpretation of reported
latency values. Diagnostic context may also include extended DNS
error information [RFC8914].
6.6. Statistical Representation
DNS latency measurements are typically derived from multiple
observations rather than individual queries.
Accordingly, latency measurements are commonly represented using
statistical summaries such as percentile values, median latency,
minimum latency, maximum latency, or other statistical
characteristics.
When reporting statistical summaries, implementations should ensure
that the associated observation interval and measurement scope are
clearly described.
Statistical values obtained under different sampling methodologies or
observation intervals should not be interpreted as directly
comparable unless their measurement context is also understood.
6.7. Measurement Description Template
The framework defined in this document is intended to improve the
semantic consistency and interoperability of DNS latency
measurements. To facilitate consistent reporting and interpretation,
this section defines a reusable measurement description template.
The template does not prescribe a reporting format or serialization
mechanism. Instead, it identifies the conceptual information that
SHOULD accompany reported DNS latency measurements to enable
consistent interpretation across operational environments.
A measurement description consists of the elements described below.
6.7.1. Measurement Description Elements
A DNS latency measurement SHOULD be accompanied by the information
summarized in Table 2.
Wang, et al. Expires 13 March 2027 [Page 18]
Internet-Draft DNS Latency Measurement September 2026
+================+=========================+=====================+
| Element | Description | Example |
+================+=========================+=====================+
| Measurement | Optional identifier for | Resolver-RTT-2026Q1 |
| Identifier | the measurement | |
| | instance or dataset. | |
+----------------+-------------------------+---------------------+
| Measurement | Operational purpose of | Resolver |
| Objective | the measurement. | optimization |
+----------------+-------------------------+---------------------+
| Measurement | Portion of the DNS | End-to-End |
| Scope | resolution process | Resolution |
| | represented by the | |
| | reported latency. | |
+----------------+-------------------------+---------------------+
| Measurement | Location where the | Recursive Resolver |
| Point | latency observation was | |
| | obtained. | |
+----------------+-------------------------+---------------------+
| Timing | Timing components | TC2 + TC3 |
| Components | included in the | |
| | reported latency. | |
+----------------+-------------------------+---------------------+
| Measurement | Operational conditions | Cache miss, DoQ, |
| Context | that influence | IPv6 |
| | interpretation. | |
+----------------+-------------------------+---------------------+
| Observation | Time period over which | 2026-01-01 to |
| Interval | observations were | 2026-03-31 |
| | collected. | |
+----------------+-------------------------+---------------------+
| Sampling | Method used to obtain | Passive Observation |
| Method | observations. | |
+----------------+-------------------------+---------------------+
| Statistical | Statistical summary of | Median, P95 |
| Representation | reported latency | |
| | values. | |
+----------------+-------------------------+---------------------+
| Measurement | Optional | DNSSEC validation |
| Notes | implementation-specific | enabled |
| | information relevant to | |
| | interpretation. | |
+----------------+-------------------------+---------------------+
Table 2: Measurement Description Template
The elements above collectively describe the semantic meaning of a
reported latency measurement.
Wang, et al. Expires 13 March 2027 [Page 19]
Internet-Draft DNS Latency Measurement September 2026
Not all elements are required for every operational use case.
However, omitting relevant descriptive information may reduce the
interpretability and comparability of reported latency values.
6.7.2. Example Measurement Description
The following example illustrates the application of the measurement
description template.
Measurement Identifier: Resolver-Performance-2026Q1
Measurement Objective: Recursive Resolver Optimization
Measurement Scope: Recursive-to-Authoritative Latency
Measurement Point: Recursive Resolver
Timing Components: TC3
Measurement Context: Cache Miss, DNS over QUIC, IPv6,
Anycast Authoritative Service
Observation Interval: 2026-01-01 - 2026-03-31
Sampling Method: Passive Observation
Statistical Representation: Median = 14.2 ms, P95 = 27.6 ms
Measurement Notes: DNSSEC validation enabled.
Figure 3: Example Measurement Description
The example is illustrative only.
Implementations MAY report additional information according to their
operational requirements.
6.7.3. Reporting Considerations
Different operational environments require different levels of
reporting detail.
For example,
* operational monitoring systems may report only a subset of the
measurement description elements;
* benchmarking studies may provide a more complete description of
measurement methodology and context;
* research publications may include additional statistical analyses
or implementation details.
The framework does not require all measurement reports to include
identical descriptive information.
Wang, et al. Expires 13 March 2027 [Page 20]
Internet-Draft DNS Latency Measurement September 2026
Instead, implementations are encouraged to include sufficient
measurement attributes to enable consistent interpretation by other
operators, researchers, and measurement systems.
6.7.4. Interoperability Considerations
The measurement description template improves interoperability by
separating the semantic description of a latency measurement from the
methodology used to obtain it.
Consequently,
* implementations employing different measurement algorithms can
produce semantically comparable measurement reports;
* operational systems can exchange latency observations without
requiring identical implementation strategies;
* future measurement methodologies can be incorporated without
modifying the framework itself.
The template therefore provides a stable conceptual description that
is independent of protocol evolution, deployment architecture, and
implementation-specific optimization.
6.8. Framework Compliance
An implementation conforms to this framework by describing DNS
latency measurements using the measurement attributes defined in
Section 5.
Conformance to the framework does not require implementations to
modify measurement algorithms, change protocol behavior, or adopt
common implementation strategies.
Instead, the framework promotes interoperability by establishing a
common semantic description for DNS latency measurements across
diverse operational environments.
7. Operational Considerations
The framework defined in this document is intended to improve the
semantic consistency of DNS latency measurements while preserving
implementation flexibility. Operational deployment of the framework
does not require modifications to existing DNS protocols, resolver
implementations, or authoritative server behavior.
Wang, et al. Expires 13 March 2027 [Page 21]
Internet-Draft DNS Latency Measurement September 2026
Instead, operators and measurement systems are encouraged to
associate reported latency measurements with the measurement
attributes defined in Section 5 and the reporting template described
in Section 6. Such descriptions improve the interpretability of
latency observations across operational environments without
constraining implementation-specific measurement methodologies.
7.1. Incremental Deployment
The framework is designed for incremental adoption.
Existing measurement systems MAY incorporate individual measurement
attributes or reporting elements without requiring complete
implementation of the framework. For example, an operational
monitoring platform may initially report measurement scope and
observation context while continuing to employ its existing
measurement algorithms.
Incremental adoption allows the framework to improve measurement
interoperability without disrupting existing operational practices.
7.2. Compatibility with Existing Measurement Systems
The framework is compatible with existing DNS operational measurement
systems.
Because the framework provides a conceptual description rather than a
measurement procedure, implementations MAY continue to employ passive
observation, active probing, synthetic transactions, resolver
statistics, or other operational measurement techniques.
The framework neither requires nor discourages any particular
measurement methodology.
Instead, it enables measurements obtained using different
methodologies to be described using a common semantic model.
7.3. Extensibility
The framework intentionally separates measurement semantics from
implementation behavior.
Wang, et al. Expires 13 March 2027 [Page 22]
Internet-Draft DNS Latency Measurement September 2026
Consequently, future protocol developments—including new DNS
transport protocols, resolver optimization techniques, caching
strategies, encrypted DNS mechanisms, or authoritative service
architectures—can be accommodated by extending the associated
measurement context or timing component descriptions without
modifying the framework itself.Related operational guidance can be
found in [RFC9471] and [RFC9606].
This extensibility is intended to support long-term operational
evolution of the DNS ecosystem.
7.4. Operational Interoperability
Operational interoperability does not imply that different
implementations produce identical latency values.
Instead, interoperability is achieved when latency measurements
produced by different implementations can be interpreted consistently
because they are accompanied by a common semantic description.
Accordingly, interoperability depends upon the completeness of the
accompanying measurement description rather than similarity of the
reported latency values.
8. Security Considerations
This document introduces a conceptual framework for describing DNS
resolution latency measurements.
It does not define new DNS protocol mechanisms, modify existing
protocol behavior, introduce new message formats, or specify
measurement algorithms.
Accordingly, this document does not introduce new protocol-level
security vulnerabilities.
However, inaccurate or incomplete descriptions of latency
measurements may lead to incorrect operational interpretation.
For example, latency values reported without sufficient measurement
scope, measurement context, or timing component descriptions may be
incorrectly compared across different operational environments,
potentially resulting in inappropriate operational decisions.
Similarly, latency measurements obtained under substantially
different operational conditions SHOULD NOT be interpreted as
representing equivalent DNS performance solely because they report
similar numerical values.
Wang, et al. Expires 13 March 2027 [Page 23]
Internet-Draft DNS Latency Measurement September 2026
Implementations applying the framework SHOULD ensure that reported
latency measurements are accompanied by sufficient descriptive
information to support correct interpretation as described in
Section 6.
The framework itself neither increases nor decreases the security
properties of DNS protocols, including DNSSEC, DNS over TLS
(DoT)[RFC7858], DNS over HTTPS (DoH)[RFC8484], DNS over QUIC
(DoQ)[RFC9250], or other protocol extensions.
9. IANA Considerations
This document has no IANA actions.
10. References
10.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/rfc/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
10.2. Informative References
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<https://www.rfc-editor.org/rfc/rfc7766>.
[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, <https://www.rfc-editor.org/rfc/rfc7858>.
Wang, et al. Expires 13 March 2027 [Page 24]
Internet-Draft DNS Latency Measurement September 2026
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016,
<https://www.rfc-editor.org/rfc/rfc7871>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/rfc/rfc8484>.
[RFC8767] Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data
to Improve DNS Resiliency", RFC 8767,
DOI 10.17487/RFC8767, March 2020,
<https://www.rfc-editor.org/rfc/rfc8767>.
[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020,
<https://www.rfc-editor.org/rfc/rfc8914>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/rfc/rfc9250>.
[RFC9471] Andrews, M., Huque, S., Wouters, P., and D. Wessels, "DNS
Glue Requirements in Referral Responses", RFC 9471,
DOI 10.17487/RFC9471, September 2023,
<https://www.rfc-editor.org/rfc/rfc9471>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/rfc/rfc9499>.
[RFC9606] Reddy.K, T. and M. Boucadair, "DNS Resolver Information",
RFC 9606, DOI 10.17487/RFC9606, June 2024,
<https://www.rfc-editor.org/rfc/rfc9606>.
Authors' Addresses
Jiushuang Wang
China Internet Network Information Center (CNNIC)
Email: wangjiushuang@cnnic.cn
Teng Wang
China Internet Network Information Center (CNNIC)
Email: wangteng@cnnic.cn
Wang, et al. Expires 13 March 2027 [Page 25]
Internet-Draft DNS Latency Measurement September 2026
Qi Zhao
China Internet Network Information Center (CNNIC)
Email: zhaoqi@cnnic.cn
Huiyuan Li
China Internet Network Information Center (CNNIC)
Email: lihuiyuan@cnnic.cn
Wang, et al. Expires 13 March 2027 [Page 26]