Measure DNS resolution without confusing it with download speed

Measure the pause before the page, separately

A large download can run smoothly while each unfamiliar website hesitates before opening. Conversely, names can resolve promptly while files arrive painfully slowly. DNS timing and download throughput answer different questions: how long a name lookup takes, and how much data a connection delivers per second.

The useful experiment is narrower than “Which DNS provider is fastest?” Compare the lookup path available to one computer with an alternate path, then check whether name resolution occupies a meaningful part of a web request. You are looking for a repeatable delay that matches the complaint, not a winning number.

This procedure uses a macOS or Linux terminal with dig and curl available. Run dig -v and curl --version first. If either command is missing, stop that branch and use a computer with those tools; these instructions do not require installing software or changing router settings. Windows users should not treat the elapsed runtime of nslookup as an equivalent DNS measurement.

Choose two names and hold the connection steady

Pick the exact public hostname that feels slow and one unrelated public hostname that normally works. Use hostnames only, without a scheme, path, or account token. In the commands below, replace www.example.com. with your chosen name, keeping the final dot to make the name absolute.

Record the time and zone, device, connection, VPN state, and whether other household traffic is active. Pause your own bulk transfers for the first comparison. Keep required work VPNs connected and leave managed settings alone. Use only public names when querying an external provider, and skip that comparison if network policy prohibits it.

Label the ordinary command's path configured, not “ISP.” It may contact a router or local stub that forwards elsewhere. The alternate here is 1.1.1.1, which Cloudflare documents as its standard resolver. Sending it a query discloses that hostname to the provider. Its presence in this experiment is a comparison choice, not a recommendation to replace your existing service.

Keep the answer and the timing together

Run these separately:

dig -r www.example.com. A +tries=1 +time=2
 dig -r @1.1.1.1 www.example.com. A +tries=1 +time=2

The BIND manual documents explicit server selection, statistics, and retry controls. Here, -r ignores personal dig defaults; A requests an IPv4 address record; the options select one try and a two-second query timeout. Without @, dig uses its configured server list. This need not match the operating system's complete lookup policy.

Save SERVER, status, the answer, and Query time in milliseconds. Keep the full output. A useful success is NOERROR with an address answer, possibly following an alias. NOERROR with no address is not the same success. Preserve NXDOMAIN, SERVFAIL, or timeout wording as failures; never enter a timeout as zero milliseconds.

Query time includes reaching the responding server and waiting for its work. It does not isolate the resolver's internal processing or measure file transfer capacity. If the alternate times out, external DNS may be blocked or unreachable. That result cannot rank its performance. A named server in the output also cannot prove an intervening network did not intercept the request.

Separate the first observation from the repeat batch

For each hostname, run one configured/alternate pair and label it first observed. Then run five more pairs manually, a few seconds apart. Reverse the order in alternating pairs so one service does not always benefit from being queried later. Record failures alongside successful times.

For each path and hostname, report the median of successful repeat times, their minimum and maximum, and failures out of five. Sort successful values to find the median; with five successes it is the third value. A median without the failure count can make an unreliable path look attractive. Keep the first pair outside this repeat summary.

Do not call the first lookup “cold.” Someone else may already have requested that name. RFC 1034 explains cached records and TTL limits; the first request you observe need not trigger fresh authoritative queries. Repeats often exercise cached answers, which is useful everyday behavior but a different workload.

Flushing a computer's cache cannot establish that an upstream resolver is empty. Random subdomains introduce different names and potentially different failure behavior. Neither technique makes this small comparison a controlled cold-cache benchmark. Repeat the same bounded batch later during the symptom before attributing an isolated spike to a provider.

Ask how much of one request was spent resolving

Next, replace the URL below with a small public HTTPS page on the affected hostname. Use its ordinary URL spelling, without adding the DNS command's final dot. Run this as one terminal command, three times separately:

curl --head --silent --show-error --output /dev/null --max-time 15 --write-out 'dns=%{time_namelookup} first=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' https://www.example.com/

In curl's manual, these times are seconds from the start: resolution complete, first response byte, and operation complete. They are cumulative, not separate durations to add. --head requests headers; --max-time bounds the operation. No redirects are followed here. Keep errors and HTTP codes with each row; a failed operation is not a completed timing sample.

This tests request startup, not download throughput. A redirect measures only the initial response; a server rejecting HEAD is not a representative page-load trial. Pick another suitable small public page if necessary. Existing system caches can still influence separate invocations. If a proxy is configured, interpretation changes; do not equate its lookup path with a direct site lookup.

Consider explicitly hypothetical values: dns=0.020, first=1.200, total=1.210. Resolution finished after 20 milliseconds, leaving about 1.18 seconds before the first byte. Removing that measured DNS interval entirely would save only about 20 milliseconds for this transaction. These invented numbers illustrate the calculation; they are not test results or a universal performance threshold.

Decide which explanation survives the evidence

Different returned addresses complicate comparison: a resolver change may send a distributed website to a different delivery location. A faster lookup can coexist with a slower subsequent transfer. Also, this A-record trial does not clear IPv6 address lookups; repeat with AAAA as a separately labeled batch if relevant.

A browser may use another resolver entirely. Mozilla documents Firefox's DNS over HTTPS modes and fallback behavior. Record whether browser DNS differs before applying command-line findings to it. A browser page also involves multiple names, reused connections, scripts, and caches, so this single request is a diagnostic slice.

Finish with a repeatable result and a way back

These queries change no persistent DNS configuration, so recovery is simply stopping them and resuming paused transfers. Do not replace DNS across the household based on one batch. If evidence supports a later provider trial, first preserve the original automatic/manual setting and every configured address on one personal device; retain required filtering and internal-name access.

Retest the original symptom as well as the lookup batch. Restore the saved settings if names stop resolving, expected local services disappear, or the original task does not improve. Avoid router resets: they erase unrelated configuration without validating the timing hypothesis.

A useful support record includes the two public hostnames, timestamps, responding server addresses, first-observed results, repeat medians and ranges, failure counts, and HTTP timing rows. State the remaining uncertainty: “The configured query path was slower in two batches” is supportable when observed. “My ISP's DNS CPU is overloaded” is not established by these measurements.