DNS Server Not Responding? Fix One PC or the Whole Office

Updated: October 2026

Someone's browser says the page can't be reached, they run the Windows troubleshooter, and it announces that the DNS server isn't responding. That message is a starting point, and the fix the top search results suggest can quietly break a work PC. Here's how to tell whether it's one machine or the whole office, which commands prove where the problem is, and how to fix it without creating the next ticket.

What "The DNS Server Isn't Responding" Means

DNS turns a name like outlook.office.com into the IP address a computer can connect to. Every browser tab, sync client and sign-in starts with that lookup. When it fails, nothing that uses names works, even if the network cable and Wi-Fi are fine.

The message itself comes from Windows Network Diagnostics. It tried a lookup, got no answer, and reported its best guess. That guess is often right, but the same symptom shows up when the default gateway is down, the adapter has no address, or a security agent is filtering DNS. Treat it as a lead, not a diagnosis.

One PC or the Whole Office? Check Scope First

The fix depends on how many people are affected, so ask before you touch anything.

• One PC only. Something local: the adapter, its DNS settings, the cache, a VPN client or a browser setting.
• Everyone at one site. The site's DNS server, the router or firewall handing out DNS, or the DHCP scope.
• Only people on the VPN. The tunnel's DNS settings or split tunnelling.
• Everyone, everywhere. A cloud resolver, a DNS filtering service, or the internal DNS servers themselves.

Two minutes on this saves an hour of flushing caches on a PC that was never the problem.

Fix It on One Windows PC

Start by finding out which DNS server the PC is using. Run:

code
ipconfig /all

Look at the DNS Servers line for the active adapter, and check the Default Gateway too. If ping to the gateway fails, the problem is the connection, not DNS, and no amount of cache flushing will help.

If the gateway answers, test each DNS server directly, so you know whether the server or the PC is at fault:

powershell
Resolve-DnsName outlook.office.com -Server 10.0.0.10
Resolve-DnsName outlook.office.com -Server 1.1.1.1 -DnsOnly

Microsoft's documentation describes Resolve-DnsName as the PowerShell counterpart to nslookup. The -Server switch is the useful part: if the internal server answers and the PC still fails, the problem is local. If the internal server times out, stop working on the PC.

For a local problem, work from least to most disruptive. Clear the cache with ipconfig /flushdns, re-register the PC's own records with ipconfig /registerdns, then disable and re-enable the adapter. netsh winsock reset comes last, because it needs a restart and resets things that usually aren't broken.

If lookups still fail with a healthy server, check that the DNS Client service is running with Get-Service Dnscache. It shouldn't be stopped or disabled on a working PC, and a security tool or a tuning script that switched it off will produce exactly this error.

This walkthrough shows the same testing order on a live machine, from ipconfig to a direct lookup.

Don't Point Domain PCs at 8.8.8.8

The top-ranking guides for this error all say to switch the DNS server to 8.8.8.8 or 1.1.1.1. On a home laptop that's fine. On a PC joined to an Active Directory domain, it creates a new problem.

A domain PC finds its domain controllers through special records that only exist on the company's internal DNS server. Google's resolver has never heard of them. So the web works again, and then the user can't sign in, Group Policy stops applying, and file shares disappear.

Microsoft's own DNS client recommendations are direct about this: "Don't configure the client DNS settings to point to your ISP's DNS servers." Instead, domain PCs point at internal DNS, and the internal DNS server forwards anything outside the company to the internet.

Internal and public DNS get tangled in other ways too. In this thread, the company's internal domain matched its public website, so the day marketing dropped "www" from the site, nobody inside the office could reach it.

When the Whole Office Loses DNS

When everyone is affected, look upstream. The usual suspects are the internal DNS server itself (often a domain controller), its forwarders, the router or firewall that DHCP points everyone at, or a DHCP scope handing out a server that no longer exists.

On a Windows DNS server, confirm the service is up with Get-Service DNS, then run dcdiag /test:dns on a domain controller. It checks the records domain PCs depend on, the forwarders and the delegations in one pass, and it names the part that's failing instead of leaving you to guess.

Security tools are on the list now too. DNS filtering agents sit in the lookup path on every endpoint, so when the filtering service has a bad afternoon, every PC reports the same error at once. In this r/msp thread from March 2026, the one thing every broken endpoint had in common was the DNS filter agent, and the vendor later confirmed a regional outage.

One Windows behaviour explains the flaky version of this. If the preferred DNS server stops answering, the PC switches to the alternate and stays there until that one fails or 15 minutes pass, per the same Microsoft page. So a server that comes back doesn't fix every PC immediately, and a half-broken secondary can cause errors that come and go.

Browsers, VPNs and Secure DNS

Some cases only affect one app. Chrome and Edge can use secure DNS (DNS over HTTPS) and send lookups to a public provider instead of the company server. Internal sites then fail in the browser while everything else works.

VPNs add their own DNS servers when they connect. With split tunnelling, some names should go through the tunnel and some shouldn't, and a wrong setting sends internal names to the wrong resolver. A stale hosts file entry can do the same on one PC, which is why Resolve-DnsName -NoHostsFile is worth a try when one name misbehaves.

Stop It Coming Back

Most of this is plumbing you set once. Run two internal DNS servers per site, so one reboot doesn't take the office offline. Check that DHCP hands out those two servers and nothing else. Watch the forwarders, because a dead forwarder looks exactly like a dead DNS server to users.

Then test from where the users are. A scheduled Resolve-DnsName against an internal and an external name, run on a handful of endpoints, catches a failing server before the phones ring. OpenFrame can run scripts like that on a schedule across devices, with approval gates on anything that changes settings.

If lookups work but feel slow, that's a different problem with different fixes, covered in our guide to slow DNS lookups.

For the commands above and the ones that sit next to them, see our PowerShell commands cheat sheet.