Is Your ISP's Default DNS Server Slowing You Down?

When you plug in a new router, it quietly configures every device on your network to use your internet provider's DNS resolver. Most people never look at that setting again. Sometimes that is perfectly fine — an ISP resolver sits close to you on the network and can be very fast. Other times it is the reason websites take a noticeable beat before they start loading, why a typo lands you on an ISP search page full of ads, or why sites stop working entirely while the rest of your connection seems fine. The broader question of whether DNS settings affect website speed has a nuanced answer; this article is about testing your own ISP's resolver so you can answer it for your connection.

You will learn how to find out exactly which resolver you are using, how to measure its speed against alternatives with repeatable tests, the non-speed problems that are often a better reason to switch, and when staying with your ISP's resolver is actually the better choice.

Why the ISP Resolver Matters

Every time a device needs to look up a hostname that is not already in its local cache, it asks a recursive resolver. The resolver either answers from its own cache or walks the DNS hierarchy to find the answer. A single page can involve lookups for a dozen or more hostnames — the site itself, its CDN, font hosts, analytics, and ad networks — so a slow resolver adds delay to the start of many connections.

A resolver can be slow or unreliable for several reasons:

• Overloaded hardware at busy times of day.
• Poor caching — small caches or aggressive eviction mean more full recursive lookups.
• Distance — some ISPs run resolvers in only a few central locations.
• Outdated software that handles modern features such as EDNS or DNSSEC poorly.
• Outages that affect DNS while the rest of the connection stays up, making the internet appear "down."

The key word is "can." Plenty of ISP resolvers are fast and well maintained. The only way to know is to measure.

Step 1: Find Out Which Resolver You Are Using

Your device usually lists your router as its DNS server, and the router forwards queries to the ISP. You need to know both.

Windows (PowerShell):

Get-DnsClientServerAddress -AddressFamily IPv4 |
    Where-Object { $_.ServerAddresses } |
    Select-Object InterfaceAlias, ServerAddresses

macOS:

scutil --dns | grep "nameserver\[[0-9]*\]" | sort -u

Linux with systemd-resolved:

resolvectl status | grep -E "DNS Servers|Current DNS Server"

If these show something like 192.168.1.1, your router is the DNS server and it forwards upstream. To see the resolver that actually reaches the internet, ask a service that reports the source address of the query:

dig whoami.akamai.net A +short
dig o-o.myaddr.l.google.com TXT +short

whoami.akamai.net returns the IP address of the resolver that queried Akamai's authoritative servers. The Google TXT record returns the same kind of information (and, if your resolver sends EDNS Client Subnet, a second line showing your truncated subnet). Look up that IP with a WHOIS tool: if it belongs to your ISP, you are using the ISP's resolver. If it belongs to Cloudflare, Google, or Quad9, someone has already changed it.

Step 2: Measure Lookup Times

Compare your current resolver with a few public resolvers using the same set of domains. Make sure to include both your router and, if you can find it, the ISP resolver directly (often listed in the router's WAN or Internet status page).

#!/usr/bin/env bash
SERVERS="192.168.1.1 1.1.1.1 8.8.8.8 9.9.9.9"
DOMAINS="wikipedia.org github.com bbc.co.uk mozilla.org reddit.com python.org"

for server in $SERVERS; do
  total=0
  count=0
  for domain in $DOMAINS; do
    t=$(dig @"$server" "$domain" A +noall +stats +time=2 +tries=1 | awk '/Query time/ {print $4}')
    if [ -n "$t" ]; then
      total=$((total + t))
      count=$((count + 1))
    fi
  done
  if [ "$count" -gt 0 ]; then
    echo "$server: average $((total / count)) ms over $count queries"
  else
    echo "$server: no responses"
  fi
done

Save it as dns-test.sh, make it executable with chmod +x dns-test.sh, and run it a few times. It sends one A query per domain to each server, extracts the Query time that dig reports, and prints an average. Queries that time out after two seconds are skipped and show up as a lower count — a useful signal in itself.

Interpreting the numbers:

• Single-digit to low tens of milliseconds for popular domains is good. That is a cache hit at a nearby resolver.
• Consistently higher times for your ISP than for public resolvers at the same moment suggests the ISP resolver is genuinely slower.
• Big swings between runs, or timeouts, point to an overloaded or flaky resolver.
• The router's number includes the router's own forwarding, which is usually a millisecond or two; if the router is much slower than querying the ISP resolver directly, the router itself is the bottleneck.

For a more statistically solid comparison with medians and percentiles, and a deeper look at the main public resolvers, see Cloudflare DNS vs Google Public DNS vs Quad9, which includes a Python benchmark script you can point at your ISP's server too.

Test Uncached Lookups

Popular domains are almost always cached, so they mostly measure network distance. To see how fast a resolver performs a full recursive lookup, query names that are very unlikely to be cached:

for server in 192.168.1.1 1.1.1.1; do
  name="$(date +%s%N | tail -c 8)-test.wikipedia.org"
  echo -n "$server: "
  dig @"$server" "$name" A +noall +stats | awk '/Query time/ {print $4 " ms"}'
done

Each run builds a random subdomain, so the resolver cannot have it cached (though it may still have the parent zone's nameservers cached). The answer will be NXDOMAIN, but the timing reflects the resolver's ability to reach authoritative servers. On macOS, date +%N is not supported, so replace it with $RANDOM$RANDOM.

Test at Different Times

Run your tests in the morning and again in the evening, when residential networks are busiest. A resolver that is fine at 10 a.m. but sluggish at 9 p.m. is under-provisioned.

Step 3: Check for Problems That Are Not About Speed

Speed differences are often small. These issues are frequently a stronger reason to switch.

NXDOMAIN Hijacking

Some ISPs intercept "domain does not exist" responses and return the IP of their own search or advertising page instead. That breaks software that relies on correct errors and is a privacy concern. Test it:

dig thisdomaindoesnotexist-7f3a9c.com A

A well-behaved resolver returns status: NXDOMAIN with no answer section. If you get status: NOERROR with an IP address, your resolver is rewriting failures. The post on NXDOMAIN, SERVFAIL, and REFUSED explains what each status should mean.

No DNSSEC Validation

A validating resolver refuses to return answers for domains with broken signatures, which protects you from certain spoofing attacks. Check with a deliberately broken test domain:

dig dnssec-failed.org A | grep status
dig example.com A +dnssec | grep flags

On a validating resolver, the first command shows SERVFAIL, and the second shows the ad (authenticated data) flag in the header. If dnssec-failed.org resolves normally and ad never appears, your ISP resolver is not validating. Read what DNSSEC is for why that matters.

Reliability

If you regularly see browser errors like DNS_PROBE_FINISHED_NO_INTERNET or "server not found" while video calls on the same connection keep working, the ISP resolver may be going down intermittently. A simple log over a day makes this visible:

while true; do
  if ! dig @192.168.1.1 example.com A +short +time=2 +tries=1 | grep -qE '^[0-9.]+$'; then
    echo "$(date '+%F %T') lookup failed" >> dns-failures.log
  fi
  sleep 60
done

Once a minute, the loop asks the router to resolve example.com and appends a timestamp to dns-failures.log whenever the output does not contain an IPv4 address (a timeout, SERVFAIL, or empty answer). Press Ctrl+C to stop it. A handful of failures per day is a sign of trouble; for help diagnosing them, see how to fix the DNS server not responding error.

Privacy and Logging

Your ISP already sees the IP addresses you connect to, but plain DNS also shows them every hostname you look up, which some ISPs log or use for analytics. Switching resolvers alone does not hide that traffic — standard DNS is unencrypted — but combining a public resolver with encrypted DNS does. That is a privacy decision as much as a performance one.

Transparent DNS Interception

Some ISPs redirect all port 53 traffic to their own resolvers regardless of what you configure. If you set 1.1.1.1 but whoami.akamai.net still returns an ISP address, your queries are being intercepted. Encrypted DNS (DoH or DoT) is the practical way around this.

When Your ISP's Resolver Is the Better Choice

Switching is not automatically an upgrade. ISP resolvers have real advantages:

1. Proximity. They are often inside your ISP's network, a few milliseconds away, while the nearest public resolver node may be further.
2. CDN mapping. CDNs pick an edge server based on the resolver's location. An ISP resolver located in your region can lead to well-placed CDN edges, while a public resolver that does not send EDNS Client Subnet might occasionally route you to a less optimal location.
3. ISP-specific services. Some ISPs use DNS for features like account portals, parental controls, or IPTV, which may stop working with another resolver.

If your measurements show the ISP resolver is fast, does not hijack NXDOMAIN, and validates DNSSEC, there is no performance reason to change.

Keep Expectations Realistic

Even a clearly slower resolver only costs time on the first lookup of each hostname. Your operating system and browser cache answers for their TTLs, so repeat visits and subsequent page loads usually skip DNS entirely. Switching resolvers will not fix slow Wi-Fi, limited bandwidth, a congested ISP backbone, or a slow website. A DNS caching layer on your own network — a router with a decent cache or a local resolver — often helps as much as changing the upstream.

If testing does show a meaningful improvement, the most effective place to make the switch is on the router so every device benefits at once. The guide to changing DNS servers on your router covers that, including how to avoid IPv6 quietly keeping you on the ISP resolver.

---

ISP DNS FAQ

Conclusion

Your ISP's default DNS server might be slowing you down, or it might be the fastest option you have — the only way to know is to measure it from your own connection. Identify the resolver actually handling your queries, compare cached and uncached lookup times against a few alternatives at different times of day, and log failures over a day if you suspect reliability problems. Pay just as much attention to behaviour: NXDOMAIN hijacking, missing DNSSEC validation, and intercepted queries are often stronger reasons to switch than a few milliseconds.

If the data says your ISP resolver is fine, keep it. If it says otherwise, change it on the router, consider encrypted DNS for privacy, and run the same tests again to confirm the switch actually helped.

Here are some useful references for testing and understanding resolver behaviour:

1. RFC 8499: DNS Terminology — precise definitions of recursive resolvers, NXDOMAIN, and related terms.
2. RFC 7871: Client Subnet in DNS Queries — how resolvers pass location hints to CDNs, and why resolver location affects routing.
3. Cloudflare Learning Center: What is DNS? — background on resolvers, caching, and the lookup process.
4. ISC: BIND 9 documentation — includes the dig reference used for the tests in this article.
5. Microsoft Learn: Get-DnsClientServerAddress — reference for checking DNS servers on Windows.