Carlos, et al, FWIW, I have always thought it's a weakness in the definition of protocols that performance is not addressed. As a general matter, most Internet protocols have been designed to work with quite a bit of tolerance regarding timing. That said, the tolerances are clearly not infinite.
With regard to DNS, latency and coherence are (two of) the relevant metrics. I strongly believe and would advocate that these be included in the consideration of the definition, design, implementation and operation of the protocols. Steve Crocker On Wed, Jan 28, 2026 at 12:16 PM Carlos Horowicz <carlos= [email protected]> wrote: > 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/> - by having 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 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] >> To unsubscribe send an email to [email protected] >> > > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Sent by a Verified sender
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
