DNS timing is not your download rate

DNS resolves names to records such as IP addresses. A faster response to one lookup does not establish a faster sustained download, a lower game-server round trip, or better performance for every website. Cached answers may avoid a new lookup entirely. Start with a specific symptom: failed name resolution, a delay before a connection, or low throughput after it has started.

Compare the same question under recorded conditions

Use an operating-system lookup tool to query the same name and record type against each resolver. Record the resolver address, query, time, network, response status, and returned answer. Repeat and alternate order. Keep successful and failed attempts. Local, browser, and recursive-resolver caches can differ; a repeated cached lookup is a different condition from the first lookup. Cloudflare documents example dig comparisons, but its troubleshooting examples are not independent rankings.

Try a read-only lookup before changing settings

These commands send a DNS question to the specified public resolver; they do not change your device's DNS configuration or clear caches. The resolver and your network can observe the query. Use a public example name first, not a private work hostname, and do not bypass workplace or VPN policy. A network can block or redirect ordinary DNS; specifying a resolver address does not prove the request reached it unchanged.

macOS or Linux, when dig is available

On narrow screens, command blocks may scroll sideways. Keyboard users can Tab to a block and use the left and right arrow keys to read the full line.

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Keep the full output. Look for the response status, answer section, server field, and Query time. Use the same name and record type, then repeat in reverse order. Do not treat the first pair as a winner: the recursive resolver may already have a cached answer, and the second request has different timing conditions. If dig is unavailable, use an approved tool for your platform rather than installing software on a managed device without permission.

Windows Command Prompt or PowerShell

nslookup -type=A example.com 1.1.1.1
nslookup -type=A example.com 8.8.8.8

Compare success, failure, the selected server, and the returned answer. Standard nslookup output does not normally report a comparable query-time field. Do not equate the time for the whole command to finish with a single DNS round trip, or invent a millisecond value from this output. This is a resolution check, not a Windows speed ranking.

Illustrative output only: the fragment below is constructed to explain fields. It is not captured from a test, not a current answer for example.com, and not a VelocityVerify measurement. The answer address is a documentation placeholder.

;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; ANSWER SECTION:
example.com. 300 IN A 192.0.2.10
;; Query time: 18 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
  • NOERROR: the DNS response does not report an error. Check that the requested record is actually present; a successful status can still have an empty answer. It does not prove the website or application will connect.
  • NXDOMAIN: the response says the queried name does not exist. Check spelling and the full name, and compare the same question elsewhere before diagnosing the cause.
  • SERVFAIL: the resolver could not complete the request. Keep the failure and compare another name and resolver; this status alone does not identify the underlying fault.
  • A timeout: no usable response arrived within the tool's waiting/retry limits. Record it as a failure, not zero milliseconds or an excluded inconvenient result. Blocking, routing, or resolver problems are possibilities, not a diagnosis from one attempt.
  • Query time: a timing for that dig query, not download throughput, page-load time, or a guarantee about future requests. The server field reports the queried endpoint, not independent proof of the entire network path.

Keep a short record: timestamp and timezone; device and network; VPN state; resolver; name and record type; outcome; returned answer; and query time only if the tool reports it. Do not average failures as numeric timings. Different answers can be legitimate; a different destination also changes the conditions for a later application test.

Next action: if one resolver repeatedly fails while another answers under the same recorded conditions, investigate the resolver or network path before changing system-wide settings. If both answer but downloads remain slow, investigate throughput separately. Browser secure DNS can use another path, so these command-line results may not describe the browser's own lookups.

Command references: Cloudflare's dig and nslookup troubleshooting examples and Microsoft's nslookup syntax and error descriptions. Neither source establishes a fastest-resolver recommendation.

Do not turn a small sample into a ranking

A resolver comparison depends on your location, routing, record, caches, and moment of observation. Different answers may direct a service to different endpoints. Test the affected task too, while recognizing that destination changes introduce another variable. This page supplies no universal fastest-resolver table and no measured DNS result from the VelocityVerify throughput test.

Change one setting and keep a rollback path

Check your router, device, browser secure-DNS setting, and any VPN or workplace policy. They may select different resolvers. Do not override managed settings without approval. Save the original configuration, change one layer at a time, repeat the same task, and restore it if names fail, filtering changes unexpectedly, or access becomes unreliable.

Review privacy and scope

A resolver choice changes which operator can handle your DNS requests; it does not make all browsing anonymous. Encrypted DNS protects a particular transport path, not every part of the connection. Read the operator’s current policy rather than assuming zero logging. Cloudflare describes limited resolver logs and exceptions in its policy. Consider filtering, parental controls, and organizational requirements alongside timing.