01 Compare Public DNS Resolvers From Where You Are
Compares how fast Cloudflare and Google public DNS answer from your browser: your round trip, a new name, and the difference.
This tests public resolvers only. A browser cannot see which DNS server your device uses, so it cannot time your current one. See "Time your own resolver" below.
Check the connection underneath
DNS is only one part of speed. The Live Network panel shows latency, jitter and packet loss, which tell you whether the problem is DNS or the connection itself.
02 What a DNS Lookup Is and Why It Gets Slow
Every website you open has a name, and computers route by number. A DNS lookup is the step that turns the name into an IP address. Your device asks a resolver, usually run by your ISP or a public provider. If the resolver already knows the answer it replies at once. If it does not, it walks from the root servers to the top-level domain and then to the server that owns the name, as defined in RFC 1034 and RFC 1035.
Resolvers keep answers for a time set by each record, called the TTL. That is why a site you visit often loads its name quickly, and a name you have never asked for takes longer. Your browser, your operating system and often your router keep their own caches on top of that.
Lookup time matters because it comes first. Nothing else about a page can start until the name has an address, so a slow lookup delays every new site you open.
03 What Counts as Slow
A lookup includes the trip to the resolver, so raw numbers depend on where you are. The fix is to compare two lookups of the same kind. The tool above reports a penalty: the time for a new name minus your fastest round trip to the resolver. You can do the same for your own resolver with the commands further down: the first lookup of a site you rarely visit, minus the second, is the resolver's own work.
| Penalty | What it usually means | Next step |
|---|---|---|
| Under 100 ms | Normal. The resolver is doing its job | Nothing to fix here |
| 100 to 300 ms | Noticeable on new sites | Compare with another resolver |
| Over 300 ms | Slow. Often a distant, overloaded or partly failing resolver | Compare resolvers, switch if one is clearly faster, then retest |
These ranges are this page's own rule of thumb, not an industry standard. Also look at the round trip. If it is already about 150 ms or more, which can happen on mobile networks or far from the resolver (a second rule of thumb), distance dominates every lookup, and a resolver run by your ISP can be closer and faster than a public one.
04 Common Causes of Slow Lookups
Most slow lookups trace back to a short list of causes. A distant or overloaded resolver is a frequent one. An unresponsive DNS server in your list is the classic hidden one: the device waits for it to time out before trying the next, so some lookups take seconds. An unreachable IPv6 DNS server causes the same wait before the device falls back to IPv4. Routers that forward DNS can add delay or get stuck, VPN and security software can redirect lookups to their own servers, and a browser's own Secure DNS setting can bypass the DNS your device is set to use.
If pages also stall after the name resolves, the cause is probably not DNS. Our guide to why internet speed fluctuates covers congestion and Wi-Fi problems that look similar.
05 Time Your Own Resolver
The browser check cannot see your current resolver, so time it from the command line. Use a site you rarely visit, because a popular name is probably already cached. Run each timing twice: the first run is the resolver doing the full lookup, the second is answered from the resolver's cache, and the difference is the resolver's own work. Your device must not answer the repeat itself, so clear its cache before each run where it keeps one.
- Mac: run
dig sitename.com, read the Query time line, then run it again. dig asks the resolver directly, so no flush is needed. To compare, rundig sitename.com @1.1.1.1ordig sitename.com @8.8.8.8the same way. - Linux: use the same dig commands. If your system uses systemd-resolved, run
resolvectl flush-cachesbefore each one, because dig then asks a local service that remembers answers. If dig is not installed, add your distribution's DNS utilities package. - Windows: run
ipconfig /flushdns, thenMeasure-Command { Resolve-DnsName sitename.com -Type A }in PowerShell and read TotalMilliseconds. The-Type Aasks for one record, as dig does. Flush again and repeat. Flushing before each run stops Windows answering from its own cache. To compare, flush, then add-Server 1.1.1.1to the same command and repeat the same way. If Windows refuses the flush, open PowerShell as administrator.
06 Fix 1: Change the DNS Resolver
Switching helps when your current resolver is the slow part. It does not help if the new one is far from you, so compare before and after. Three widely used public resolvers are listed below. Set one on a single device, or on the router so every device that uses it benefits.
| Resolver | Addresses | Notes |
|---|---|---|
| Cloudflare | 1.1.1.1, 1.0.0.1. Android name: one.one.one.one | General purpose, supports DNS over HTTPS |
| Google Public DNS | 8.8.8.8, 8.8.4.4. Android name: dns.google | General purpose, supports DNS over HTTPS |
| Quad9 | 9.9.9.9, 149.112.112.112. Android name: dns.quad9.net | Blocks known malicious domains |
| Your ISP | Assigned automatically | Varies by provider |
| Device | Where | What to enter |
|---|---|---|
| Windows 11 | Settings, Network & internet, then Wi-Fi or Ethernet, open the connection properties, DNS server assignment, Edit | Choose Manual, turn on IPv4, enter preferred and alternate addresses |
| Mac | System Settings, Network, your connection, Details, DNS | Add addresses with the plus button |
| iPhone and iPad | Settings, Wi-Fi, the info icon next to your network, Configure DNS | Choose Manual and add servers. This applies to that Wi-Fi network only, not to mobile data |
| Android | Look for Private DNS in the network or connection settings (names vary by maker) | Choose the private DNS provider and enter the name from the table above. It applies on every network, including mobile data |
| Router | Router admin page, Internet or WAN settings | Enter primary and secondary DNS. See the router IP guide to sign in |
After changing it, flush the cache (next section) and repeat your measurement. To undo, set the connection back to automatic.
07 Fix 2: Flush the DNS Cache
A cache can hold a bad or outdated answer. Flushing clears it. This is quick and safe, and your device simply asks again.
| System | Command |
|---|---|
| Windows | ipconfig /flushdns |
| macOS | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder |
| Linux (systemd-resolved) | resolvectl flush-caches |
Browsers keep a separate cache. Restarting the browser clears it.
08 Fix 3: Check Your VPN, Router and Security Software
A VPN usually sends lookups to its own servers, so a slow VPN resolver means slow lookups even when your own is fast. Turn the VPN off and test again. The VPN and Proxy panel shows whether your connection is routed through one. Then restart the router, since its DNS forwarder can get stuck, and check whether security or parental-control software filters DNS.
Frequently Asked Questions
Twelve questions on DNS lookup time, resolvers and fixes.
Explain what a lookup is, define slow in a way that removes distance, list the causes, then separate measuring your own resolver from comparing public ones. Change DNS only when a comparison supports it, and measure again afterwards.
The browser check sends DNS-over-HTTPS queries to Cloudflare and Google. It times one warm-up, seven repeat lookups of example.com (the fastest is your round trip) and five lookups of random new names (the median is the new-name time). It cannot see your current DNS server, so the commands in the page time that one. Penalty ranges are a rule of thumb, and results depend on your location and connection.