The Five Step DNS Troubleshooting Guide Your Small Business Actually Needs

Let me save you some time. The website is not loading. Someone in the office has said “it is DNS” with the quiet confidence of a person who once fixed a printer. Before anyone starts rewriting resolver settings, changing configurations, or performing the ritual sacrifice of the router, follow these five steps. In order. Every time.

This is the sequence we discussed on this week’s podcast, expanded here with the specific commands and practical detail you need to actually do it.

Why a Sequence Matters

The instinct to immediately blame DNS exists because DNS sits near the start of every web connection. Type a domain name, and DNS translates it into an IP address. If that translation fails, nothing loads. So blaming DNS feels logical.

The problem is that dozens of other failures produce the same symptom: “website will not load.” Bad wifi. Captive portals. Stale browser cache. Router misconfigurations. ISP outages. Security products intercepting traffic. A device that cannot reach the resolver in the first place. All of these look like DNS from the outside.

A structured sequence separates genuine DNS failure from everything that impersonates it. Each step narrows the field. By step five, you either have a confirmed DNS issue or you have identified something else entirely.

Step One: Test Another Device on the Same Network

This is the fastest way to determine whether the problem is specific to one machine or affects the whole network.

If your laptop cannot reach a website but your phone, connected to the same office wifi, loads it perfectly, the issue is almost certainly local to the laptop. That could be a stale browser cache, a misconfigured local DNS setting, a VPN client interfering with queries, or an endpoint security product filtering traffic differently.

If both devices fail on the same network, the problem is more likely at the network level: the router, the broadband connection, or the upstream DNS resolver.

What to do: Open the same website on a phone connected to the office wifi. Note whether it loads. If it loads on one device but not another, the problem is local to the failing device.

Step Two: Test a Different Network

Mobile data is perfect for this. Disconnect your phone from office wifi, switch to 4G or 5G, and try the website again.

If it loads fine over mobile data but not over office broadband, you have narrowed the problem from “the entire internet” to “something on this connection or inside this network.” That is a substantial diagnostic gain. You are now looking at the router, the ISP connection, or the DNS resolver configuration on your office network.

If it also fails on mobile data, the website itself may genuinely be down, or the domain’s DNS records may be misconfigured at the authoritative level. That is a problem at the website’s end, not yours.

What to do: Turn off wifi on your phone. Load the website over mobile data. Compare the result.

Step Three: Check Resolver Reachability

This is the step most people skip, and it is the one that prevents the most wasted time.

Before blaming the DNS resolver for giving wrong answers, check whether your device can actually reach it. If the network path to the resolver is broken, of course names will not resolve. That is not the resolver’s fault. That is your route to the helper being broken.

On Windows, open Command Prompt and type:

nslookup google.com

If this returns an IP address, your device can reach its configured DNS resolver and the resolver is responding. If it times out, either the resolver is down or your device cannot reach it.

To check which resolver your device is using:

ipconfig /all

Look for the “DNS Servers” entry. Note the addresses listed.

On macOS, open Terminal and type:

nslookup google.com

To check your configured resolver:

scutil --dns | head -20

What to look for: If nslookup times out, try pinging the resolver IP address directly. If the ping fails too, the issue is network connectivity to the resolver, not the resolver itself. If the ping succeeds but nslookup fails, the resolver may be blocking queries or experiencing issues.

Step Four: Clear DNS Cache

Stale cache is not always the problem, but it is common enough to be worth ruling out early, especially after a recent DNS record change.

DNS answers are cached at multiple levels: the browser, the operating system, and the resolver. If a DNS record changed recently, one machine might still hold the old answer while another has the new one. People hear “inconsistency” and think mystery. Usually it is just caches expiring at different times based on TTL (time to live) settings.

Browser cache: Close and reopen the browser, or use a private/incognito window to bypass the browser’s DNS cache.

Windows OS cache: Open Command Prompt as Administrator and type:

ipconfig /flushdns

macOS OS cache: Open Terminal and type:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

What to do after clearing: Retry the website. If it loads now, the problem was a stale cached record. If it still fails, move to step five.

Step Five: Compare the IP Response

This is where troubleshooting becomes investigation. Ask the same DNS question from different sources and compare the answers.

On Windows or macOS, use nslookup to query different resolvers:

nslookup example.com 1.1.1.1

nslookup example.com 8.8.8.8

nslookup example.com 9.9.9.9

Replace “example.com” with the domain that is not working. Compare the IP addresses returned by each resolver.

What the results tell you:

If all three resolvers return the same IP address but the website still does not load, DNS is working correctly. The problem is elsewhere: the web server, the network path to it, or something blocking the connection.

If your office resolver returns a different IP address from the public resolvers, you have something concrete to investigate. Possibilities include a stale cached record on your resolver, a misconfigured DNS record at the authoritative level, or, and this is the one that matters, malicious interference.

If your office resolver returns an IP that does not match any legitimate server for that domain, treat it as a potential security incident. Rogue DNS settings, cache poisoning, and router compromise can all produce this result.

When It Actually Is DNS

Sometimes, after all five steps, the problem genuinely is DNS. The most common genuine DNS failures for small businesses are:

Misconfigured records. Someone changed an A record, a CNAME, or a name server delegation and introduced a typo or pointed it at the wrong IP. This is the most common genuine DNS failure and it is fixable by correcting the record at your domain registrar or DNS hosting provider.

Expired domain. The domain registration lapsed because nobody renewed it or the payment card on file expired. The domain stops resolving entirely. Check your registrar account.

Name server delegation issues. The domain’s name servers are set to servers that are not actually authoritative for it. This happens after migrations between DNS providers when the old name servers are decommissioned but the registrar still points to them.

TTL and propagation delays. After a legitimate DNS change, caches around the world expire at different times. One device gets the new record, another holds the old one. This resolves itself within the TTL period, typically a few hours to a day.

The Security Check You Must Not Skip

If your investigation in step five reveals that your office resolver is returning a different IP address from public resolvers, and that IP does not correspond to any legitimate server for the domain in question, do not shrug and call it internet weirdness.

Check your router’s DNS settings. If they have changed without a documented reason, that is a potential indicator of compromise. Check endpoint DNS settings too. Malware can modify local resolver configuration to redirect traffic through attacker-controlled servers.

As Mauven discussed in Wednesday’s analysis, the NCSC recommends monitoring for unusual resolver traffic precisely because DNS tampering hides behind perfectly boring user complaints.

Common False Positives

Before declaring a DNS emergency, rule out these frequent imposters.

Captive portals. Hotel, airport, and guest wifi networks intercept traffic until you accept terms and conditions. Your laptop says “connected” but the internet does not work. Open a browser and look for a login page.

VPN split tunnelling. If you are connected to a VPN, some traffic may route through the VPN tunnel while other traffic goes direct. DNS queries may follow different paths depending on the VPN configuration. Disconnect the VPN and test again.

Browser extensions. Ad blockers, privacy extensions, and security add-ons can intercept or modify DNS behaviour. Test in a clean browser profile.

ISP transparent DNS proxying. Some ISPs intercept DNS queries regardless of which resolver you configure and redirect them through their own servers. This can produce unexpected results when you think you are querying 1.1.1.1 but your ISP is actually answering instead.

How to Turn This Into a Competitive Advantage

Having a documented troubleshooting process for network issues signals operational maturity to clients, partners, and auditors.

If your business provides services to other organisations, being able to respond to a “your website is down” complaint with a structured diagnosis rather than panicked guessing builds confidence. It shows you understand your infrastructure.

Create a one-page troubleshooting card with these five steps and distribute it to everyone in the business who handles IT issues. It costs nothing and it saves hours of unstructured debugging.

How to Sell This to Your Board

Wasted diagnostic time is measurable. Track how long network issues take to resolve before and after implementing a structured process. The reduction in mean time to resolution translates directly to recovered productivity.

Structured diagnosis reduces external IT costs. If your business calls in external IT support for every network issue, a troubleshooting sequence that rules out the simple causes first reduces the number of callouts. That is money saved.

Security incidents hide in plain sight. A troubleshooting process that includes IP comparison (step five) provides early warning of DNS tampering. Without it, rogue DNS settings can persist undetected for weeks or months.

What This Means for Your Business

1. Print the five step sequence and put it where IT issues get reported. Another device, another network, check resolver, clear cache, compare IPs. Make it the default starting point for every “the internet is broken” complaint.

2. Document your baseline DNS configuration. Record which resolvers your router uses, which resolvers are configured on company devices, and when these were last verified. Without a baseline, you cannot identify changes.

3. Train one person to run nslookup. You do not need a networking qualification. You need one person who can open a terminal, type nslookup example.com 1.1.1.1, and compare results. That person saves the business hours per incident.

4. Keep a log of DNS changes. Every time someone changes a DNS setting, whether on the router, a device, or the domain registrar, log it with the date, what changed, and why. The number of outages caused by undocumented changes is staggering.

5. Treat unexpected IP results as a security concern. If step five reveals your resolver returning a different IP from public resolvers for the same domain, do not ignore it. Investigate. Check router settings. Check endpoint configurations. Escalate if necessary.

Source	Article
NCSC	Protective DNS for the private sector
NCSC	Managing Public Domain Names
NCSC	Small Business Guide
DSIT / GOV.UK	Cyber Security Breaches Survey 2025
Cloudflare	1.1.1.1 DNS Resolver Documentation
Quad9	Quad9 DNS Security and Privacy
Google	Google Public DNS
ISC	BIND 9 CVE-2025-40778 Advisory