DNS Latency: How to Measure It, Fix It and Monitor It

Every visit to your site starts with a DNS lookup, and nothing else can happen until it finishes. Most of the time it takes a few milliseconds because the answer is cached; occasionally it takes hundreds, and when DNS breaks outright your site is unreachable even though the server is perfectly healthy. This guide explains how resolution works, how to measure it with dig, which settings you control, and how DNS failures look in your monitoring.

How a DNS lookup actually works

When a browser needs the IP address for www.example.com, several parties are involved:

1. Stub resolver — the small resolver in the operating system. It checks its local cache and otherwise forwards the question.
2. Recursive resolver — run by the ISP, a company network, or a public service such as 1.1.1.1 or 8.8.8.8. If it has a cached answer that has not expired, it returns it immediately. This is the common case and the reason DNS is usually fast.
3. Root servers — on a cache miss, the recursive resolver asks a root server, which replies with the servers for the top-level domain (.com).
4. TLD servers — the .com servers reply with the delegation: the authoritative name servers for example.com, as registered at your registrar.
5. Authoritative servers — your DNS provider's servers, which return the actual record (an A, AAAA or CNAME).

Root and TLD referrals are themselves cached for a long time, so a typical cache miss costs one round trip from the resolver to your authoritative server. If your record is a CNAME pointing to another domain (common with CDNs and hosted platforms), the resolver may have to repeat the process for the target name, adding more round trips.

So DNS latency, from a visitor's point of view, is mostly: was the answer cached at their resolver, and if not, how fast and how close are your authoritative servers?

Measuring DNS with dig

dig (part of the bind9-dnsutils or bind-utils package) is the standard tool. Its statistics footer, printed by default and toggled with +stats, includes the query time:

dig example.com A +stats

;; ANSWER SECTION:
example.com.        3600    IN    A    203.0.113.10

;; Query time: 38 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: ...
;; MSG SIZE  rcvd: 56

Three things to read here: the status in the header (NOERROR, NXDOMAIN, SERVFAIL), the TTL (3600 seconds remaining in the cache), and the query time. Run the same command twice: the second answer usually comes back in a millisecond or two, with a lower TTL, because it came from the resolver's cache. The first number is the one that reflects your DNS setup.

Useful variations:

# Ask a specific public resolver
dig @8.8.8.8 example.com

# Find your authoritative servers, then query one directly (no cache involved)
dig example.com NS +short
dig @ns1.your-dns-provider.net example.com A

# Follow the whole chain from the root, as a resolver would
dig +trace example.com

# Just the answer, for scripts
dig +short www.example.com

Querying the authoritative server directly measures the real cost of a cache miss from your location. +trace shows each referral (root, TLD, authoritative) and is the fastest way to spot a broken step: a referral to name servers that do not answer, or that answer differently from each other.

From a monitoring perspective, the same phase appears as "DNS time" in a curl timing breakdown (%{time_namelookup}); our article on TTFB and how to measure it shows the full command.

TTL: the main knob you control

The TTL (time to live) on a record tells resolvers how long they may cache it. It is a straight trade-off:

A practical pattern: keep a comfortable TTL (an hour is common) for normal operation. Before a planned migration, lower it to a few minutes at least one old-TTL period in advance, so every cache has picked up the short value by the time you switch. After the move is stable, raise it again.

Remember negative caching too. When a name does not exist, resolvers cache that "no" for a period derived from the zone's SOA record (RFC 2308). If you query a hostname before creating it, you may keep getting NXDOMAIN for a while after you add it.

Anycast DNS and provider choice

With anycast, the same name-server IP address is announced from many locations, and internet routing delivers each query to a nearby one. For your authoritative DNS, that means a cache miss in another continent is answered locally instead of crossing an ocean. It also spreads load and absorbs some attacks, because no single site handles all traffic.

Most managed DNS services and large registrars' DNS run on anycast networks. If your zone is served by a couple of name servers in one data center — a common default with budget hosting — every cache miss far from that data center pays the full distance, and a single network problem there takes your DNS offline. Moving the zone to an anycast provider is usually a low-risk change: you copy the records, then update the name servers at the registrar.

Also check for CNAME chains. www → app.hosting-provider.net → lb-eu.hosting-provider.net is three names to resolve. Where the provider allows it, point directly at the final target, or use your DNS provider's apex-flattening feature (often called ALIAS or CNAME flattening).

DNS failure modes that take sites down

Slow DNS costs milliseconds; broken DNS costs the whole site. The common failures:

SERVFAIL

The resolver tried and could not get a valid answer. Typical causes: all authoritative servers are unreachable or timing out, the servers return inconsistent or malformed data, or DNSSEC validation failed (for example, a DS record at the registrar no longer matches the zone's keys after a provider change). A quick test for the DNSSEC case:

dig example.com          # status: SERVFAIL
dig example.com +cd      # +cd = checking disabled; if this returns NOERROR, DNSSEC is the problem

NXDOMAIN

An authoritative "this name does not exist". Causes include a deleted or mistyped record, a record created in the wrong zone, or, more seriously, the domain itself being removed from the TLD zone — which happens when a registration expires or is suspended. When dig +trace shows the TLD servers answering NXDOMAIN for your domain, the problem is at the registrar, not your DNS host.

Lame or expired delegations

The TLD still points to name servers that no longer serve your zone: you moved DNS providers but left the old NS records at the registrar, the old provider closed the account, or one of several listed name servers was decommissioned. Some resolvers try the dead server first, time out and retry, which shows up as intermittent slowness or intermittent SERVFAIL rather than a clean outage. Compare the delegation with what the servers themselves report:

dig +trace example.com NS              # what the TLD delegates to
dig @ns1.your-dns-provider.net example.com NS +short   # what the zone itself says

The two lists should match, and every listed server should answer authoritatively.

How DNS problems show up in uptime monitoring

An uptime check has to resolve your hostname before it can connect, so DNS failures surface as a distinct error rather than an HTTP status code. In Uptime Monitor, a failed lookup is recorded with the cause code dns_error, separate from connect_error, timeout or server_5xx. That distinction matters during an incident: a dns_error means restarting the web server will not help, and the next places to look are the DNS provider status, the registrar, and recent DNS changes.

The DNS time stored with each check is also worth watching: when a slow check is dominated by DNS, the dashboard names it as the likely bottleneck, and PDF reports on Plus and Professional show the average DNS time. It is normally small because the monitoring host's resolver caches answers, so a sudden rise, or a pattern of spikes once per TTL period, points at slow authoritative servers. Keep in mind that a single monitoring location sees DNS through one resolver; a regional resolver problem elsewhere would not show up there. When you do get a DNS alert, the website down checklist covers what to check first, and our HTTP status codes guide explains the errors that appear once DNS is working again.

FAQ

What is a good DNS lookup time?

Cached answers should take a few milliseconds. For an uncached lookup, the cost is roughly one round trip from the resolver to your nearest authoritative server, so a nearby anycast provider will be much faster than distant single-site name servers.

Does lowering the TTL make my site faster?

No — the opposite. A shorter TTL means answers expire sooner, so more visitors hit a cache miss. Use short TTLs only when you need fast changes.

Why does my site work for me but show DNS errors for others?

Different resolvers hold different cached answers. After a change, some resolvers still serve the old record until its TTL expires; with a broken delegation, results can depend on which name server a resolver happens to try.

Checklist

• Measure cold lookups with dig @your-authoritative-server and full resolution with dig +trace.
• Use an anycast DNS provider for the zone, and avoid long CNAME chains.
• Keep TTLs moderate; lower them only ahead of planned changes.
• Make sure NS records at the registrar match the provider you actually use.
• After any DNSSEC or provider change, verify with and without +cd.
• Keep domain registration on auto-renew with a payment method that will not expire.

Uptime Monitor stores DNS time on every check and labels lookup failures as dns_error, so a DNS incident is identified as one in the alert itself instead of after twenty minutes of checking web servers. You can try it on one site with the free plan — sign up here.