DNS is a 40-year-old protocol that translates names into numbers. Conceptually simple. In practice it's responsible for more outages and more misdiagnosed "connectivity issues" than almost anything else on a network.
This guide is about finding the actual problem fast.
The domain name system is one of those things you think you've got handled until you're staring at a terminal wondering why nslookup keeps timing out on domains that worked fine ten minutes ago. Most DNS issues follow predictable patterns though. Once you know where to look, fixes tend to come fast, or at least faster than they feel in the moment.
Let's walk through the troubleshooting steps that actually work. The commands and checks that'll get your DNS resolver back online.
Before running commands, worth spending thirty seconds on what you're actually dealing with. The cause narrows down the fix significantly.
Misconfigured DNS settings show up more than anything else. Usually it's wrong IP address entries. Either set manually and never updated, or a router that quietly reset itself to ISP defaults after a firmware update and didn't tell anyone. That second one is particularly annoying because nothing looks broken until DNS stops resolving.
DNS cache corruption or stale records sitting in local cache. Both can happen constantly after network changes, or when a domain's IP address gets updated but your system still holds the old one.
ISP or upstream DNS service outages. Name servers at your internet service provider go down. More often than they should, honestly. Worth having backup DNS server addresses configured for exactly this reason.
Firewall blocking port 53. UDP and TCP both. Corporate VPNs are the usual culprit and they rarely give you a useful error message when they do it.
Basic network connectivity issues. The internet connection itself is just broken. Less common than you'd think when DNS is the complaint, but check it first before touching anything else.
But most of the time it's cache or config. So let's get started.
Start here before anything else.
Windows:
ping 8.8.8.8Linux/macOS:
ping -c 4 8.8.8.8Ping comes back with replies? Your connection is alive and you're dealing with a DNS-specific problem. No replies at all means something broader is broken. Check the router or your Wi-Fi situation before touching DNS settings.
A working ping looks like:
Reply from 8.8.8.8: bytes=32 time=14ms TTL=117"Request timed out" means DNS isn't your issue yet. Sort out the network first and come back to this.
Corrupted cache causes more weird DNS behavior than most people expect. Worth clearing before doing anything else.
Windows (Command Prompt, run as administrator):
ipconfig /flushdnsmacOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderLinux (systemd-resolve):
sudo systemd-resolve --flush-cachesLinux (nscd on older systems):
sudo /etc/init.d/nscd restartFlush it, then test. Sites loading now? Good, you're done. Keep going if not.
Worth noting: if you're running dnsmasq or another caching service on Linux, flushing systemd's cache does nothing useful. Run systemctl status systemd-resolved first to confirm what's actually handling DNS resolution on your machine before assuming the flush had any effect at all.
Wrong DNS server means no name resolution. Let's see what you're actually pointed at.
Windows:
ipconfig /allLook for the "DNS Servers" line. Should show your router's IP, something like 192.168.1.1, or a public DNS resolver like 8.8.8.8. On Windows Server environments, also check here for misconfigured DNS configuration coming in via Group Policy. It shows up in this output.
Linux:
cat /etc/resolv.confExpecting to see something like:
nameserver 8.8.8.8
nameserver 8.8.4.4macOS:
scutil --dnsSomething unexpected in there, or blank? That's your DNS problem. Switch to a known-good server. Google's public DNS runs on 8.8.8.8 and 8.8.4.4. Cloudflare is 1.1.1.1 and 1.0.0.1. Either works fine.
Where you change it depends on your setup. On Windows it's the network adapter settings. Linux uses /etc/resolv.conf, though check your DHCP config too. DHCP-assigned DNS settings override static entries and you'll wonder why your edit keeps disappearing on reboot. macOS is under System Settings > Network. Or just set it on the router and push it to everything at once.
Time to check if DNS queries are actually completing.
Windows (nslookup, Command Prompt):
nslookup google.com 8.8.8.8Linux/macOS:
dig @8.8.8.8 google.comGet an IP address back? DNS resolution is working. SERVFAIL means the server responded but something's broken upstream. A timeout means you can't reach the DNS service at all. Different problem, different fix.
PowerShell alternative:
Resolve-DnsName google.com -Server 8.8.8.8A clean dig response looks like:
;; ANSWER SECTION:
google.com. 299 IN A 142.250.185.46That A record means the lookup went through. NXDOMAIN when you're not expecting it usually points to a missing record or a DNS zone misconfiguration on the authoritative side. Worth pulling up the actual zone if you manage it.
Also run AAAA while you're at it:
dig @8.8.8.8 google.com AAAABroken IPv6 DNS resolution while IPv4 works fine is a common problem on dual-stack networks. One of those things that hides until it suddenly doesn't.
DNS runs on port 53. UDP for most queries, TCP when responses are large or during DNS zone transfers. A firewall blocking port 53 kills queries without any useful error output.
Linux/macOS:
traceroute 8.8.8.8Windows:
tracert 8.8.8.8Packets not making it through? Check your local firewall rules first. Then the router. Corporate network policies are worth looking at too. VPNs in particular tend to intercept port 53 traffic and silently route it somewhere broken, and they don't warn you when they do it.
On Linux, tcpdump shows whether DNS packets are actually leaving your machine:
sudo tcpdump -i any port 53Watch for outbound queries that never get a response. That pattern, queries leaving with nothing coming back, means the problem is upstream. Either your ISP or the DNS service itself.
Ran through all five steps and DNS is still broken? Some problems genuinely need some deeper digging.
Try a different network. Mobile hotspot works well for this. Resolves fine from there? Your local network or ISP is the problem, not the domain.
Contact your ISP. If their name servers are down and you can't switch to a public DNS resolver for policy reasons, there's nothing on your end to fix. Escalate it and wait.
Check the DNS zone if you manage it. Look for broken CNAME records, missing A records, or TTL values misconfigured in either direction. Too short causes excessive query load, too long means stale records stick around longer than they should. Also verify DNSSEC if it's in use. A broken DNSSEC chain causes resolution failures that look exactly like a server-side problem and can send you in the wrong direction for a while.
Isolate IPv4 and IPv6. Use ping -4 or dig -4 to force IPv4 and see if connectivity issues change. AAAA record lookups behave differently from A record lookups on dual-stack networks, and a problem on one protocol won't always surface on the other.
ISP DNS servers go down more than they should. Switching to a public DNS resolver is usually the faster fix.
Cloudflare (1.1.1.1) is probably the most common recommendation right now. Fast response times, privacy-focused. Good default choice.
Google (8.8.8.8). Reliable, widely documented, been around long enough that most network tools reference it by default. Not much else to say about it.
Quad9 (9.9.9.9) blocks known malicious domains automatically. Slightly slower than Cloudflare on some networks. If the filtering matters more to you than raw query speed, use this one.
Setting Cloudflare as primary and Google as secondary covers you for most failure scenarios. One thing worth watching: if your monitoring tools or any application makes DNS queries via API, make sure the DNS server addresses it uses match what the rest of your network is actually pointed at. Mismatched resolvers cause failures in automated systems that are annoying to track down because they look like application bugs at first.
Most DNS errors are preventable. Mostly it comes down to not cutting corners during setup.
Use reliable DNS servers. ISP defaults are fine until they aren't. Public resolvers are more stable and usually faster.
Monitor DNS performance. If you manage a network, track DNS query response times and failure rates. Tools like Paessler PRTG Network Monitor alert you when DNS starts degrading, before users notice anything. That's a better situation than working backward from a flood of tickets.
Keep your DNS zones current. Stale records and misconfigured CNAME entries cause quiet problems that surface weeks later. On DHCP-heavy networks especially, DNS records drift out of sync over time if nobody's watching them.
Write down your DNS configuration. Sounds basic. When something breaks at 2am and you can't remember which name server you're actually supposed to be using, you'll care about this.
Test IPv4 and IPv6 separately, and do it regularly. Don't assume both work because one does.
And if DNSSEC isn't in place yet, worth looking at. Microsoft has solid documentation for Windows Server environments if you need a starting point. It closes a class of DNS attacks that are otherwise difficult to defend against.
Most DNS issues come down to cache, config, or connectivity. Once you've seen the pattern a few times you work through it quickly.
But if you're done with reactive troubleshooting and want to know about DNS failures before your users do, monitoring is the answer. PRTG tracks DNS query performance, server availability, and resolution times continuously so you see it break before anyone sends a ticket.
Start your monitoring journey today and try PRTG free for 30 days.