Hi Geoff,
Thanks for your reply. It seems that people care more about whether this metric holds practical value, which is why there’s greater focus on its influencing factors. My original intention was to send queries to authoritative servers from a specific monitoring point to measure the latency. I’ve found that the actual latency variance is fairly minimal—ranging from a few milliseconds to a few hundred milliseconds. If this only affects a recursive server’s first cache-miss query, it really has little practical impact. It was during this process that I realized there seems to be no clear definition of latency. I’d just roughly run a dig or ping test to check it. That’s why I wanted to find out if there are any commonly accepted descriptions of it. It appears that in practice, the focus is on reducing this latency by means such as lowering network delay and minimizing packet size, etc. However, maybe a precise definition of this latency is neither that critical nor necessary, and it’s also highly susceptible to various factors, so there’s no need to define it explicitly. Thank you again for your reply. regards, Cathy At 2026-01-29 10:22:35, "Geoff Huston" <[email protected]> wrote: 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, manyRFCs about the desire to minimize latency, including things like: RFC9824 - "Compact Denial of Existence in DNSSEC" - saves small bits of time by not having to fetch from a DB style setup. RFC9715 - "IP Fragmentation Avoidance in DNS over UDP" - by not failing over to TCP, you can save quite a few RTT. RFC9520 - "Negative Caching of DNS Resolution Failures" - if you cache non-response answers you can immediately return these to clients. RFC9276 - "Guidance for NSEC3 Parameter Settings" - a bit of a stretch, but not doing iterations saves, um, many microseconds. RFC9210 - "DNS Transport over TCP - Operational Requirements" - 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" - trades some latency to improve privacy RFC8906 - "A Common Operational Problem in DNS Servers: Failure to Communicate" - if you don't answer, or answer incorrectly, some queries take much longer. RFC8806 - "Running a Root Server Local to a Resolver" - by having zones locally you don't need to do a lookup. RFC8198 - "Aggressive Use of DNSSEC-Validated Cache" - 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" - 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" - same as RFC8806. RFC4472 - "Operational Considerations and Issues with IPv6 DNS", RFC3901 - "DNS IPv6 Transport Operational Guidelines" - Make DNS fast by making sure IPv6 works too…. RFC3258 - "Distributing Authoritative Name Servers via Shared Unicast Addresses" - 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]
