DNS resolution problems can manifest in confusing, seemingly unrelated ways — this guide provides a systematic step-by-step troubleshooting approach for isolating and resolving DNS issues.
Why Systematic Troubleshooting Matters
DNS issues can originate at many different layers (local resolver configuration, upstream DNS server, network connectivity, DNS record configuration itself) — a systematic approach isolates which layer is actually the problem rather than guessing.
Step 1 — Verify Basic Network Connectivity First
ping 8.8.8.8Rule out a basic connectivity problem before assuming DNS specifically is the issue — if you can't reach an IP directly, DNS resolution failure is a downstream symptom, not the root cause.
Step 2 — Test DNS Resolution Directly
nslookup yourdomain.com
dig yourdomain.comdig provides more detailed output, generally preferred for genuine troubleshooting over the simpler nslookup.
Step 3 — Test Against a Specific, Known-Good DNS Server
dig @8.8.8.8 yourdomain.comExplicitly querying Google's public DNS (or another known-reliable resolver) bypasses your system's configured resolver entirely — if this succeeds while your default resolution fails, the problem is likely in your local DNS configuration, not the domain's actual DNS records.
Step 4 — Check Your System's Configured DNS Servers
cat /etc/resolv.confVerify your system is actually configured to use the DNS servers you expect — a misconfigured or unreachable resolver here is a common, simple root cause.
Step 5 — Verify the Domain's Actual DNS Records
dig yourdomain.com NS
dig yourdomain.com AConfirm the domain's authoritative nameservers are correctly configured, and that the specific record type you need (A, AAAA, CNAME) actually exists and has the expected value.
Step 6 — Check for DNS Propagation Delay (Recent Changes)
See Understanding DNS Propagation and TTL — if you've recently changed DNS records, some resolvers worldwide may still have cached the old value until TTL expiration; this is expected temporary behavior, not necessarily a genuine misconfiguration.
Step 7 — Check for Local DNS Caching Issues
sudo systemd-resolve --flush-cachesLocal DNS caching (systemd-resolved, or application-level caching) can sometimes hold onto stale results longer than expected — flushing local caches rules this out as a factor.
Step 8 — Check for Firewall Blocking DNS Traffic
sudo ufw statusVerify outbound DNS traffic (typically UDP/TCP port 53) isn't being blocked by an overly restrictive firewall configuration — a less common but genuine possible cause, particularly after recent firewall configuration changes.
Step 9 — Check for DNSSEC Validation Failures
dig +dnssec yourdomain.comIf DNSSEC is enabled for the domain, a misconfiguration can cause validating resolvers to reject the response entirely — check for DNSSEC-related errors specifically if standard troubleshooting steps don't reveal the issue.
Step 10 — Test from a Genuinely Different Network
If the issue is only reproducible from one specific network/location, this points toward something network-specific (a local ISP DNS issue, a specific firewall) rather than a genuine problem with the domain's DNS configuration itself.
Continue Reading
- Understanding DNS Propagation and TTL
- How to Set Up a VPS as a DNS Server with BIND9
- How to Diagnose and Fix High Network Latency
Browse more articles in Advanced Networking & VPN.
