If you assume that "DNS latency" is defined as the elapsed time between passing a query to a DNS resolver and receiving its response, and the "DNS latency" will vary dramatically depending on the state of the cache in the resolver(s) that are involved in processing the query, the query options (DNSSEC Enabled), the configuration of the queried name (Glue / no Glue records), the presence of a truncation flag in a UDP response, and so on. the number of zone cuts in the name, DNSSEC validation, and so on.
This makes the measurement of "DNS latency" to be so extremely variable that the concept becomes somewhat meaningless, particularly when you might want to use such measurements as a comparator. regards, Geoff > On 29 Jan 2026, at 12:32 pm, Cathy Zhang <[email protected]> wrote: > > Hi Warren, > > Thank you so much for your reply and for listing so many reference RFCs. > This is really thoughtful of you, and I will read through each one carefully. > > Right now, I’m only looking to clarify the definition of latency, and haven’t > yet gotten to the question of what a reasonable latency threshold should be. > > The descriptions I’ve been able to find go something like this: > Query Latency is the time elapsed between sending a DNS request and receiving > the response. > > Is it acceptable to use RTT to denote latency? > The description in the BIND9 ARM is quite brief: "the time taken to respond > to the query". > In the source code, the timing logic seems to be the time when the response > packet is received (before parsing the response packet) minus the time when > the request packet is sent. > > From my understanding, DNS latency should include the transmission time of > the request packet, the time the server takes to process the query request, > and the transmission time of the response packet. > > I’m not looking for a formal, standardized definition, simply a detailed > descriptive explanation will suffice. > Naturally, this latency value varies significantly between TCP and UDP, and > the definition for UDP is likely more straightforward. > > regards, > Cathy > > > > > > At 2026-01-29 00:31:25, "Warren Kumari" <[email protected]> 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 <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] > <mailto:[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 to [email protected]
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
