Why DNS Works on One Device but Not Another
After updating a DNS A or CNAME record, an engineer observes that the website loads instantly on their mobile phone over cellular data, but their office laptop continues returning an old IP address or fails to connect with DNS_PROBE_FINISHED_NXDOMAIN. Even within the same local network, different operating systems or browsers may resolve completely different records.
DNS_PROBE_FINISHED_NXDOMAIN or ERR_NAME_NOT_RESOLVED (Device A: Resolves to 198.51.100.1; Device B: Resolves to 203.0.113.5).Why does Why DNS Works on One Device but Not Another occur?
Primary Root Cause
DNS resolution is decentralized and hierarchical. There is no single central server that updates all client devices simultaneously. When a DNS record changes, every intermediate resolver (client OS, home router, ISP resolver, CDN, enterprise gateway) holds the old record until its configured TTL counter counts down to zero.
Device A might be using cellular LTE with a direct query to Cloudflare (1.1.1.1) which already purged the cache, while Device B is connected to a home Wi-Fi router running dnsmasq with an unexpired 86400-second (24 hour) TTL cache. Furthermore, Chrome may have "Secure DNS" enabled using Google DNS (8.8.8.8) while the OS terminal uses the local DHCP server.
How to Confirm You Are Facing This Exact Issue
Site loads smoothly on 4G/5G mobile, but returns "Server IP address could not be found" on office Wi-Fi.
Terminal ping resolves to the old server IP, but an online DNS lookup tool shows the new server IP.
Different browsers on the same machine display different content (Chrome works via DoH, Safari fails via system DNS).
Colleagues in different geographic locations see divergent website environments.
Explicit Diagnostic Reasoning
Execute these diagnostic tests to locate whether the discrepancy is caused by the OS cache, the upstream resolver, or browser DoH:
"If the domain resolves on mobile cellular data but fails on home/office Wi-Fi"
Your local Wi-Fi router or ISP resolver is caching the old DNS record until the previous TTL expires.
→ Change your Wi-Fi DNS settings to 1.1.1.1 or 8.8.8.8, or reboot the local router to clear its resolver cache.
"If the domain resolves in Google Chrome but fails in terminal ping or curl on the same computer"
Chrome has Secure DNS (DNS-over-HTTPS) enabled, bypassing your operating system resolver.
→ Compare "chrome://net-internals/#dns" with "nslookup <domain>" in your terminal.
"If nslookup using 1.1.1.1 returns the correct IP but default nslookup returns NXDOMAIN or an old IP"
Your network adapter is configured with an unresponsive or out-of-sync local DNS server.
→ Update network adapter IPv4/IPv6 DNS settings to use reliable public resolvers.
"If ping returns 127.0.0.1 or a private IP regardless of the external DNS records"
A hardcoded override exists in your local hosts file (/etc/hosts or C:\Windows\System32\drivers\etc\hosts).
→ Inspect and clean outdated entries from your system hosts file.
Forces query against Cloudflare’s public resolver, isolating whether the authoritative record is published versus cached by your local ISP.
Long-Term Engineering Solution
Isolate the failing layer (browser cache, OS resolver, router cache, or ISP resolver) and purge stale caches or standardize resolver configurations across devices.
Architectural Pattern
During DNS migrations, lower the record TTL to 300 seconds (5 minutes) at least 24 hours in advance so intermediate resolvers purge old records rapidly.
How do you fix this step-by-step?
Query Authoritative Nameservers Directly
Verify that the new DNS record is actually published on the authoritative nameservers for your domain.
# Find the authoritative nameservers
nslookup -type=ns example.com
# Query the authoritative nameserver directly
dig @ns1.yourdnsnameserver.com example.com +shortFlush the Local Operating System DNS Cache
Clear the client OS resolver cache on the failing device to force an immediate network query.
# Windows PowerShell / CMD (Run as Administrator)
ipconfig /flushdns
# macOS (Terminal)
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo resolvectl flush-cachesClear Browser DNS and Socket Cache
Modern browsers maintain an internal socket and DNS pool independent of the operating system.
Chrome / Edge:
Navigate to chrome://net-internals/#dns and click "Clear host cache".
Navigate to chrome://net-internals/#sockets and click "Flush socket pools".
Firefox:
Navigate to about:networking#dns and click "Clear DNS Cache".Check and Clean the Hosts File
Ensure no developer staging or mock IPs remain mapped in the operating system hosts configuration.
# Linux / macOS:
sudo nano /etc/hosts
# Windows:
# Open Notepad as Administrator -> C:\Windows\System32\drivers\etc\hosts
# Remove any conflicting lines referencing your domain.What are common misconceptions and mistakes when fixing this?
Changing DNS records without lowering the existing TTL beforehand.
Ursache des Fehlers: If the old record had a TTL of 86400 (24 hours), downstream resolvers are legally allowed to serve the old IP for a full 24 hours, regardless of changes on the authoritative server.
✓ Korrekte Alternative: Lower TTL to 300 seconds 24 to 48 hours prior to the migration, then revert to 3600 after successful rollout.
Assuming "ipconfig /flushdns" clears Chrome or Firefox browser DNS cache.
Ursache des Fehlers: Chrome and Firefox with DNS-over-HTTPS (DoH) maintain private application-level DNS caches that do not listen to OS flush signals.
✓ Korrekte Alternative: Clear browser sockets and host cache via chrome://net-internals/#dns or restart the browser.
Testing propagation using the local router gateway IP (192.168.1.1).
Ursache des Fehlers: Home routers often run lightweight DNS caches that do not refresh until restarted.
✓ Korrekte Alternative: Use external diagnostic tools or query 1.1.1.1 and 8.8.8.8 explicitly.
Can this fix introduce security vulnerabilities?
DNS discrepancy can be a symptom of malicious DNS hijacking, cache poisoning, or misconfigured split-horizon networks.
Security Risks If Ignored
- •DNS Spoofing / Cache Poisoning: Users on compromised Wi-Fi networks may be routed to phishing clone sites.
- •Split-Horizon Leakage: Internal development IP addresses exposed to public queries or vice-versa.
- •Man-in-the-Middle (MitM): Insecure UDP DNS can be intercepted and altered in transit.
Hardening Best Practices
- ✓Deploy DNSSEC (DNS Security Extensions) to cryptographically sign DNS records and prevent spoofing.
- ✓Enforce DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) on enterprise workstations.
- ✓Regularly audit authoritative zone files to prune dangling CNAME records (subdomain takeover prevention).
Comparing Resolvers in Terminal vs Direct Authoritative Query
# Querying default local router resolver (Stale cache response)
$ nslookup app.example.com
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: app.example.com
Address: 203.0.113.5 <-- OLD DEPRECATED SERVER IP (Cached for 14 hours remaining)# Querying authoritative nameserver directly
$ dig @ns1.cloudflare.com app.example.com +short
198.51.100.1 <-- NEW PRODUCTION SERVER IP (Live authoritative state)
# Testing via public DoH resolver
$ curl -s "https://cloudflare-dns.com/dns-query?name=app.example.com&type=A" -H "accept: application/dns-json" | jq .Answer
[
{
"name": "app.example.com",
"type": 1,
"TTL": 300,
"data": "198.51.100.1"
}
]Frequently Asked Questions About Why DNS Works on One Device but Not Another
Why does my phone on 5G see the new site immediately while my PC does not?↓
Cellular network providers have high-volume recursive resolvers that refresh rapidly, whereas home router DNS caches obey the maximum TTL duration.
Mobile operators handle billions of queries and frequently refresh popular records. Home routers running dnsmasq keep records in memory until the original TTL countdown strictly reaches zero or the router reboots.
How long does DNS propagation really take?↓
DNS does not "propagate"; it expires. The delay is exactly equal to the TTL value set on the previous record (typically 5 minutes to 24 hours).
Whenever a resolver queries a domain, it stores the record with a countdown timer (TTL). Until that timer hits zero, the resolver will not ask the authoritative server again. If your old TTL was 86400, it takes 24 hours for every resolver on the internet to refresh.
Does clearing browser history clear DNS cache?↓
No, clearing standard browsing history, cookies, and cache does not flush the browser’s internal DNS resolution table.
Browsers maintain a dedicated internal socket and hostname cache. In Chromium browsers, you must visit chrome://net-internals/#dns and chrome://net-internals/#sockets to flush them, or completely close and reopen all browser processes.