Nameserver Performance Test
Test nameserver performance for any domain: repeated timed SOA queries give min, average and max response time, jitter and packet loss for each authoritative server, measured from Europe.
About Nameserver Performance Test
The Nameserver Performance Test measures how quickly each of a domain's authoritative nameservers actually answers. It resolves the NS set, sends a series of timed SOA queries to every server, and reports the minimum, average and maximum response time, the jitter between them, and the share of queries that got no reply at all. The fastest and slowest servers are named, so an underperforming secondary that a normal lookup would hide behind its healthier peers becomes visible in a single run.
RFC 1035 describes a resolver keeping per-server state, the SLIST, with the response history it uses to prefer whichever nameserver has been answering fastest. That strategy copes well with a server which is dead and badly with one which is merely slow or lossy. Because DNS over UDP has no transport-level retransmission, every dropped query costs the resolver its whole timeout, often close to a second, before another server is tried. The site stays up, but a slice of real users pays that wait before the first byte. RFC 2182 asks for diverse secondaries precisely so one bad path cannot dominate.
Each nameserver receives four consecutive SOA queries at the zone apex, a question every authoritative server must answer and one that is cheap to serve, so the figures reflect the network path and server load rather than an unusual record type. Jitter is reported as maximum minus minimum, the plainest signal of an unstable path, and loss as the proportion of queries that went unanswered. Up to ten nameservers are measured, and everything is timed from our own European servers, so the numbers are a European view rather than a North American one.
How to use it
- 1Enter the domain whose nameservers you want to measure, such as example.eu.
- 2Select Measure nameservers to send the repeated timed SOA queries.
- 3Read each server's line: the average response time in bold, then min, max and jitter, with the bar giving a visual comparison.
- 4Compare the others against the fastest server named above the list.
- 5Investigate any server reporting packet loss, or a jitter figure much larger than its own average.
Common use cases
- -Comparing DNS providers with real numbers before moving a zone or adding a second provider.
- -Troubleshooting slow first-byte times that no application metric explains, by ruling the nameservers in or out.
- -Detecting a secondary on a poor network path that raises latency for only a fraction of lookups.
- -Auditing the geographic spread of a delegation from a European vantage point, as RFC 2182 recommends.
- -Verifying that a move to anycast nameservers really did lower response time from Europe.
Frequently asked questions
- What is a good DNS nameserver response time?
- Measured from within Europe, an anycast nameserver on a good path usually answers in under 30 ms, and anything below 50 ms is comfortable. Between 50 and 150 ms normally means the nearest instance sits on another continent. Above 150 ms, or with visible packet loss, the server is adding delay to every cold lookup your users make.
- Does a slow nameserver slow down my website?
- Only for lookups that miss a cache, but those are the ones users notice. DNS resolution has to finish before the TCP connection can even start, so the time is added at the very front of the page load, ahead of everything else. Once a record is cached for the length of its TTL, the nameserver is out of the path until that TTL expires.
- What does jitter mean in a DNS test?
- Jitter here is the maximum response time minus the minimum across the samples, so it shows how much the answer time varies rather than how large it is. A server averaging 40 ms with 5 ms of jitter sits on a stable path. The same average with 200 ms of jitter points to congestion, an overloaded server, or a route flapping between anycast instances.
- Why does one of my nameservers show packet loss?
- A DNS query is a single UDP datagram, so a lost query simply gets no answer and the test counts it. Common causes are a rate limiter or firewall dropping queries it considers abusive, a congested path, or a server too busy to reply. Any loss is worth investigating, because a resolver must wait out its full timeout before trying another server.