DNS Troubleshooting Guide

When a user reports they "cannot access the internet," the issue is frequently not a network connectivity failure, but a DNS failure. A solid DNS troubleshooting methodology prevents engineers from wasting time investigating routers and firewalls when the network is completely healthy.

DNS Failure vs Connectivity Failure

The most critical first step is isolation. If a user cannot open example.com, ask them to ping a known public IP address, such as 8.8.8.8.

• If the IP ping fails: The computer has no internet access. Check the physical link, DHCP, default gateway, and Firewall. Do not troubleshoot DNS.
• If the IP ping succeeds, but the hostname fails: The network is delivering packets perfectly. The computer simply cannot translate the human-readable name into an IP address. You have a DNS failure.

Common DNS Symptoms

• One User Affected: Often points to a local PC issue, a static IP misconfiguration, or a corrupted local DNS cache.
• Whole VLAN Affected: Often points to a DHCP server handing out the wrong DNS server addresses to that specific subnet.
• Internal Name Fails, Public Name Works: The client is likely using an external DNS server (like 8.8.8.8) instead of the internal corporate Domain Controller, breaking Split DNS resolution.
• Intermittent Resolution: Often caused by having two DNS servers configured (Primary and Secondary) where one is healthy and the other is dead. The PC alternates between them, causing random timeouts.

Practical Troubleshooting Sequence

1. Verify IP Connectivity: Confirm the PC can ping the internet (e.g., ping 8.8.8.8).
2. Check DNS Configuration: Verify which DNS servers the client is actually using. Are they the correct internal servers? Is the DNS Suffix/Search Domain correct?
3. Resolve Known Hostname: Attempt to resolve a standard name. Does it fail completely, or does it resolve to the wrong IP?
4. Query Specific Resolver: Bypass the local OS cache and force a query to a specific DNS server (e.g., query the internal server directly).
5. Check Returned Record: If the resolution succeeds, is it an A Record? A CNAME? (DNS Record Types).
6. Check Cache: The authoritative server might be updated, but the local PC or the intermediate recursive resolver might be holding onto a stale cached record.
7. Check Firewall / Network Path: Standard DNS uses UDP Port 53. Large responses (like DNSSEC or massive zone transfers) use TCP Port 53. Ensure the firewall permits both.
8. Check Authoritative Side: If you manage the domain, verify the records exist on the authoritative nameserver.
9. Verify After Change: Clear the local cache and test again.

Useful Diagnostic Commands

Windows

Linux

Note: Linux DNS resolution depends heavily on the distribution (systemd-resolved, NetworkManager, etc.). Do not assume one tool works everywhere.