What’s the first thing you do when a user says “the internet isn’t working”?

If your answer is “flush the DNS cache,” you’re in good company. It’s also probably wrong.

DNS troubleshooting has become IT’s equivalent of turning it off and on again—a ritual performed more out of habit than understanding. The problem with ritualistic troubleshooting is that it works just often enough to reinforce bad habits, while wasting enormous amounts of time when the actual issue is something else entirely. If you’re working a help desk role or studying for IT certifications, understanding DNS properly will set you apart.

This guide is different. You’re going to learn how DNS actually fails, what those failures look like, and how to systematically identify the real problem instead of guessing. By the end, you’ll handle DNS tickets faster than anyone else on your team, and you’ll understand why.

Why DNS Breaks (And Why “Flush the Cache” Usually Isn’t the Answer)

DNS failures fall into a handful of categories. Once you recognize which category you’re dealing with, the fix becomes obvious.

The Client Can’t Reach Any DNS Server

The user’s machine is configured to use a DNS server it can’t actually communicate with. This happens when:

  • The configured DNS server IP is wrong or outdated
  • Network connectivity is broken between the client and DNS server
  • A firewall is blocking DNS traffic (UDP/TCP port 53)
  • The DNS server itself is down

When this is the problem, nothing resolves. Not google.com, not your internal sharepoint site, nothing. The user sees “DNS server not responding” or similar messages in their browser.

The DNS Server Can’t Resolve the Query

The DNS server is reachable, but it fails to resolve specific domains. This could be:

  • An authoritative server is misconfigured or unreachable
  • The domain’s DNS records are broken or missing
  • DNSSEC validation is failing
  • The DNS server is experiencing issues with recursion

When this is the problem, some sites work and others don’t. You can typically ping by IP address even when DNS resolution fails.

The DNS Response is Wrong or Stale

The DNS server responds, but with incorrect information. Causes include:

  • Cached records that haven’t updated after changes
  • DNS hijacking (by captive portals, malware, or ISP interception)
  • Misconfigured records at the authoritative server
  • Split-horizon DNS returning the wrong response for the client’s location

When this is the problem, connections fail in weird ways. A site might load partially, redirect unexpectedly, or show security certificate errors because it’s reaching the wrong server.

The Application is Bypassing System DNS

Some applications use their own DNS resolution, ignoring system settings entirely. Browsers like Firefox and Chrome can use DNS over HTTPS (DoH), which means flushing the system DNS cache does absolutely nothing.

When this is the problem, the same site works in one browser but not another, or works from command-line tools but not applications.

The Diagnostic Toolkit: Commands You Actually Need

Before you can fix DNS problems, you need to identify them precisely. These are the commands that matter. Many sysadmin jobs require solid DNS troubleshooting skills.

nslookup: The Cross-Platform Standard

Available on Windows, macOS, and Linux, nslookup queries DNS servers directly. It’s not the most powerful tool, but it’s everywhere.

Basic query:

nslookup google.com

This tells you what DNS server answered and what IP address it returned. If it times out, your system can’t reach its configured DNS server.

Query a specific DNS server:

nslookup google.com 8.8.8.8

This bypasses your system’s configured DNS and queries Google’s public DNS directly. If this works but the first command doesn’t, your local DNS server is the problem.

Check specific record types:

nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com

MX records tell you where email should go. TXT records often contain SPF and DKIM settings. NS records show which servers are authoritative for the domain.

dig: The Professional’s Choice

dig (Domain Information Groper) provides more detailed output and better control. It’s standard on Linux and macOS; Windows users can install it through BIND or use WSL. If you’re learning bash scripting, dig is often combined with other commands to create automated monitoring scripts.

Basic query:

dig google.com

The output shows the question, answer, and metadata including TTL (how long the response is cached) and which server answered.

Query a specific DNS server:

dig @8.8.8.8 google.com

Get just the answer:

dig +short google.com

Trace the full resolution path:

dig +trace google.com

This shows every step from root servers to authoritative servers. Invaluable when tracking down where resolution fails.

Check all common record types:

dig google.com ANY

Note: Some DNS servers don’t respond to ANY queries for security reasons. If you get an empty response, query specific record types individually.

If you’re looking to sharpen your command-line skills for DNS work and beyond, Shell Samurai offers hands-on terminal exercises that build the muscle memory you need for rapid troubleshooting.

Windows-Specific Commands

PowerShell provides modern cmdlets for DNS management, while cmd still works for quick checks.

View current DNS configuration:

Get-DnsClientServerAddress

Or the older method:

ipconfig /all

View the DNS cache:

Get-DnsClientCache

Or:

ipconfig /displaydns

Flush the DNS cache:

Clear-DnsClientCache

Or:

ipconfig /flushdns

View DNS resolution policy (if your organization uses NRPT):

Get-DnsClientNrptPolicy

For Windows Server DNS troubleshooting, Microsoft’s official guidance covers server-side issues in detail. Our Windows Server tutorial provides broader context for these administrative tasks.

Linux-Specific Commands

Check your system’s DNS configuration:

cat /etc/resolv.conf

On systemd-based systems:

resolvectl status

Flush systemd-resolved cache:

sudo resolvectl flush-caches

Restart the resolver service (if caching issues persist):

sudo systemctl restart systemd-resolved

Our Linux basics guide covers these commands in context if you need a refresher on Linux system administration. For understanding systemd services, see our dedicated tutorial.

The Systematic Troubleshooting Process

Here’s the process that separates methodical troubleshooters from cache-flushers. Follow it in order.

Step 1: Verify It’s Actually a DNS Problem

Before touching DNS settings, confirm that DNS is the issue.

Try accessing a site by IP address:

ping 142.250.80.46

(That’s one of Google’s IPs)

If this works but ping google.com fails, you have a DNS problem. If both fail, you have a network connectivity problem—DNS isn’t your issue.

Check if other services using DNS work:

Can you ping internal hostnames? Can you access other websites? If some DNS works and some doesn’t, you’re looking at a partial failure, which narrows down the cause significantly.

Step 2: Identify Where Resolution Fails

Query your system’s configured DNS:

nslookup problematic-domain.com

Query a public DNS server:

nslookup problematic-domain.com 8.8.8.8
nslookup problematic-domain.com 1.1.1.1

If the public DNS servers resolve the domain but your configured DNS doesn’t:

  • Your local DNS server has a problem
  • Your local DNS server is blocking the domain
  • Your local DNS server’s cache is stale

If neither resolves the domain, the problem is with the domain itself or its authoritative DNS servers.

Step 3: Trace the Resolution Path

For domains that aren’t resolving through any DNS server:

dig +trace problematic-domain.com

Watch where the trace stops. Does it fail at the TLD servers? At the authoritative nameservers? This tells you exactly where to focus your investigation.

Step 4: Check the Authoritative Records

Find the authoritative nameservers:

dig NS problematic-domain.com

Query them directly:

dig @ns1.authoritative-server.com problematic-domain.com

If the authoritative servers don’t respond or return incorrect records, the problem is at the domain registrar or DNS hosting level—not something you can fix locally.

Step 5: Examine TTL and Caching

Look at the TTL values in your dig output:

dig google.com

The ANSWER SECTION shows TTL values (in seconds) for each record. If you’ve recently changed DNS records and they haven’t propagated, check whether the TTL has elapsed since the change.

Common TTL values:

  • 300 (5 minutes): Changes propagate quickly
  • 3600 (1 hour): Standard setting
  • 86400 (24 hours): Maximum recommended; changes propagate slowly

If someone set TTLs to 86400 and then changed hosting providers yesterday, some users will still see old records until today.

Common Scenarios and Their Fixes

Let’s apply this framework to situations you’ll encounter regularly. These are the scenarios that come up in help desk interviews and daily support work.

Scenario: “The Internet Isn’t Working” (Single User)

Symptoms: User reports all websites fail to load. Other users are fine.

Diagnostic steps:

  1. Check if the user can ping an IP address (verify network connectivity)
  2. Check the user’s DNS settings (ipconfig /all on Windows)
  3. Try querying a public DNS server

Common causes:

  • DHCP gave the user a bad DNS server address
  • User manually configured an invalid DNS server
  • Malware changed DNS settings to point to malicious servers (a red flag worth mentioning to your security team)
  • VPN software overrode DNS settings

Fix: Compare the user’s DNS settings to a working machine. Reset to DHCP-provided settings or manually configure known-good DNS servers.

Scenario: Specific Website Doesn’t Load (Multiple Users)

Symptoms: One particular external website fails for everyone in the office.

Diagnostic steps:

  1. Check if the site resolves from a public DNS server
  2. Check if your internal DNS server resolves it correctly
  3. Check your firewall/proxy logs for blocks

Common causes:

  • Web filtering blocking the domain
  • DNS sinkhole for security purposes
  • The site itself is actually down
  • Your ISP is having routing issues to that site

Fix: If public DNS resolves it correctly, check your internal DNS and web filtering settings. If public DNS also fails, the problem is external.

Scenario: Internal Application Stopped Working

Symptoms: Users can’t access an internal application by hostname.

Diagnostic steps:

  1. Can you access it by IP address?
  2. What does your internal DNS return for that hostname?
  3. When did the DNS record last change?
  4. Is the hostname registered in DNS at all?

Common causes:

  • Someone deleted the DNS record
  • The server’s IP changed but DNS wasn’t updated
  • DNS scavenging removed a stale record (a known issue in Windows Server environments)
  • The DNS server hosting that zone is down

Fix: Verify the correct DNS record exists and points to the right IP. Check zone replication if you have multiple DNS servers. If you’re managing Active Directory environments, DNS is tightly integrated—AD issues often manifest as DNS problems.

Scenario: Website Shows Wrong Content or Certificate Errors

Symptoms: A website loads, but shows unexpected content or browser warns about certificate mismatch.

Diagnostic steps:

  1. What IP does DNS return for that domain?
  2. Who owns that IP address? (whois or IP lookup tools)
  3. Are you going through a proxy or VPN?

Common causes:

  • DNS records point to an old server
  • CDN or load balancer configuration changed
  • You’re hitting a captive portal that’s intercepting the request
  • DNS hijacking (malicious or ISP-level)

Fix: Verify the returned IP is correct for that service. Check with the site owner or your network administrator if the IP seems wrong.

When to Actually Flush the Cache

After all that, when should you flush DNS caches?

Flush the cache when:

  • You’ve confirmed records changed at the authoritative server
  • You’ve verified the TTL should have expired but the old record persists
  • You’ve ruled out other causes and want to force a fresh lookup

Don’t flush the cache when:

  • You haven’t diagnosed the actual problem yet
  • The issue affects only one site and public DNS can’t resolve it either
  • The problem is intermittent (caching doesn’t explain intermittent failures)

Flushing caches is a valid troubleshooting step. It’s just not the first step.

Advanced: DNS Security Issues

DNS troubleshooting sometimes reveals security problems. Know what to look for. If you’re pursuing a cybersecurity career path, DNS analysis is a foundational skill for threat hunting and incident response.

Signs of DNS Hijacking

  • DNS returns IPs owned by suspicious entities
  • All failed lookups redirect to the same IP (often an ad page)
  • HTTPS sites show certificate errors because they’re reaching wrong servers

Check your router’s DNS settings. Consumer routers are frequently compromised to redirect DNS traffic. Enterprise networks should use DNSSEC to validate responses.

DNS over HTTPS (DoH) Complications

Modern browsers use encrypted DNS by default, bypassing your network’s DNS servers. This is good for privacy but complicates troubleshooting and breaks internal DNS resolution for some organizations.

In Firefox: Settings > Privacy & Security > DNS over HTTPS In Chrome: Settings > Privacy and security > Security > Use secure DNS

If internal sites fail only in browsers but work in command-line tools, DoH is likely the culprit.

Cache Poisoning Indicators

If DNS randomly returns wrong answers that change between queries, someone might be attempting cache poisoning. Modern DNS servers have protections, but older or misconfigured servers remain vulnerable.

Building DNS Troubleshooting Skills

The best way to learn DNS troubleshooting is to practice when things aren’t broken.

Pick a domain and investigate it:

dig +trace amazon.com
dig amazon.com ANY
whois amazon.com

Understand what normal looks like before you’re trying to fix abnormal under pressure. Understanding Wireshark can help you see DNS traffic at the packet level for deeper analysis.

Set up a home lab DNS server. If you’re studying for CompTIA Network+ or similar certifications, running your own DNS gives you safe space to break things and fix them. Our home lab guide covers how to get started.

Read incident postmasters. Companies like Cloudflare publish detailed analyses of DNS outages. These show real-world troubleshooting in action.

The Interview Angle

DNS troubleshooting comes up constantly in IT support interviews. Interviewers want to see systematic thinking, not magic incantations.

Bad answer: “I’d flush the DNS cache and reboot the computer.”

Good answer: “First, I’d verify it’s actually a DNS problem by testing if the user can reach sites by IP address. Then I’d check what DNS servers the client is configured to use and whether those servers respond to queries. If the local DNS works for other domains, I’d trace the specific domain to find where resolution fails.”

The difference? The second answer shows you understand what DNS is and can adapt when the obvious fix doesn’t work.

If you’re preparing for technical interviews, practice walking through troubleshooting scenarios out loud. Our guide to system administrator interview questions covers more examples.

Frequently Asked Questions

What’s the difference between nslookup and dig?

Both query DNS servers, but dig provides more detailed output and better control over queries. nslookup is available everywhere and good for quick checks. dig is preferred for serious troubleshooting because it shows TTLs, flags, and the full response structure. Most DNS professionals use dig when available.

Why does flushing DNS sometimes fix problems even when caching isn’t the issue?

The act of flushing the cache doesn’t magically fix DNS. What happens is that the time spent flushing gives transient network issues a chance to resolve, or the application retries after you’ve made it wait. Correlation isn’t causation—the problem might have resolved itself regardless.

How long does DNS propagation actually take?

It depends on TTL values. If the old record had a 5-minute TTL, propagation happens within 5 minutes after the change. If the TTL was 24 hours, it takes up to 24 hours. “48-72 hours” is outdated advice from when TTLs were commonly set higher. Modern configurations usually propagate within an hour.

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

For troubleshooting, either works fine. For production use, consider: Cloudflare claims faster performance. Google has a longer track record. Both are reliable and offer privacy-focused options (Cloudflare’s 1.1.1.1 claims no logging; Google’s 8.8.8.8 logs some data). Some organizations block public DNS to enforce internal policies—check before recommending to users.

What causes “DNS server not responding” errors?

The client can’t communicate with its configured DNS server. Check: Is the server IP correct? Can you ping the server? Is the server actually running DNS services? Is a firewall blocking port 53? Is the server overloaded? The error is generic; any communication failure produces it.

Wrapping Up

DNS troubleshooting isn’t complicated once you understand the system. Most problems fall into predictable categories: client can’t reach server, server can’t resolve query, response is wrong, or application bypasses system DNS.

The key is diagnosis before treatment. Identify which category your problem falls into, then apply the appropriate fix. Flushing caches, restarting services, and switching DNS servers all have their place—but only after you know why they might help.

Next time someone says “the internet isn’t working,” you’ll know exactly where to start. And it won’t be ipconfig /flushdns.

Building your networking fundamentals? Check out our networking basics guide for the concepts behind these commands, or dive into TCP/IP fundamentals for the protocol-level understanding that makes troubleshooting intuitive. Looking to advance your career? Our help desk to sysadmin guide covers the skills that matter most.