I finally stopped guessing about DNS problems after learning these Windows commands

For the longest time, a DNS problem meant a site wouldn’t load, or it would load on my phone but not my PC, and I’d start working through a bunch of Windows commands to fix the internet. I would also restart the router, switch to a different DNS server, or reboot Windows and hope. Sometimes one of them worked, but I could never tell you which one or why, because I was never really looking at the problem.

However, a better way to deal with a DNS problem is to learn a handful of Windows commands that show you what DNS is doing. Instead of guessing whether the cache was stale, the DNS server was unreachable, or the route itself was broken, you can check what’s actually happening under the hood.

ipconfig /displaydns

Shows you every address Windows is currently remembering

The first command I run when the internet breaks is ipconfig /displaydns. Windows keeps a local DNS cache, a list of site names it has recently looked up, along with the IP addresses they resolved to. This saves your PC from asking a DNS server the same question every time you open a site. The catch is that a cached answer can go stale, and a stale answer is one of the most common reasons a site loads everywhere except on your machine.

Running ipconfig /displaydns in Windows Terminal or Command Prompt, print every record in that cache. Each entry shows the record name, the record type, a Time To Live value counting down the seconds until the record expires, and the actual IP address Windows has on file. That last part is what I care about. If a site is misbehaving, I can see exactly which address my PC thinks it should be talking to.

This is where the guessing stops. If the cached IP looks wrong, I know the cache is the problem before I touch anything else. PowerShell takes this further with the Get-DnsClientCache cmdlet, which lets you filter the cache by name or record type.

nslookup

Asks a DNS server directly, so you stop guessing what resolves

ipconfig /displaydns tells me what my PC already believes. nslookup tells me what’s actually true right now. It’s a command-line tool that queries a DNS server directly and reports back the IP address tied to a hostname so that I can compare a fresh answer against the stale one in my cache.

The clearest sign that DNS is your problem is when a site refuses to load, but pinging a raw IP address works fine. That split means your connection is healthy, but the name-to-address translation is failing somewhere. Running nslookup example.com confirms it. If the command returns an IP address, DNS is doing its job. If it returns “Non-existent domain” or simply times out, the lookup itself is broken.

The output also tells you which DNS server answered. A normal result is marked “non-authoritative,” meaning the answer came from a server’s cache rather than the domain’s official records, which is expected. You can dig deeper, too. Adding -type=mx pulls mail records, handy when email is the thing that’s broken, and -type=ns lists a domain’s name servers. For everyday troubleshooting, a plain nslookup is usually enough to tell you whether the resolver is the culprit.

tracert

Shows you exactly where the connection breaks down

Once nslookup confirms a hostname resolves to an IP, the next question is whether packets can actually reach that IP. That’s the job of tracert. It doesn’t trace the DNS lookup itself; it maps the path your data takes toward the resolved address and shows where that path slows down or stops.

The most useful thing Tracert does for DNS troubleshooting is to rule DNS in or out. Run tracert example.com, and if you immediately see “Unable to resolve target system name,” Windows could not get an IP for that hostname at all. The problem is definitely DNS or your hosts file, not routing. But if the trace gets past the first hop, the hostname has already been resolved successfully, which means DNS worked, and whatever is wrong lives further down the path.

There’s a neat trick here. Run tracert against a hostname, then run it again against the raw IP nslookup gave you. If the IP version completes while the hostname version fails even to start, you’ve isolated the fault to DNS resolution while confirming general connectivity is fine. You can also point tracert straight at a public resolver like tracert 8.8.8.8. If reaching the DNS server itself is slow or full of timeouts, your lookups will feel slow, no matter how healthy the rest of your connection is, which is sometimes a sign that your router settings are quietly hurting your speed.

ipconfig /flushdns

Clears the stale cache that keeps sending you nowhere

By this point, I usually know what’s wrong, and more often than not, it’s a stale cache entry pointing my PC at an old address. The fix is ipconfig /flushdns. It clears the entire local DNS cache, forcing Windows to fetch fresh records the next time you visit a site.

This matters most after a website moves to a new server. The site now lives at a new IP, but your PC is still holding the old one and dutifully sending you to an address that no longer answers. Flushing the cache wipes that outdated entry. The same applies after you change your DNS server or suspect the cache has been corrupted by malware redirecting your lookups. It’s a safe command too, comparable to routine network maintenance, and it won’t harm performance or settings.

One thing worth knowing is that flushing won’t always empty the cache completely. Entries from your local hosts file aren’t cleared, and background apps can immediately trigger new lookups that repopulate it within seconds. So if you run ipconfig /displaydns right after a flush and still see entries, that’s normal. If a flush fixes the problem, the issue was a stale record. If it doesn’t, you’ve ruled the cache out and can move on. Switching to a more reliable resolver afterward is worth considering, and changing your DNS isn’t just for your PC.

netsh winsock reset

The fix to try when nothing else works

If the cache is clean, the hostname resolves, and the route is fine, but networking is still broken, the problem may be deeper than DNS. This is when I reach for netsh winsock reset.

Winsock is the Windows networking component that sits between your applications, like your browser, and the network itself. Its configuration lives in something called the Winsock catalog, and that catalog can get corrupted by malware, badly installed network software, or leftover entries from a device you removed. When it does, you get strange failures: DNS lookups failing despite correct settings, or browsers reporting limited connectivity for no obvious reason.

Running netsh winsock reset in an elevated Command Prompt resets that catalog to its default state, then you reboot to finish the job. Before I run it, I save a snapshot with netsh winsock show catalog > winsock-before.txt, so I have a record of what changed. If the problem is more about IP configuration than Winsock, the related netsh int ip reset command rebuilds your TCP/IP settings the same way. Neither is a guaranteed cure, but as a last resort before calling support, a reset clears out corruption that no amount of cache flushing will touch.

OS

Windows

Minimum CPU Specs

1Ghz/2 Cores

Windows 11 is Microsoft’s latest operating system featuring a centered Start menu, Snap Layouts, virtual desktops, enhanced security with TPM 2.0, and deeper integration with Microsoft Teams and AI-powered Copilot.

Fixing the DNS problem is easy if you know where to look

I still run into DNS problems, because everyone does. But instead of throwing every trick in the book at my connection, I run two or three commands, read what they tell me, and apply the right fix. Once you know the cause, the fix is the easy part.