How DNS Problems Mimic Connectivity Problems
DNS translates domain names like google.com into IP addresses that computers can route to. When DNS is broken or slow, websites appear to fail — pages do not load, apps time out, and the internet seems down — even though the underlying connection is completely functional. This is one of the most common sources of “my internet is broken” reports that turns out to be a five-second fix.
The diagnostic key is simple: if you can reach a website by its IP address but not by its domain name, DNS is the problem. If you cannot reach anything regardless of whether you use a name or an IP, the connectivity problem is deeper than DNS.
Step 1: Test IP vs Domain Access
The fastest way to isolate DNS is to bypass it entirely and connect to a known IP directly:
# Test connectivity to a raw IP (Google's public DNS server)
# If this works, your network connection is functional
ping 8.8.8.8
ping 1.1.1.1
# Test the same destination by domain name
# If this fails while the IP ping works, DNS is the problem
ping google.com
ping cloudflare.comIf the IP pings succeed and the domain pings fail (or time out with “cannot resolve host”), you have confirmed DNS is the failure point.
Step 2: Test Your DNS Server Directly
Use dig (Mac/Linux) or nslookup (Windows) to query your current DNS server and see its response time:
# macOS / Linux — query your default resolver
dig google.com
# Query a specific DNS server (Cloudflare 1.1.1.1)
dig @1.1.1.1 google.com
# Query Google's DNS instead
dig @8.8.8.8 google.com
# Windows equivalent
nslookup google.com # uses default resolver
nslookup google.com 1.1.1.1 # uses CloudflareLook at the “Query time” at the bottom of the dig output. Under 50ms is normal. Over 500ms indicates a slow or struggling DNS server. If your default resolver times out but querying 1.1.1.1 works fine, your ISP's DNS server is the problem.
Step 3: Check What DNS Server You Are Using
# macOS
scutil --dns | grep nameserver | head -5
# Linux (systemd)
resolvectl status
# Windows
ipconfig /all | findstr “DNS Servers”Most home routers give themselves as the DNS server (192.168.1.1 or similar) and forward queries to your ISP's resolvers. If your DNS shows the router's IP, it is acting as a relay — the actual resolver is your ISP's server. To test whether the ISP's server is the weak link, temporarily change your DNS to a public resolver and retest.
Step 4: Switch DNS and Retest
| DNS Provider | Primary | Secondary | Characteristic |
|---|---|---|---|
| Cloudflare | 1.1.1.1 | 1.0.0.1 | Fastest average query time in most regions; strong privacy policy |
| 8.8.8.8 | 8.8.4.4 | Highly reliable; good uptime; queries used for Google analytics | |
| Quad9 | 9.9.9.9 | 149.112.112.112 | Blocks known malicious domains automatically |
| OpenDNS | 208.67.222.222 | 208.67.220.220 | Customizable filtering; parental control options |
Change DNS on your router's admin page (usually under WAN or Internet settings → DNS server) to affect all devices at once. After changing, flush your DNS cache: on macOS, run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder; on Windows, ipconfig /flushdns. Then retest.
Common DNS Problem Patterns
| Symptom | Likely Cause | Fix |
|---|---|---|
| Pages load by IP, fail by domain | DNS resolver is down or unreachable | Switch to Cloudflare (1.1.1.1) or Google (8.8.8.8) |
| Pages load very slowly but eventually | DNS resolver is overloaded or slow | Switch to faster public resolver; check router DNS relay settings |
| Some sites fail, others work fine | Specific domain not resolving (DNSSEC failure, expired TTL) | Try dig against multiple resolvers; if results differ, the domain has DNS issues on the authoritative side |
| Internet works on mobile data, fails on Wi-Fi | Router's DNS relay is broken; or ISP DNS is down for that connection | Change router's DNS servers; reboot router |
| Works on one device, fails on another | Device-specific DNS cache or settings | Flush DNS cache on failing device; check device's network settings for manual DNS override |
Frequently Asked Questions
Will changing DNS make my internet faster?
It can make page load initiation faster by reducing the time it takes to resolve domain names. Typical gains from switching from a slow ISP resolver to Cloudflare or Google are 20–200ms per DNS lookup, which is noticeable when a page requires many DNS resolutions (ads, CDN resources, analytics). It does not affect download speeds or latency once a connection to the server is established — DNS only affects the initial name resolution step. In regions where ISP DNS is particularly slow or unreliable, the improvement can be significant.
How do I know if my ISP's DNS is the problem versus the internet connection?
The test is: ping 1.1.1.1 directly (using the IP, bypassing DNS). If that ping succeeds with normal latency, your internet connection is working. If dig or nslookup to your ISP's resolver times out but dig @1.1.1.1 works, your ISP's DNS server is having a problem, not your connection. Switch to a public resolver temporarily and the problem will likely resolve immediately.
Does my router need to be rebooted after changing DNS?
No, but devices connected to the router need to release and renew their DHCP lease to get the new DNS settings. The quickest way is to disconnect and reconnect the device to Wi-Fi, or run ipconfig /release then ipconfig /renew on Windows. If you changed DNS directly on the router's WAN settings (pointing the router itself to a different upstream resolver), connected devices typically do not need to reconnect because the router is still acting as their DNS relay.
Why does DNS affect only some websites?
DNS resolution problems can be domain-specific when the issue is with a particular authoritative name server rather than your resolver. If google.com resolves fine but another domain fails, the problem is on that domain's DNS infrastructure (their name servers are down or misconfigured), not your DNS resolver or connection. Verify by querying multiple resolvers: dig @1.1.1.1 example.com and dig @8.8.8.8 example.com. If both fail, the problem is the domain's authoritative server. If one works and the other fails, it is a resolver propagation or caching issue.