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]
