Support Library

Why does DNS work on one network but not another?

Why a domain resolves on one network but not another: find each network's resolver, compare answers, and test DNSSEC, filtering and caching differences.

Author
CategoryDNS Troubleshooting Playbooks
Length5 minute read
UpdatedOctober 24, 2026

The short answer

When a name resolves on one network but not another, the difference often involves resolvers or their paths, but a domain-side DNSSEC, delegation or authoritative reachability fault may affect only one of them. Each network hands its devices a different recursive resolver, and resolvers differ in what they have cached, whether they validate DNSSEC, what they filter, and how they reach the internet. Find out which resolver each network uses, ask both the same question, and compare.

$ dig @192.0.2.53 www.example.com A

$ dig @1.1.1.1 www.example.com A

Replace 192.0.2.53 with the resolver the failing network gave you. If the public resolver answers and the local one does not, investigate the local resolver and its upstream path. Also compare DNSSEC validation, delegation, authoritative instances and transport reachability before attributing the fault to the local network.

Step 1: find the resolver each network uses

SystemCommand
Windows (PowerShell)Get-DnsClientServerAddress
Windows (Command Prompt)ipconfig /all
macOSscutil --dns
Linux with systemd-resolvedresolvectl status
Other Linux and BSDcat /etc/resolv.conf

Also check for things that bypass those settings. A browser may use its own DNS over HTTPS resolver, a VPN client may install its own resolver or send some domains to a corporate server (split DNS), and some networks intercept all port 53 traffic whatever you configure. The Split-Brain DNS article covers networks that deliberately give different answers inside and outside.

Step 2: compare the answers

Run the same query against the failing network's resolver and a public one, and note the status line, the flags and the answer.

What differsMost likely causeNext check
Local resolver returns SERVFAIL, public one answersThe local resolver validates DNSSEC and the domain's signatures are broken, or it cannot reach the domain's name serversThe DNSSEC test in step 3
Local resolver returns NXDOMAIN or a block page addressFiltering, such as a DNS firewall or parental controlLook for an Extended DNS Error such as 15 (Blocked) or 17 (Filtered), and ask the network owner
Local resolver returns an older addressA cached answer from before a recent changeCompare the TTL with the record's TTL, and wait or flush that cache
Local resolver times outThe resolver is down, or the network blocks DNS to itTry +tcp, and try another resolver from the same network
Different addresses, both workNormal for CDNs and GeoDNS, which answer by locationNone, unless one address is unreachable from that network
Same DNS answer on both networksThat queried RRset matches; other names, address families or DNS paths may still differTest the connection itself, for example with traceroute

Step 3: test DNSSEC properly

Adding +dnssec to a query asks for signatures; it does not validate them. To tell whether validation is the difference, ask the resolver that fails the same question with and without checking disabled:

$ dig @192.0.2.53 www.example.com A +dnssec

$ dig @192.0.2.53 www.example.com A +dnssec +cdflag

$ delv www.example.com A

If the normal query returns SERVFAIL but the +cdflag query answers, that is strong evidence of a validation problem. It does not establish why another network succeeds: caches, trust anchors and resolver policy can differ. Inspect Extended DNS Errors and use delv or DNSViz to locate the failing link. See DNS SERVFAIL Explained.

Other network differences

  • IPv6: on an IPv6-only or dual-stack network, a resolver may reach a domain's name servers over IPv6. If the servers' IPv6 addresses do not answer, only those networks fail.
  • Large responses: DNSSEC-signed answers can be large. Networks that drop fragmented UDP or block DNS over TCP fail on those names only. See EDNS and TCP Fallback.
  • Captive portals: hotel and guest networks often answer every query with the portal's address until you sign in.
  • Search domains: a short name such as intranet may resolve only on a network whose DHCP settings add the right search suffix.

Fixing it

If the domain is at fault, fix it at the source: correct the DNSSEC chain, repair the name servers that do not answer, or allow DNS over TCP. Changing your own devices to a different resolver only hides the problem from you. If the network is at fault, the fix belongs to whoever runs its resolver: flush the cache, correct the forwarding rules, or adjust the filtering policy. Record which networks use which resolvers, so the next comparison takes minutes.

How DNS Panopticon helps

Domain Visualizer shows what large public resolvers return for the domain, which gives you the "outside" answer to compare against. Its lookups run from DNS Panopticon's servers, so it cannot see your local resolver, VPN or network filtering. The comparison in step 2 has to be run from the network that fails.

Sources and further reading