Why does everything break when DNS breaks?

Users can’t access websites. Email stops flowing. Authentication fails. Applications time out. The entire infrastructure feels like it’s collapsing—even though every server is up, every cable connected, every firewall rule unchanged.

DNS is the silent dependency that most IT infrastructure assumes will just work. When it doesn’t, the symptoms look like everything else is failing. That misdirection sends IT teams chasing ghosts through network configs, firewall logs, and application settings while the actual problem sits quietly in the name resolution layer.

If you’ve ever spent an hour troubleshooting a “network outage” only to discover it was a DNS issue, you understand the frustration. This guide gives you the diagnostic process to identify DNS problems quickly and the tools to fix them before users start forming a line at your desk.

Why DNS Problems Disguise Themselves

DNS sits at the foundation of almost every network request. Your browser doesn’t connect to google.com—it connects to an IP address that DNS provided. Your email client doesn’t send mail to a domain—it first asks DNS where that domain’s mail servers live. Your authentication system, your cloud services, your internal applications: they all start with DNS queries.

When DNS fails, applications don’t display “DNS Error.” They show generic messages: “Unable to connect,” “Request timed out,” “Server not found.” Those messages trigger instincts to check connectivity, firewalls, application configurations—anywhere except the actual problem.

This is why a single DNS failure during the October 2025 AWS outage paralyzed over 3,500 companies across 60+ countries. The servers were fine. The networks were fine. But without DNS resolution, nothing could find anything else.

Understanding DNS troubleshooting separates reactive IT professionals from those who diagnose problems efficiently. If you’re building your networking fundamentals, DNS skills belong near the top of your priority list.

The First Question: Is It Actually DNS?

Before diving into DNS tools, confirm that DNS is actually the problem. This takes thirty seconds and saves hours of misdirected troubleshooting.

The IP Address Test

Try accessing a resource by IP address instead of hostname. For external sites, you can use known IP addresses:

ping 8.8.8.8

If ping succeeds by IP but fails by hostname, you’ve confirmed a DNS problem. If ping fails by IP too, the issue is network connectivity—not DNS.

For internal resources, find the server’s IP address from your documentation (you have documentation, right?) and test directly:

ping 192.168.1.50

Same logic applies. Success by IP but failure by hostname points to DNS.

Quick Browser Test

Type http://142.250.80.46 in your browser (that’s a Google IP). If the page loads but google.com doesn’t, DNS is your problem.

This basic triage catches the most common misdiagnosis in IT troubleshooting: assuming network problems when name resolution is failing.

Essential DNS Diagnostic Tools

Every IT professional needs these tools in their troubleshooting toolkit. They work across different operating systems and cover different diagnostic needs.

nslookup (Windows, macOS, Linux)

The most accessible DNS diagnostic tool. Available on virtually every system without installation.

Basic query:

nslookup google.com

This shows which DNS server answered and what IP address it returned. If you get “Non-existent domain” or timeout errors, you’ve found your problem.

Query a specific DNS server:

nslookup google.com 8.8.8.8

This bypasses your configured DNS and queries Google’s public DNS directly. If this works but your normal DNS doesn’t, your configured server is the issue.

Check specific record types:

nslookup -type=MX company.com

Replace MX with A, AAAA, CNAME, TXT, or NS depending on what you’re investigating. Mail delivery problems? Check MX records. Website loading issues? Check A records.

dig (macOS, Linux, Windows with installation)

More powerful than nslookup, with detailed output useful for complex troubleshooting.

Basic query:

dig google.com

The output includes query time, which server responded, and the complete answer section. Look for the ANSWER SECTION to see the resolved IP addresses.

Query specific record types:

dig google.com MX
dig company.com TXT
dig internal.company.local A

Trace the resolution path:

dig +trace google.com

This follows the complete DNS resolution chain from root servers through TLD servers to authoritative servers. When DNS works from public servers but fails internally, this trace reveals where the chain breaks.

Get just the answer:

dig +short google.com

Returns only the IP address. Useful for scripting and quick checks.

PowerShell DNS Commands (Windows)

If you’re working in Windows environments, PowerShell offers powerful DNS cmdlets.

Query DNS:

Resolve-DnsName google.com

Query specific record types:

Resolve-DnsName company.com -Type MX

Clear the DNS cache:

Clear-DnsClientCache

For deeper Windows DNS troubleshooting, understanding Group Policy helps, since DNS settings are often pushed via policy.

The Systematic Troubleshooting Process

Random troubleshooting wastes time. Follow this structured approach to isolate DNS problems efficiently.

Step 1: Verify the Symptom

Don’t trust user reports without verification. “The internet is down” could mean anything from complete DNS failure to a single website being unreachable.

Ask specific questions:

  • Which sites or applications aren’t working?
  • Did this just start, or has it been happening intermittently?
  • Is it affecting everyone or just certain users/machines?

Test the reported symptom yourself before proceeding.

Step 2: Test Local DNS Resolution

Start at the client machine experiencing problems.

nslookup google.com

Note the server that responds. Is it your expected DNS server? Sometimes machines grab unexpected DNS settings from VPNs, DHCP options, or manual configurations.

If this fails, try:

nslookup google.com 8.8.8.8

If public DNS works but local doesn’t, your internal DNS infrastructure has a problem. If both fail, the machine may have connectivity issues reaching any DNS server.

Step 3: Clear Local DNS Cache

Cached DNS records can persist after changes or failures. Clear them and retest.

Windows:

ipconfig /flushdns

macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux:

sudo systemd-resolve --flush-caches

Or restart the appropriate service for your distribution.

Stale cache causes problems especially after infrastructure changes or server migrations. The client insists on using old IP addresses even though authoritative records have changed.

Step 4: Check DNS Server Accessibility

Can the client machine reach the DNS server at all?

ping 192.168.1.1  # Replace with your DNS server IP

If ping fails, the problem isn’t DNS—it’s network connectivity to the DNS server. Check routing, firewalls, and physical connectivity.

Also verify DNS ports are open:

nslookup google.com 192.168.1.1

Firewalls sometimes block UDP/TCP port 53 without blocking ICMP (ping). The server might be reachable but not answering DNS queries.

Step 5: Test the DNS Server Itself

If clients can reach the DNS server but queries fail, the server itself may have problems.

On the DNS server:

nslookup google.com 127.0.0.1

If the server can’t resolve queries to itself, check:

  • Is the DNS service running?
  • Are forwarders configured correctly?
  • Can the server reach upstream DNS?

For Windows DNS servers, check the DNS service status and Event Viewer for DNS-related errors. For Linux BIND servers, check /var/log/messages or journalctl -u named.

Step 6: Verify DNS Configuration

Check what DNS servers the problematic machine is actually using.

Windows:

ipconfig /all

Look for “DNS Servers” under the active network adapter.

Linux:

cat /etc/resolv.conf

Or for systemd-resolved systems:

resolvectl status

macOS:

scutil --dns

Compare these settings to what you expect. Misconfigurations happen through:

  • VPN clients overriding DNS settings
  • DHCP servers providing wrong DNS addresses
  • Manual configurations forgotten after testing
  • Network profile corruption

If the machine is getting DNS from DHCP, verify the DHCP scope is configured correctly with the right DNS server addresses.

Common DNS Problems and Their Fixes

After working through diagnostics, you’ll typically find one of these root causes.

Problem: DNS Server Not Responding

Symptoms: All DNS queries time out. Multiple clients affected.

Diagnosis:

ping <dns-server-ip>      # Check connectivity
nslookup . <dns-server-ip> # Test DNS response

Fixes:

  1. Service stopped: Restart the DNS service on the server
  2. Server overloaded: Check CPU, memory, and query volume. May need to add capacity or optimize
  3. Firewall blocking: Verify port 53 UDP/TCP is allowed from client networks
  4. Server crashed: Check system logs, restart if necessary

For production environments, this is why you should have multiple DNS servers with failover configured.

Problem: DNS Resolves Wrong IP Address

Symptoms: Users reach wrong server or get certificate errors because hostname resolves to unexpected IP.

Diagnosis:

dig +short problemdomain.com
nslookup problemdomain.com <authoritative-dns>

Compare returned IP to expected value.

Fixes:

  1. Stale cache: Flush DNS cache on clients and intermediary servers
  2. Incorrect DNS record: Fix the record at the authoritative DNS server
  3. TTL too high: Lower TTL before making changes, wait for caches to expire
  4. DNS hijacking: Rare but possible—verify authoritative server hasn’t been compromised

Problem: External Sites Work, Internal Sites Don’t

Symptoms: google.com resolves fine but internal.company.local fails.

Diagnosis:

nslookup internal.company.local
nslookup internal.company.local <internal-dns-server>

Fixes:

  1. Client using wrong DNS: Client may be using public DNS instead of internal. Check DNS settings and DHCP configuration
  2. Missing zone: Internal DNS server doesn’t have the zone configured
  3. Missing records: Zone exists but specific record is missing
  4. Conditional forwarder missing: If using Active Directory, verify DNS integration

Problem: DNS Works, Then Randomly Fails

Symptoms: Intermittent resolution failures. Hard to reproduce.

Diagnosis:

# Run continuous monitoring
while true; do nslookup google.com; sleep 5; done

Watch for failures and note timestamps. Correlate with:

  • Network utilization graphs
  • DNS server performance metrics
  • DHCP lease times (clients getting new DNS servers)

Fixes:

  1. Overloaded DNS server: Add capacity or optimize queries
  2. Network congestion: DNS uses UDP—congested networks drop packets
  3. Failing DNS server in rotation: One of multiple DNS servers may be unhealthy
  4. DHCP lease changes: Clients may be getting different DNS servers at lease renewal

Problem: DNS Resolution Is Slow

Symptoms: Sites load but take several seconds to start. First connection slow, subsequent connections fast.

Diagnosis:

dig google.com | grep "Query time"

Normal resolution is under 100ms. Over 500ms indicates a problem.

Fixes:

  1. DNS server far away: Use geographically closer DNS servers
  2. Too many forwarder hops: Simplify DNS forwarding chain
  3. Slow upstream DNS: Configure faster public DNS as fallback
  4. DNS server resource contention: Optimize server or add capacity

When to Escalate

Some DNS problems require access or expertise beyond typical IT support. Know when to escalate:

Escalate to network team when:

  • Firewall changes are needed to allow DNS traffic
  • Routing issues prevent DNS server accessibility
  • Network segmentation is blocking DNS queries

Escalate to DNS administrators when:

  • Zone file changes are required
  • DNS server configuration changes are needed
  • DNSSEC issues are suspected

Escalate to security team when:

  • DNS hijacking or poisoning is suspected
  • Unusual query patterns suggest compromise
  • DNS is being used for data exfiltration

Document your troubleshooting steps before escalating. Nothing wastes time like repeating diagnostic work because findings weren’t recorded.

Building DNS Skills for Your Career

DNS troubleshooting is a fundamental skill that appears in multiple certification exams and job interviews. The CompTIA Network+ covers DNS concepts extensively, and DNS questions appear in technical interviews for system administrator and network engineer positions.

For hands-on practice, build a lab environment where you can break DNS intentionally and practice fixing it. Set up a simple DNS server using BIND on Linux or the DNS role on Windows Server. Create zones, configure forwarders, and simulate common failure scenarios.

If you’re working through Linux basics, practice with dig and learn to read its output thoroughly. For command-line practice in a structured environment, Shell Samurai offers interactive exercises that build the muscle memory you need for efficient troubleshooting.

Understanding DNS also connects to broader networking knowledge. Once you’re comfortable with DNS, expand into related topics like DHCP, subnetting, and packet analysis with Wireshark.

Quick Reference: DNS Troubleshooting Commands

Keep this cheat sheet handy for quick diagnostics.

TaskWindowsLinux/macOS
Basic DNS querynslookup domain.comdig domain.com or nslookup domain.com
Query specific servernslookup domain.com 8.8.8.8dig @8.8.8.8 domain.com
Check MX recordsnslookup -type=MX domain.comdig domain.com MX
Flush DNS cacheipconfig /flushdnssudo systemd-resolve --flush-caches
View DNS settingsipconfig /allcat /etc/resolv.conf or resolvectl status
Trace resolution pathN/A (use online tools)dig +trace domain.com
Quick IP lookupnslookup domain.comdig +short domain.com

Putting It Together

DNS troubleshooting follows a logical progression: verify it’s actually DNS, test at multiple levels (client, network, server), and systematically eliminate possibilities. The tools are simple—nslookup and dig cover most scenarios. The skill is knowing what questions to ask and interpreting the answers correctly.

The next time users report that “nothing works,” you’ll know to test IP connectivity first, isolate whether DNS is the culprit, and trace through the resolution chain to find exactly where it breaks.

And yeah, sometimes the fix is still “flush the cache and try again.” But now you’ll know why that works.

FAQ

Why does rebooting the router often fix DNS problems?

Routers often cache DNS queries and forward requests to upstream DNS servers. Rebooting clears this cache and reestablishes connections to upstream servers. If the router’s DNS proxy had stale data or lost connectivity to its configured DNS servers, rebooting resets everything. It’s not elegant, but it works.

Should I use public DNS servers like Google (8.8.8.8) or Cloudflare (1.1.1.1)?

For personal devices and troubleshooting, public DNS servers are excellent—fast, reliable, and helpful for isolating whether problems are with your DNS infrastructure or upstream. For enterprise environments, you typically need internal DNS to resolve internal resources. Use public DNS as fallback or for external resolution, but maintain internal DNS infrastructure for internal domains.

What’s the difference between nslookup and dig?

Both query DNS, but dig provides more detailed output and is more scriptable. nslookup is simpler and available on Windows without additional installation. For basic troubleshooting, either works. For complex debugging (tracing resolution paths, analyzing DNSSEC, scripting), dig is more powerful. Learn both—use whichever is available on the system you’re troubleshooting.

How do I know if DNS is being blocked by a firewall?

Try pinging your DNS server (tests basic connectivity) and then running a DNS query. If ping succeeds but DNS queries fail, port 53 is likely blocked. You can also test from different network segments or use packet capture tools like Wireshark to verify whether DNS packets are leaving your machine and whether responses return.

What causes “DNS server not responding” on Windows?

Common causes include: the configured DNS server is unreachable (network issues), the DNS server is down, firewall rules block DNS traffic, or the network adapter’s DNS settings are misconfigured. Start by checking your DNS settings (ipconfig /all), then test connectivity to the DNS server, then try an alternate DNS server. This usually isolates whether it’s a local configuration issue, network problem, or server problem.