Domain & DNS
DNS response time benchmark
Benchmark resolver speed across multiple providers.
Domain, record type, runs
We query 15 resolvers N times and stream each latency sample live.
About this tool
This tool measures how fast 15 public resolvers answer a DNS query for the domain you choose. Each resolver is queried several times in a row so you can see variance — a single outlier is often a cold cache, a consistent high number means that anycast footprint is just far from our Frankfurt host.
Latency is taken from dig's own ;; Query time statistic, which measures the wire time between us and the resolver after the process starts. Fork+exec overhead (~10–20ms) is excluded, so the numbers reflect network + resolver behaviour rather than OS scheduling. The sparkline shows the raw sequence; the Min/Avg/Max columns summarize successful runs only.
When to use this tool
- Picking a resolver for your router or device. Run against a domain you actually use — different networks see different winners.
- Diagnosing a slow site. Compare resolver latency against site-load symptoms — DNS that always takes 200ms adds up over dozens of subresources.
- Monitoring a provider. If your primary resolver suddenly jumps from 20ms to 300ms across several runs, it is time to switch.
- Comparing anycast coverage. Cloudflare and Google usually win from EU hosts; Alibaba and DNSPod surprise-win from Asia.
Why results differ from your local network
We measure from our server in Germany to each resolver's nearest anycast POP. From your home network the distances and peering are different. Treat absolute numbers as a relative comparison, not as your personal latency. If you need a local measurement, rundig +stats @<ip> example.com on your own machine — the same flag produces the same number.
Frequently asked questions
Why is one resolver much slower than the rest?
Either its nearest POP is far from our host, its anycast is having a bad day, or the recursive had to traverse to an authoritative server (cold cache). Our default query is
cloudflare.com — a very popular name that every resolver caches; if you query a rare domain, the first run will be slow for everyone.
What does "Timeout" mean?
No UDP reply in 2 seconds. Could be a temporary glitch, our host's IP is blocked by that provider, or the resolver is under pressure. One timeout in five runs is noise; five out of five means that resolver is currently unreachable from our Frankfurt network.
How is this different from DNS Propagation?
Propagation asks "do resolvers see the new value?" — one query each, values compared side-by-side. Response Time asks "how fast do they answer?" — multiple queries each, latency compared side-by-side. Different question, same 15 resolvers.
Can I change the number of runs?
Yes — pick 3, 5, 7, or 10 from the dropdown. More runs = tighter median, but each run waits for the previous to finish across all 15 resolvers, so 10 runs take roughly 5× as long as 2 runs. For casual use, 5 is a good balance.
Are the results cached?
For one minute per (domain, type, runs) triple. Clicking Measure twice in a row returns the same result table — good for sharing the URL, bad for polling changes. Adjust the domain or runs to force a fresh run; wait 60s otherwise.