Actually, 450 ms was already a cache hit. The response time would be 530 ms on the first query of google.com:

  ./godnsbench -c 1 -q google.com -a https://sky.rethinkdns.com/dns-query
  ...
  2025/05/05 02:50:14 [info] Average per query: 532.1144ms

Subsequent queries for google.com within a few minutes would result in a slightly shorter response time, like my second comment above.

  ./godnsbench -c 1 -q google.com -a https://sky.rethinkdns.com/dns-query
  ...
  2025/05/05 02:50:48 [info] Average per query: 468.5749ms

  ./godnsbench -c 1 -q google.com -a https://sky.rethinkdns.com/dns-query
  ...
  2025/05/05 02:55:04 [info] Average per query: 472.1229ms

Some of the lengthy response times originate from the overhead of DNS over HTTPS. If we switch to the DNS over TLS version of Rethink DNS, there will be about a 240-320 ms improvement in response time.

  ./godnsbench -c 1 -q google.com -a tls://max.rethinkdns.com
  ...
  2025/05/05 02:50:26 [info] Average per query: 290.4762ms

  ./godnsbench -c 1 -q google.com -a tls://max.rethinkdns.com
  ...
  2025/05/05 02:50:51 [info] Average per query: 145.1868ms

However, 290ms is still quite a large delay for DNS queries, which makes webpage rendering a quarter of a second slower the first time you visit it.

So how is it fast in the multiple lookup case?

Is it all per request overhead and gets eaten by a single large request doing multiple lookups?

> Could the ~430ms be startup time for a sleeping worker? Or is it the cost for a cache miss?

One won't really gain much insight for DoH / DoT resolver performance with one query per connection, I don't think.

For something as lightweight as domain name resolution, network latency / round-trip time dominate so much (for a public DNS resolver anyway) that the CPU-bound optimizations are almost always pointless if you don't first optimize your network deployment: For example, not running servers closer to your users wouldn't move the needle much regardless of how big your caches are, or the language your resolver is written in (C or Rust or hand-rolled assembly or SIMD/SIMT built-ins etc). A good indicator of performance of a pubic DNS resolver would be to monitor it over a period of time, to effectively rule out noise introduced by variances.

But as far as I understand - these tests are run on hosts with comparable distance/ping?

And 400ms ping is remarkably bad for a client that can otherwise do 20ms to a nearby server?

godnsbench isn't testing pings but DoH / DoT (and DoH is expensive due to the TCP, TLS, and HTTP overhead [0]). OP did share a ping report (which paints a different picture): https://check-host.net/check-ping?host=https://sky.rethinkdn...

Sending one DNS query per HTTP connection (which is what the OP claims is "real world") is not how "real world" DoH clients are supposed to be written or work. So it is unlikely to be representative of "real world" delays.

In fact, in my tests, other public DNS resolvers don't fair any better with one query per connection, either.

[0] For example, a TLS handshake transfers 1.5KB to 4KB, while a typical DNS query is 30B to 70B & responses are 70B to 150B.