I don’t believe DNS RFCs are the right place to look for answers about
latency. RFCs mainly describe correctness and behavior, not performance
guarantees. Latency tends to be treated as an operational outcome rather
than something the protocol tries to define.
From practical experience, DNS latency depends heavily on context:
whether you’re talking about recursive or authoritative service, current
cache state (cold vs warm caches), upstream behavior, SERVFAIL
conditions, EDNS buffer sizes versus path MTU, TCP fallback, and so on.
All of these can vary widely and are outside the scope of what an RFC
could reasonably standardize.
Because of that, latency is usually discussed in terms of operational
best practices and measurement studies, not as a protocol parameter with
defined bounds.
Carlos Horowicz
Planisys
On 28/01/2026 17:31, Warren Kumari wrote:
Depends what you mean by "defining DNS query/response latency".
If you are meaning "The latency from a stub to a recursive MUST be
less than 100ms. The latency from a recursive to an auth MUST be less
then 123.4ms", then no, I don't think that there is anything like that
(modulo timeouts and similar).
There are, however, many RFCs about the desire to minimize latency,
including things like:
RFC9824 - "Compact Denial of Existence in DNSSEC"
<https://datatracker.ietf.org/doc/rfc9824/> - saves small bits of time
by not having to fetch from a DB style setup.
RFC9715 - "IP Fragmentation Avoidance in DNS over UDP"
<https://datatracker.ietf.org/doc/rfc9715/> - by not failing over to
TCP, you can save quite a few RTT.
RFC9520 - "Negative Caching of DNS Resolution Failures"
<https://datatracker.ietf.org/doc/rfc9520/> - if you cache
non-response answers you can immediately return these to clients.
RFC9276 - "Guidance for NSEC3 Parameter Settings"
<https://datatracker.ietf.org/doc/rfc9276/> - a bit of a stretch, but
not doing iterations saves, um, many microseconds.
RFC9210 - "DNS Transport over TCP - Operational Requirements"
<https://datatracker.ietf.org/doc/rfc9210/> - if you *do* have to fail
over to TCP, making sure it actually works means clients get an
answer, and don't just hang.
RFC9156 - "DNS Query Name Minimisation to Improve Privacy"
<https://datatracker.ietf.org/doc/rfc9156/> - trades some latency to
improve privacy
RFC8906 - "A Common Operational Problem in DNS Servers: Failure to
Communicate" <https://datatracker.ietf.org/doc/rfc8906/> - if you
don't answer, or answer incorrectly, some queries take much longer.
RFC8806 - "Running a Root Server Local to a Resolver"
<https://datatracker.ietf.org/doc/rfc8806/> - byhaving zones locally
you don't need to do a lookup.
RFC8198 - "Aggressive Use of DNSSEC-Validated Cache"
<https://datatracker.ietf.org/doc/rfc8198/> - if you know (through e.g
NSEC) that a name doesn't exist, you can immediately send back a
negative answer.
RFC8020 - "NXDOMAIN: There Really Is Nothing Underneath"
<https://datatracker.ietf.org/doc/rfc8020/> - same. If you get an NXD
for foo.example, you know that bar.foo.example
<http://bar.foo.example/> doesn't exist
RFC7706 - "Decreasing Access Time to Root Servers by Running One on
Loopback" <https://datatracker.ietf.org/doc/rfc7706/> - same as RFC8806.
RFC4472 - "Operational Considerations and Issues with IPv6 DNS"
<https://datatracker.ietf.org/doc/rfc4472/>, RFC3901 - "DNS IPv6
Transport Operational Guidelines"
<https://datatracker.ietf.org/doc/rfc3901/> - Make DNS fast by making
sure IPv6 works too….
RFC3258 - "Distributing Authoritative Name Servers via Shared Unicast
Addresses" <https://datatracker.ietf.org/doc/rfc3258/> - A big one.
Any cast FTW!
W
On Mon, Jan 26, 2026 at 11:19 PM, Cathy Zhang <[email protected]> wrote:
Hello everyone,
Are there any RFCs or drafts defining DNS query/response latency?
Regards,
Cathy
_______________________________________________
DNSOP mailing list -- [email protected] <mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
DNSOP mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
