DNS server not responding: how to fix it on Windows, Windows Server, macOS and Linux

Short answer: “DNS server not responding” means your computer sent name lookups to the DNS server set on its network adapter and got no reply, so it cannot turn a name like example.com into an IP address. Check that the connection works without DNS, flush the DNS cache, point the adapter at two working public resolvers, and only if that fails reset Winsock and the TCP/IP stack. On a Windows Server you reach over Remote Desktop, read the warning in Fix 5 first: the TCP/IP reset can remove the server’s static IP.

Windows Network Diagnostics words it as: your computer “appears to be correctly configured”, but the “device or resource (DNS server) is not responding”. nslookup says DNS request timed out. and timeout was 2 seconds., and Chrome shows DNS_PROBE_FINISHED_BAD_CONFIG, or DNS_PROBE_FINISHED_NO_INTERNET when it cannot reach any resolver at all. All three describe the same thing: the website may be fine, but the server that should translate its name is not answering you.

If Chrome shows DNS_PROBE_FINISHED_NXDOMAIN instead, a DNS server did answer and the trouble is that one name, not your resolver. That case is covered in DNS_PROBE_FINISHED_NXDOMAIN.

Is it DNS or the whole connection?

Four commands in PowerShell tell you which problem you have:

# 1. Does traffic leave the machine at all, without DNS?
ping 1.1.1.1
Test-NetConnection 1.1.1.1 -Port 443        # use this if ping is filtered

# 2. Which DNS servers is Windows using?
Get-DnsClientServerAddress | Where-Object ServerAddresses

# 3. Ask the configured server, then a public resolver directly
Resolve-DnsName example.com -DnsOnly
Resolve-DnsName example.com -Server 1.1.1.1 -DnsOnly

• Step 1 fails: this is not a DNS problem. The machine has no working route out. Check the cable or Wi-Fi, the router, and ipconfig /all for an IPv4 address and a default gateway. An address starting with 169.254. means the adapter never got one from DHCP.
• The public resolver answers, the configured one does not: the DNS server on your adapter is the problem. This is the most common case. Go to Fix 1 and 2.
• Both time out: something between you and every resolver drops DNS: a VPN client, a security suite, a firewall rule, or a network that only allows its own resolver. Try Resolve-DnsName example.com -Server 1.1.1.1 -TcpOnly. If TCP works and the normal (UDP) query does not, a filter is dropping UDP port 53. Go to Fix 4.

A second opinion from outside your network settles whether the domain itself is fine: the DNS lookup tool asks our resolver in Amsterdam. If the name resolves there but not on your machine, the fault is the DNS server your machine uses.

Causes, ranked by how often they are the culprit

Fix 1: restart the router and flush the DNS cache

At home, the DNS server on your adapter is usually the router itself, which forwards queries to your ISP. When that forwarder hangs, every device in the house shows this error while plain IP traffic still works. Power-cycle the router, wait until it is fully back, then clear the Windows cache from an elevated prompt:

ipconfig /flushdns
Clear-DnsClientCache     # the PowerShell way to do the same

Flushing drops cached answers, including failed lookups Windows remembered during the outage. It cannot make a silent server answer, so if Step 3 above still fails, move on. You will often see ipconfig /registerdns suggested too. It re-registers your computer’s own name in a DNS zone, which matters in an Active Directory network and does nothing for this error.

Fix 2: point the adapter at working DNS servers

Replacing the adapter’s DNS servers fixes most cases. Use two different providers, so one outage cannot take both down. The example sets Cloudflare (1.1.1.1) and Quad9 (9.9.9.9), plus their IPv6 addresses. Run PowerShell as administrator:

# find the name of the adapter that is up (Ethernet, Wi-Fi, Ethernet 2 ...)
Get-NetAdapter | Where-Object Status -eq 'Up'

# set DNS servers for IPv4 and IPv6
Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses ('1.1.1.1','9.9.9.9','2606:4700:4700::1111','2620:fe::fe')
Clear-DnsClientCache
Resolve-DnsName example.com

# to undo: go back to the servers DHCP hands out
Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ResetServerAddresses

Servers set this way override whatever DHCP assigns for that adapter. Quad9’s 9.9.9.9 also blocks domains it knows to be malicious; for the same service without that filter, use 9.9.9.10 and 2620:fe::10. In the graphical settings the same switch is under Settings → Network & internet → your connection → DNS server assignment → Edit → Manual on Windows 11, or ncpa.cpl → adapter → Properties → Internet Protocol Version 4 (TCP/IPv4) on Windows 10 and Windows Server.

Fix 3: check the IPv6 DNS servers too

Get-DnsClientServerAddress shows two rows per adapter, one for IPv4 and one for IPv6. Routers and ISPs can hand out IPv6 DNS servers that do not answer, and Windows will try them. If the IPv6 row lists addresses that time out with Resolve-DnsName example.com -Server <address>, the command in Fix 2 already replaces them, because it sets both families at once.

Do not switch IPv6 off to get rid of the problem. Microsoft advises against disabling it, because parts of Windows expect it to be there. Replace the broken servers instead.

Fix 4: VPN clients, proxies and security software

A VPN client adds a virtual adapter with its own DNS servers, and often a rule that sends every lookup into the tunnel. When the tunnel is half-connected or its server is down, lookups go nowhere. Disconnect the VPN completely and repeat the tests. Two commands show what it left behind:

Get-DnsClientServerAddress          # look for the VPN adapter and its servers
Get-DnsClientNrptPolicy             # rules that send some names to specific DNS servers

The second command lists the Name Resolution Policy Table, which VPNs and corporate policies use to route certain domains to certain servers. A leftover entry from an uninstalled VPN can break lookups for those names. Security suites with web filtering, and some “privacy” tools, hook into DNS the same way. Pause or update them to test, and if uninstalling one leaves the network broken, Fix 5 cleans up what it left.

Hotel, office and school networks often block DNS to anything but their own resolver. On such a network, Fix 2 makes things worse: reset the servers to DHCP with -ResetServerAddresses. If you run a VPN on a remote Windows server, the guide to using a VPN on an RDP server covers setting the tunnel’s DNS without cutting yourself off.

Fix 5: reset Winsock and the TCP/IP stack

When the servers are right and lookups still fail, reset the networking stack. Open Command Prompt as administrator:

ipconfig /all > %USERPROFILE%\ip-before.txt
netsh winsock reset
netsh int ip reset C:\resetlog.txt
ipconfig /flushdns
shutdown /r /t 0

netsh winsock reset rebuilds the Winsock catalog and removes third-party layered providers, the hooks that VPNs and security software install. netsh int ip reset rewrites the TCP/IP registry settings, which Microsoft describes as equivalent to removing and reinstalling TCP/IP. Both need the restart at the end. The first line saves your current settings to ip-before.txt in your user folder, so you can put them back.

On a physical PC, a broken or freshly updated network driver can cause the same symptom: roll it back or reinstall it in Device Manager if the error started right after an update.

On a Windows Server VPS over Remote Desktop

Remote Desktop connects to the server’s IP address, so a DNS failure on the server does not lock you out. It breaks the browser, Windows Update and anything else that looks up names. You can fix it from inside the session, as long as you keep the network itself intact:

1. 1Find out whether the address is static

   Run ipconfig /all. If the DHCP Enabled line says No, the address is static. Write down the IPv4 address, subnet mask, default gateway and DNS servers.

2. 2Change only the DNS servers

   Set-DnsClientServerAddress from Fix 2 does not interrupt the session. Restarting or disabling the adapter, netsh int ip reset and Network reset do, so avoid them over RDP unless you have another way in.

3. 3If you are cut off, use the console

   Open the VNC console in the VMHeaven panel. It shows the server’s screen even when its network is down. Log in, switch DHCP off if a reset turned it on, and put the saved values back, with the prefix length that matches your mask (24 is 255.255.255.0):

   Set-NetIPInterface -InterfaceAlias 'Ethernet' -AddressFamily IPv4 -Dhcp Disabled
   New-NetIPAddress -InterfaceAlias 'Ethernet' -IPAddress 203.0.113.20 -PrefixLength 24 -DefaultGateway 203.0.113.1
   Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses ('1.1.1.1','9.9.9.9')

Two server-only causes are worth a look. If the adapter lists 127.0.0.1 or ::1, the server is meant to answer DNS itself, typically because the DNS Server role was installed for Active Directory. If that service is stopped, every lookup fails: check it with Get-Service DNS and start it with Start-Service DNS. And if someone set Windows Defender Firewall to block outbound traffic, Get-NetFirewallProfile | Select-Object Name, DefaultOutboundAction shows Block, and DNS needs an outbound rule for UDP and TCP port 53.

If Remote Desktop itself will not connect, that is a different problem, covered in Remote Desktop can’t connect. Every VMHeaven Windows VPS has the VNC console in the panel, so a network change that goes wrong costs you a few minutes, not the server.

On a Mac

The same fixes apply on macOS, from Terminal. First see which DNS servers it uses and what your network services are called:

scutil --dns | grep nameserver
networksetup -listallnetworkservices

Then set two public resolvers on the service you are connected through and clear the cache. Replace Wi-Fi with the name from the list, such as Ethernet:

sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 9.9.9.9
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

sudo networksetup -setdnsservers Wi-Fi empty returns to the servers the router hands out. In System Settings, the same field is under Network, your connection, Details, DNS.

On a Linux server: the resolver does not answer

Linux reports the same failure as Temporary failure in name resolution, or dig prints communications error to … timed out followed by no servers could be reached. Separate a broken resolver setting from blocked DNS traffic:

cat /etc/resolv.conf               # what programs use; 127.0.0.53 = systemd-resolved
resolvectl status                  # which DNS servers, per interface
resolvectl query example.com       # a lookup through systemd-resolved
dig @1.1.1.1 example.com +short    # skip the local resolver entirely
sudo ufw status verbose            # default should read "allow (outgoing)"

A resolver that stays silent looks like this in dig. Replace 192.0.2.1 with the server from resolvectl status or /etc/resolv.conf:

dig @192.0.2.1 example.com +tries=1 +time=2; echo "exit status $?"

;; communications error to 192.0.2.1#53: timed out

; <<>> DiG 9.18.49-1~deb12u2-Debian <<>> @192.0.2.1 example.com +tries=1 +time=2
; (1 server found)
;; global options: +cmd
;; no servers could be reached
exit status 9

Exit status 9 is dig’s “no reply from server”. A name that does not exist ends with status 0, because a server did reply with NXDOMAIN; that is the line between this error and a missing name.

If dig @1.1.1.1 answers and the normal lookup does not, the configured servers are wrong or unreachable. Ubuntu runs systemd-resolved; a plain Debian install often does not, and then resolvectl is missing and the servers sit in /etc/resolv.conf itself. With systemd-resolved, a drop-in sets global servers without touching netplan:

sudo mkdir -p /etc/systemd/resolved.conf.d
printf '[Resolve]\nDNS=1.1.1.1 9.9.9.9\n' | sudo tee /etc/systemd/resolved.conf.d/dns.conf
sudo systemctl restart systemd-resolved
resolvectl flush-caches

If dig @1.1.1.1 times out as well, outbound DNS is blocked or the server has no network. A ufw policy that denies outgoing traffic needs sudo ufw allow out 53. For machines without systemd-resolved, netplan details and Docker containers, see Temporary failure in name resolution. If dig is missing, install bind9-dnsutils.

When your own DNS server does not respond

If you run BIND, Unbound, dnsmasq or PowerDNS on a VPS and clients report that it does not respond, test it from outside with dig @203.0.113.10 example.com, then check these on the server:

sudo ss -lntup 'sport = :53'      # who listens on port 53, and on which address
sudo ufw allow 53                  # opens port 53 for both TCP and UDP
sudo journalctl -u named -n 50     # BIND; use unbound, dnsmasq or pdns for the others

• It listens on 127.0.0.1 only. Set the public address in the server’s own config (listen-on in BIND, interface: in Unbound).
• It fails to start with “address already in use”. The systemd-resolved stub listener holds port 53 on 127.0.0.53 and 127.0.0.54. Turn the stub off and point /etc/resolv.conf at the file that lists the upstream servers directly:

sudo mkdir -p /etc/systemd/resolved.conf.d
printf '[Resolve]\nDNSStubListener=no\n' | sudo tee /etc/systemd/resolved.conf.d/no-stub.conf
sudo systemctl restart systemd-resolved
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

• TCP is closed. Large answers, DNSSEC included, are retried over TCP. Open both protocols on port 53, which ufw allow 53 does.
• It answers, but with REFUSED. That is a response, not silence. An authoritative server refuses names it does not host. If you meant to run a resolver for yourself, allow your own addresses (allow-recursion in BIND, access-control in Unbound) and nobody else: open resolvers are abused for DNS amplification attacks.

If the server is meant to answer for your domain on the internet, it also has to be named as one of the domain’s nameservers at the registrar. The guide to what nameservers are walks through that delegation. Once it is, the DNS propagation checker asks the domain’s own name server directly, next to twelve public resolvers; a server that stays silent shows up there as “No answer within 2 seconds”.

How to keep it from coming back

• Configure two resolvers from two different providers on every machine.
• On servers, set DNS where the system manages it (the adapter, netplan or a resolved drop-in), not in a generated file that gets overwritten.
• Before any network reset, save ipconfig /all or ip addr and ip route output, and make sure you have console access.
• On a server, add a scheduled lookup to your monitoring, so a dead resolver shows up as an alert rather than as failed updates a week later.

Without a monitoring system, a cron line does the job. Add it with crontab -e:

*/5 * * * * dig example.com +time=2 +tries=2 | grep -q 'status: NOERROR' || logger -t dns-check "lookup of example.com failed"

It checks for a NOERROR answer rather than for dig’s exit status, so it also catches the SERVFAIL that systemd-resolved hands back when, for example, no DNS server is configured at all. Failures land in the system log, where journalctl -t dns-check lists them.

A remote Windows desktop that you can repair without a ticket is what the Windows RDP plans are built for: Administrator access, your own IPv4 address and the console in the panel for the moments RDP is not enough.

Frequently asked