When a user says “the internet is down,” the fault is a name resolution problem more often than a routing problem. The Domain Name System sits between every application and the IP address it needs, so a single broken NS record, a stale cache entry, or a firewall dropping TCP port 53 can take down mail flow, VPN tunnels, and web apps at once while ping to 8.8.8.8 still works fine.
To troubleshoot DNS issues efficiently, work outward in layers: confirm the network path first, then the client cache and resolver config, then the specific records the affected service queries, and only then the authoritative nameservers and delegation. That order keeps you from flushing caches on twelve workstations when the real problem is a missing glue record at the registrar.
The tools at PacketTools were built for exactly this workflow, run from browser sessions during live incidents where a second opinion from outside your network settles an argument in about ten seconds. Nothing is logged, nothing needs a sign-in, and the output is plain enough to paste into a ticket.
How to Tell DNS From a Network Connectivity Fault
Split the fault domain in the first sixty seconds by testing an IP address directly. If ping 1.1.1.1 succeeds but ping cloudflare.com returns “could not find host,” you have a DNS failure, not a network connectivity fault. The error string your resolver returns, NXDOMAIN versus SERVFAIL versus a timeout, tells you which layer to open next.
Recognize Resolver Failures, NXDOMAIN, and SERVFAIL
NXDOMAIN means an authoritative server answered and told you the name does not exist. That points at a typo, a deleted record, or a search-domain suffix being appended to your query.
SERVFAIL means the resolver tried and could not complete the lookup. Common causes include DNSSEC validation failures, unreachable authoritative nameservers, and expired zone data on a secondary.
A timeout (“Request to server timed out” or “No response from server”) means the query never got an answer at all. Microsoft’s guidance on troubleshooting DNS servers notes this often means the DNS service is not running, or the server is not listening on the IP you queried.
Confirm Routing Before Changing DNS Settings
Run ipconfig /all on Windows or ip addr on Linux and verify the IP addresses, subnet mask, and default gateway are what you expect. A wrong subnet mask produces symptoms that look identical to DNS failure.
Then trace the path with tracert 1.1.1.1 on Windows or traceroute 1.1.1.1 on Linux. If the trace dies at hop two, stop touching resolver settings. A quick ping test from outside your network confirms whether the target is reachable at all.
Check IPv6 separately. Dual-stack hosts that get a broken IPv6 default route will hang on AAAA lookups before falling back to IPv4, which reads as “slow DNS” to users.
Compare Results Across Devices and Networks
Query the same name from three vantage points: the affected host, a second machine on the same VLAN, and a device on a cellular hotspot. One failing host means client config or cache. An entire VLAN failing means the resolver or a firewall rule. Everything failing everywhere means the zone itself.
Isolate the Resolver, Cache, or Client Configuration
Once routing checks out, the next three candidates are the configured DNS resolver, the local DNS cache, and the adapter’s IP configuration. A side-by-side query against your internal DNS server and a public DNS resolver separates the first from the other two in one command.
Query the Configured Resolver and Public DNS Side by Side
Run the same lookup against your resolver and a public one:
nslookup example.com 10.0.0.1
nslookup example.com 8.8.8.8
dig @1.1.1.1 example.com A
If 8.8.8.8, 1.1.1.1, or 9.9.9.9 answers correctly and your internal server does not, the problem is your resolver, its forwarders, or its recursion path. When both fail identically, move up to the authoritative layer.
Keep the secondary resolvers handy: Google Public DNS uses 8.8.8.8 and 8.8.4.4, Cloudflare uses 1.1.1.1 and 1.0.0.1. Testing both members of a pair catches a single dead primary DNS server.
Flush Stale or Corrupted Local DNS Cache Entries
DNS cache corruption produces the classic “works everywhere except this one laptop” symptom. Clear it by platform:
- Windows:
ipconfig /flushdns, orClear-DnsClientCachein PowerShell - macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Linux (systemd):
sudo systemd-resolve --flush-cachesorsudo resolvectl flush-caches - Windows DNS Server role:
dnscmd /clearcacheorClear-DnsServerCache
Inspect before you flush. ipconfig /displaydns shows what the client believes, and a wrong entry there is evidence worth capturing in the ticket.
Verify DHCP, Adapter Settings, and Resolver Order
Confirm which servers the client was handed. ipconfig /all on Windows lists the DNS servers per adapter; on Linux, read /etc/resolv.conf (or resolvectl status on systemd hosts).
Watch for a hard-coded public resolver on a domain-joined machine. That breaks internal name resolution while external lookups work perfectly, which is a maddening ticket to inherit. Resolver order matters too: Windows queries the first entry and only fails over after a timeout, so a dead primary adds seconds to every lookup.
Resolve-DnsName example.com -Server 10.0.0.1 -Type A gives cleaner structured output than nslookup for scripting these checks across a fleet.
Query the Records That the Affected Service Needs
Query the exact record type the broken service depends on, because a healthy A record tells you nothing about why mail is bouncing. Web traffic needs A, AAAA, and often CNAME records; mail needs MX plus TXT records for SPF; and the TTL in every answer tells you how long a bad value will linger.
Use nslookup and Dig to Test Specific Record Types
Set the query type explicitly:
nslookup -type=MX example.com 8.8.8.8
nslookup -type=TXT _dmarc.example.com
dig example.com MX +short
dig example.com TXT +short
dig www.example.com CNAME
For a full picture in one call, dig example.com ANY still works against some servers, though most modern resolvers refuse it. Query record types individually and you avoid the ambiguity.
Add +norecurse when you want to see only what a server holds in cache or authoritatively, with no upstream lookup.
Interpret Answers, Authority Data, and TTL Values
Read the dig header first. status: NOERROR with ANSWER: 0 means the name exists but has no record of that type, which is a different problem from NXDOMAIN.
The flags: line carries aa when the response is authoritative. No aa flag means you got a cached copy, and the TTL counting down in the answer section shows how much of the original lifetime remains.
A TTL of 3600 on a record you changed four minutes ago means resolvers will keep serving the old value for another 56 minutes. Lower TTLs to 300 before planned cutovers, not during them.
Check Website, Email, and IPv6 Records Separately
Test AAAA records independently of A records. A dual-stack client that gets a stale or wrong AAAA record will fail while every IPv4-only test passes.
For mail, verify the MX hostnames resolve to reachable IP addresses, then confirm the SPF record is a single TXT string starting with v=spf1. Two SPF records on one domain is a permanent error, and it is one of the most common findings when running an all-in-one check with the PacketTools SuperTool against a domain that “used to work.” Microsoft 365 tenants have their own record set worth checking with a dedicated M365 domain checker.
Trace Delegation and Authoritative DNS Failures
When every resolver you test returns SERVFAIL, the fault lives at the authoritative layer, and dig +trace walks the resolution path from the root servers down to the zone so you can see exactly which hop breaks. Broken delegations, missing glue records, and mismatched NS records between the registrar and the DNS provider all surface in that output.
Follow the Resolution Path With dig +trace
dig +trace example.com
dig +trace +additional example.com
The output shows each referral: root, then the TLD servers, then the nameservers your registrar has on file. A trace that stops at the TLD level with no referral means the parent zone has no delegation for your domain.
On Windows, replicate the same walk in nslookup with set norecursion and set querytype=NS, querying each server the previous level referred you to.
Validate NS Records, Glue, and Broken Delegations
Compare what the parent publishes against what the zone itself publishes:
dig @a.gtld-servers.net example.com NS
dig @ns1.example.com example.com NS
Any mismatch is a delegation defect. A “FAIL” on a delegation test typically indicates that the parent DNS zone does not contain a proper delegation record pointing at the child domain’s authoritative nameservers.
Glue records matter when nameservers live inside the zone they serve. Without an A record for ns1.example.com in the parent, resolution loops. Also confirm every NS record resolves to a reachable address, because one dead nameserver out of four produces intermittent failures that come and go by resolver.
Separate DNS Propagation Delays From Incorrect Zone Data
Propagation is TTL expiry, not a mysterious internet-wide sync. If the authoritative server already returns the new value and a public resolver returns the old one, wait out the TTL. If the authoritative server returns the old value, the zone edit never saved.
Check both at once with a DNS propagation checker that queries resolvers in multiple regions. Consistent old answers everywhere plus a correct authoritative answer confirms caching; scattered results point at a nameserver out of sync with its peers. Comparing SOA serials across all authoritative servers settles that question definitively.
Repair Server-Side and Transport-Layer Problems
Server-side DNS problems cluster around three things: blocked port 53 traffic, a stopped or misbound DNS service, and zone data that never transferred. Firewall rules that permit UDP but drop TCP break large responses and zone transfers while small lookups keep working, which makes the failure look intermittent.
Allow DNS Traffic on UDP and TCP Port 53
Open both. UDP port 53 carries standard queries; TCP port 53 handles responses too large for a single UDP datagram and all zone transfers.
Test each transport separately:
dig @10.0.0.1 example.com A
dig @10.0.0.1 example.com A +tcp
If the UDP query works and the TCP one hangs, you found the rule. Microsoft’s server guidance points at exactly this scenario, noting that an intermediate packet-filtering router or proxy can force a DNS server onto a non-standard port and break nslookup, which sends to UDP 53 by default.
Also confirm nothing upstream is intercepting and rewriting DNS, a common ISP behavior that silently answers NXDOMAIN queries with a search page.
Check Windows Server and BIND Service Health
On Windows Server, start with the Application, System, and DNS Server event logs. A “Server failure” or “Query refused” response to an nslookup usually means the zone is paused, which shows on the General tab of the zone properties in the DNS console.
Restart the service with net start DNS when nslookup reports a timeout. Then check the Interfaces tab: an administrator can restrict the server to selected addresses, and querying an address outside that list fails silently.
For BIND, run named-checkconf and named-checkzone example.com /var/named/example.com.zone before reloading, then watch /var/log/messages or the journal for load errors.
Correct Zone Transfers, Forwarding, and Hosts File Overrides
Compare serial numbers between primary and secondary. When the primary’s serial is less than or equal to the secondary’s, the transfer will never fire; bump the primary and force a refresh with dnscmd /zonerefresh corp.contoso.com.
Check the Forwarders tab in the DNS console. A forwarder pointing at a decommissioned resolver produces timeouts on every external name while internal lookups succeed.
Then check the hosts file. C:WindowsSystem32driversetchosts or /etc/hosts overrides DNS entirely, and a leftover line from a migration test is a real root cause you will find more than once.
Make DNS Failures Faster to Diagnose Next Time
Work the layers in order and most DNS troubleshooting collapses into a few commands: confirm the path with ping and traceroute, split client from resolver by querying 8.8.8.8 or 1.1.1.1 alongside your internal server, pull the specific record type the broken service needs, then walk dig +trace down to the authoritative nameservers when everything else checks out.
Keep the evidence. A dig header showing status: SERVFAIL, a TTL still counting down on a record you changed, or a serial mismatch between primary and secondary turns a vague ticket into a fix.
DNS monitoring closes the loop by catching zone changes and nameserver drift before users call. Between incidents, the PacketTools DNS lookup and network tools give you an outside-the-firewall view of what the rest of the internet sees, and the broader network troubleshooting material covers the latency, TLS, and email-deliverability paths that DNS resolution feeds into.