How to check DNS lookup time

Clear the resolver cache, then run curl -s -o /dev/null -w '%{time_namelookup}' https://httpbin.org/get. The value is the seconds spent turning the hostname into an address. Cold, this run cost 125.1 ms. Run again without clearing and it fell to 17.3 ms, because the answer was already cached.

Why check this

DNS is the first leg of every request to a host the client has not spoken to recently. Check it when a new hostname enters the product: an API moved to its own subdomain, an asset host added, a vendor script pulled in. A resolver answering in 400 ms adds that cost to every cold visitor, and it never appears in a server log because the request has not reached the server yet.

The second reason is regression. A DNS provider change, a new CNAME hop, or a record with a two second TTL all show up here and nowhere else.

Prerequisites

• curl 7.52 or later. %{time_namelookup} is documented in the curl manual under --write-out.
• A command that clears the local resolver cache. On Windows ipconfig /flushdns, on macOS sudo dscacheutil -flushcache, on Linux with systemd sudo resolvectl flush-caches.
• nslookup or dig, to read the record TTL.

Steps

1. 1

   Step 1.

   Clear the resolver cache so the first measurement is cold.

   ipconfig /flushdns
   

   Successfully flushed the DNS Resolver Cache.

2. 2

   Step 2.

   Measure three times in a row without clearing again.

   for i in 1 2 3; do curl -s -o /dev/null -w "run $i namelookup %{time_namelookup}\n" https://httpbin.org/get; done
   

   run 1 namelookup 0.125102
   run 2 namelookup 0.017337
   run 3 namelookup 0.013983

   Run 1 is the real lookup. Runs 2 and 3 read the operating system cache, so they measure the cache, not DNS.

3. 3

   Step 3.

   Read the TTL of the record, which is how long that cache stays valid.

   nslookup -type=a -debug httpbin.org
   

           ttl = 9033 (2 hours 30 mins 33 secs)
         internet address = 3.212.75.38
         ttl = 21 (21 secs)
         internet address = 98.88.64.13
         ttl = 21 (21 secs)

   The A records carry a 21 second TTL, so a client that waits half a minute pays the full lookup again.

4. 4

   Step 4.

   Confirm the field measures resolution alone, by handing curl the address and skipping DNS.

   curl -s -o /dev/null --resolve httpbin.org:443:44.194.227.11 -w 'namelookup %{time_namelookup}\nconnect    %{time_connect}\n' https://httpbin.org/get
   

   namelookup 0.000123
   connect    0.135371

   With the lookup removed the field reads 0.1 ms, and connect is unchanged. Anything above that in a normal run is resolution.

How to read the result

| What you see | What it means | What to do | | --- | --- | --- | | Cold lookup under 50 ms | The resolver answered from its own cache or a nearby node | Nothing. Record the number and move to the connection. | | Cold lookup of 100 ms to 400 ms | A full recursive walk, or a distant resolver | Compare with a second network. A slow resolver on one machine is not a product defect. | | Every run identical and high | Caching is off, or the TTL is near zero | Read the TTL in step 3 and ask why it is short. | | time_namelookup near zero on run 1 | The cache was not cleared | Clear it and measure again, or the number means nothing. |

Common mistakes

What to check next

• How to check TTFB: the lookup is the first slice of the same timing breakdown.
• How to check if a site uses a CDN: a CNAME to a CDN adds a hop that this measurement includes.
• How to check preload and preconnect hints: dns-prefetch and preconnect move this cost off the critical path.
• How to check if keep-alive is enabled: a reused connection skips the lookup for later requests.

FAQ

How to measure DNS resolution time with curl?

Use -w '%{time_namelookup}' with -o /dev/null. Clear the resolver cache first. The value is seconds from the start of the request to the moment the address was known.

Why is the second measurement always faster?

The answer is cached by the operating system for the record TTL, and often by the upstream resolver as well. The second run reads memory instead of the network, so it measures the cache.

What is a good DNS lookup time?

There is no published threshold the way there is for TTFB. Compare a cold run against the same host from another network, and against the other hostnames your page uses.

Does a short TTL make a site slower?

It makes cold lookups more frequent. The 21 second TTL on the host above means most visitors pay the lookup again on a second visit, which is a trade for faster failover.

Verified