DNS Is Usually the Problem: My 5-Check Troubleshooting Routine

There's an old joke in IT: "It's not DNS. There's no way it's DNS. It was DNS." It gets repeated so often because it keeps being true.

When I worked as a Network Support Engineer at an internet service provider, a large share of "my internet isn't working" calls turned out not to be connection failures at all. The link was up. The router was fine. The device simply couldn't translate a name like example.com into an IP address. Later, supporting a manufacturing site with more than 1,200 users, I saw the same pattern inside a corporate network: shared drives "missing," internal apps "down," printers "offline," all caused by name resolution problems.

This article walks through the five checks I use to confirm or rule out DNS quickly. They work on Windows, macOS and Linux, and you don't need any special tools.

First, a 60-second refresher on DNS

The Domain Name System is the internet's phone book. Computers communicate using IP addresses, but people use names. When you type a website address, your device asks a DNS resolver, "What's the IP address for this name?" The resolver either knows the answer from its cache or asks other DNS servers until it finds one that does. Only then can your device actually connect.

Inside companies, DNS also resolves internal names: file servers, intranet sites, printers and domain controllers. If DNS fails, it can look like everything is broken, even though the network itself is working perfectly.

That's why DNS failures are confusing for users. They see error messages like "site can't be reached" or "server not found" and naturally conclude that the internet is down. The real question is: can the device reach things by IP address, but not by name?

Check 1: Is there a network connection at all?

Before blaming DNS, confirm that the basics are in place. I start by checking that the device has a valid IP address, a subnet mask and a default gateway.

• Windows: ipconfig /all
• macOS and Linux: ip addr (or ifconfig on older systems)

What I'm looking for:

• An IP address in the expected range. An address starting with 169.254 on Windows means the device didn't get an address from DHCP, which is a different problem entirely.
• A default gateway, usually the router's address.
• DNS server entries. If these are missing or point somewhere unexpected, that's an early clue.

Then I ping the default gateway. If that fails, the problem is local: cabling, Wi-Fi, the switch port or the router. DNS isn't the issue yet.

Check 2: Can you reach the internet by IP address?

This is the most important test in the routine, because it separates connectivity problems from name resolution problems.

Ping a well-known public IP address directly, for example ping 1.1.1.1 or ping 8.8.8.8.

• If this fails, traffic isn't leaving your network. Look at the router, the firewall or the internet connection itself.
• If this succeeds, your connection to the internet works. Now try ping example.com (or any well-known site). If pinging the IP works but pinging the name fails, you've almost certainly found a DNS problem.

One caution: some networks block ping (ICMP) for security reasons, so a failed ping isn't always conclusive. If ping is blocked, try opening a site in a browser using an IP address, or move straight to the next check.

Check 3: Ask DNS directly

Now I query DNS on its own, so I can see exactly what it returns.

• Windows: nslookup example.com
• macOS and Linux: nslookup example.com or dig example.com

The output tells me three useful things:

1. Which DNS server answered. Is it the server you expected, such as the company's internal DNS or the router? Or something else?
2. Whether you got an answer at all. A timeout means the DNS server isn't responding. "Non-existent domain" (NXDOMAIN) means the server responded but says the name doesn't exist.
3. What address came back. Is it the right one? An unexpected address can mean a stale record, a misconfiguration or, in rare cases, something malicious.

A very useful variation is to query a specific public resolver and compare: nslookup example.com 1.1.1.1. If the public resolver answers correctly but your normal server doesn't, the problem is your DNS server, not the name.

Check 4: Clear the cache

Devices and browsers cache DNS answers to speed things up. That's normally helpful, but it means a device can hang on to an old or wrong answer after the real record has changed.

• Windows: ipconfig /flushdns
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux (systemd-resolved): resolvectl flush-caches

Browsers keep their own cache too, so I close and reopen the browser, or test in a private window.

I also check the hosts file, which overrides DNS entirely. On Windows it lives at C:\Windows\System32\drivers\etc\hosts, and on macOS and Linux at /etc/hosts. An old manual entry left there for testing can quietly send traffic to the wrong place. From a security point of view, an unexpected entry in the hosts file deserves attention, because malware has been known to use it to redirect users.

Check 5: Look at the bigger picture

If one device has a DNS problem, the cause is usually on that device. If many devices have it at once, the cause is shared.

So I ask:

• Is it one user or many? On a help desk, several similar tickets arriving within minutes is a strong sign the issue is central.
• Is it one site or all sites? If only internal names fail, the internal DNS server may be down or unreachable. If only external names fail, the forwarders or the upstream resolver may be the problem.
• Did anything change recently? A new firewall rule, a DHCP change handing out the wrong DNS server, an expired domain, or a DNS record updated without enough time to propagate.
• Is a filtering service involved? In my home lab I run Pi-hole, which blocks ads and trackers at the DNS level. It's great, but when something blocks too much, legitimate sites can fail to load. Corporate DNS filtering can behave the same way.

A typical example, start to finish

Here's how the routine plays out on a typical call. A user reports that the company's internal portal "is down," but email is working.

Check 1 shows the laptop has a valid address, the right gateway and two DNS servers. The gateway answers a ping. Check 2 shows that a public IP replies, and that public websites load by name. So the internet is fine, and external DNS works.

Check 3 is where it gets interesting. nslookup for the portal's internal name returns "non-existent domain" from the first DNS server listed. Querying the second internal DNS server directly returns the correct address. That tells me the name exists and one of the two servers has a problem, perhaps a failed replication or a stale zone.

Check 4 explains why only some users are affected: devices that still had the answer cached kept working, and devices that asked the faulty server failed. Check 5 confirms it: the tickets are all coming from one building, the one whose DHCP scope lists the faulty server first.

Total time: about ten minutes. Without the routine, it would be easy to spend an hour restarting laptops and blaming the portal team.

Why this matters for security

DNS isn't just a troubleshooting topic. It's a security topic.

Attackers use DNS in several ways: registering look-alike domains for phishing, hijacking DNS settings so users are sent to fake sites, and even tunnelling data out of a network inside DNS queries. On the defensive side, DNS logs are one of the most valuable sources of evidence in an investigation, because almost every connection starts with a lookup.

When I troubleshoot DNS, I keep a security lens on. If the DNS server on a device has been changed to something nobody recognizes, or if a hosts file has been edited without explanation, that's not just a fault to fix. It's something to report.

The routine in one place

1. Confirm the device has a valid IP, gateway and DNS servers, and can ping the gateway.
2. Ping a public IP address, then a name. IP works but name fails points to DNS.
3. Query DNS directly with nslookup or dig, then compare with a public resolver.
4. Flush the DNS cache, restart the browser and check the hosts file.
5. Step back: one device or many, internal or external, and what changed recently?

Most of the time, this routine finds the problem in under ten minutes. Just as importantly, it gives you clear evidence to put in the ticket, so the next person doesn't have to start from scratch.

What's your go-to first step when someone says the internet is down?