DNS not resolving means a name did not turn into an address, and the useful question is where it broke. Six layers can fail: the application cache, the operating system cache, which server the machine asks, whether that server answers, whether it can reach the authoritative servers, and whether the record exists. Each has a different fix.
- Ping an address, then a name. That splits the problem in half
- Test with nslookup or dig, never a browser
- Internal failing and external working is always the wrong resolver
- Nothing propagates. Cached answers expire on their own TTL
- Lower the TTL before a change, because you cannot do it afterward
On this page
- The one test that splits a DNS problem in half
- The six DNS layers, in the order to check them
- The DNS commands, in that order
- The DNS failures worth recognizing by sight
- The record types, and the failure each one produces
- Propagation, which is not a thing
- The standard fixes, and what each one actually does
- Where people go wrong
- Comparison
- FAQ
First testThe one test that splits a DNS problem in half
Before checking anything else, establish whether this is a DNS problem at all.
ping 1.1.1.1 # an address, no name involved
ping cloudflare.com # the same destination, by nameIf the first succeeds and the second fails, the network is fine and the fault is DNS. If both fail, this is not a DNS problem and everything below is wasted effort: fix the network connectivity first.
That single comparison saves more time than any other step, and it is the one people skip.
The six layersThe six DNS layers, in the order to check them
Work outward from the machine. Each layer is cheap to check and eliminating it narrows what remains.
1. The application cache. Browsers keep their own DNS cache and, increasingly, use their own DNS server over HTTPS. A domain that fails in one browser and works at the command line is a browser problem, not a network one. Test in a private window, or better, stop testing DNS in a browser at all.
2. The operating system DNS cache. The machine remembers recent answers, including negative ones. A domain that was broken an hour ago stays broken locally after the real fix. On Windows, ipconfig /flushdns. On macOS, sudo dscacheutil -flushcache. On Linux it depends on the resolver, usually sudo resolvectl flush-caches.
3. Which DNS server the machine is using. This is where most business faults actually live. A machine that picked up a public DNS server instead of the domain controller resolves internet domains perfectly and cannot find anything internal. Check with Get-DnsClientServerAddress on Windows or resolvectl status on Linux, and read the whole list rather than the first entry.
4. Whether that DNS server answers. Query it directly by address and see whether anything comes back. If the server is unreachable, the fault is the network or a firewall rather than DNS itself.
5. Whether the DNS server can reach the authoritative servers. A resolver that answers for cached domains and fails for new ones is usually blocked outbound on port 53, or its own upstream servers are down. Test with a domain nobody has looked up recently.
6. Whether the DNS record exists at all. Query the authoritative server directly, bypassing every cache in the path. If it does not hold the record, no amount of local work helps and the fix is in the zone file.
The commandsThe DNS commands, in that order
# 3. Which resolvers is this machine actually using
Get-DnsClientServerAddress # Windows
resolvectl status # Linux, systemd
# 4. Ask the default resolver, and read which server answered
nslookup files.company.local
# 4b. Ask one specific resolver by address, bypassing the order
nslookup files.company.local 10.0.1.10
dig @10.0.1.10 files.company.local
# 6. Ask the authoritative server, bypassing every cache
dig +trace files.company.local
nslookup -type=SOA company.local
# Useful extras
dig example.com +short # just the answer
dig example.com MX # a specific record type
Resolve-DnsName example.com # the modern Windows oneTwo things about reading the output. The server line matters more than the answer. nslookup prints which DNS server responded, and when that is not the one you expected, the diagnosis is finished.
And a non authoritative answer came from a cache, which is normal and is also why you use +trace when you need the truth from the authoritative servers.
By symptomThe DNS failures worth recognizing by sight
Each of these DNS symptoms has a distinctive shape, and knowing the shape skips several checks.
Addresses work, domain names do not. DNS, definitively. Go to layer 3 and check the servers.
Internal domains fail, external domains work. The machine is using a public DNS server instead of the internal one. Almost always a VPN that did not push DNS settings, or a manually set server somebody forgot about.
Short names fail, full domain names work. The DNS search suffix is not being applied. The machine has nothing to append to files, so it never becomes the domain files.company.local.
It works at the command line and fails in the browser. The browser is using encrypted DNS to a public server that has never heard of your internal domain. Turn DNS over HTTPS off in the managed browser settings.
The domain resolves to the wrong address. Either a stale DNS cache, or the split horizon problem where the public and internal records differ. Query the internal server directly to see which.
It works from one site and fails from another. Different DNS servers, or replication between domain controllers. Query each site server directly and compare the records they return.
Everything fails and the machine has a 169.254 address. DHCP never answered. This is a network problem rather than a DNS one, and no DNS command helps until the machine has a real address.
A newly changed DNS record still returns the old value. The old answer is cached somewhere and stays until its TTL expires. Nothing propagates, which the section after next explains.
Record typesThe record types, and the failure each one produces
A domain name resolving is not one thing. Different applications ask for different DNS records against the same domain, and a missing or wrong record produces a failure that looks nothing like DNS not resolving at all. Check the record type the application uses.
| Record | What it holds | The failure when it is wrong |
|---|---|---|
| A | An IPv4 address | The name does not resolve at all |
| AAAA | An IPv6 address | Slow connections, or failures on IPv6 only networks |
| CNAME | Another domain name to follow | A chain that loops, or points at nothing |
| MX | Where mail for the domain goes | Mail bounces while the website works |
| TXT | Free text, used for SPF and verification | Mail marked as spam, or a service refusing to verify |
| NS | Which servers are authoritative | The whole domain fails, everywhere |
| SOA | Zone metadata, including the TTL | Records expiring at unexpected times |
| PTR | The reverse, an address to a name | Mail rejected, and slow logins on some systems |
Three rows produce faults that nobody thinks to blame on DNS.
A stale AAAA record points at an IPv6 address that no longer answers. A machine with IPv6 on the network tries that first, waits for it to time out, and falls back to the A record.
The site loads and takes several seconds, and every other domain is fast. Check the AAAA record specifically, because a default DNS lookup shows you the working A record and tells you nothing.
A CNAME pointing at a name that no longer exists breaks the whole chain. dig follows it and returns nothing useful, and the zone looks correct because the record is present.
An NS record pointing at a DNS server that was decommissioned takes a domain down globally and intermittently, because resolvers pick one of the listed servers at random. Half the queries work. That symptom, working for some people on the network and not others with no pattern, is almost always this.
PropagationPropagation, which is not a thing
The word does real damage, so it is worth replacing.
Nothing propagates through the DNS. When you change a record, the authoritative DNS server has the new value immediately. Every resolver already holding the old answer keeps serving it until the time to live expires, and then asks again.
So the delay is not a process working its way around the world. It is a set of independent countdowns, each started when a particular DNS server last asked. A server that cached your record with a 24 hour TTL five minutes ago serves the old value for another 23 hours and 55 minutes, whatever anybody does.
Two consequences that are actually useful.
Lower the TTL on the records before a planned change, not after. Drop it to 300 seconds a day ahead, make the change, and the world catches up in five minutes. That is the difference between a controlled cutover and a day of intermittent weirdness.
You cannot flush somebody else's DNS cache. Your own machine, yes. Your own servers, yes. A customer ISP resolver on another continent, no. Plan around the TTL you published.
The usual fixesThe standard fixes, and what each one actually does
Search this problem and you get a list of things to try. They are not wrong, and each one only fixes a specific layer, so knowing which layer it touches tells you whether it is worth trying at all.
Restart the router. Fixes a router whose own DNS forwarder has stopped answering, which does happen on consumer hardware. It fixes nothing at layers 1, 3 or 6, and it destroys the evidence. Try it after the two ping test, not before.
Flush the DNS cache. Fixes exactly one thing: a stale or negative answer cached on this machine. If the domain never worked from this machine, there is nothing cached to flush and the command changes nothing.
Change to a public DNS server, 1.1.1.1 or 8.8.8.8. A genuine fix when the ISP or router DNS is broken, and a genuine mistake on a domain joined machine, where it breaks every internal name while appearing to fix the internet. Use it as a test, then put the correct server back.
Restart the DNS Client service on Windows, or sudo systemctl restart systemd-resolved on Linux. A heavier version of flushing the cache, and worth doing when the resolver settings look right and the machine is ignoring them.
Turn off the VPN. Diagnostic rather than a fix. If names resolve with the tunnel down and not with it up, the VPN is not pushing DNS settings, and that is the thing to fix.
Disable IPv6. Appears on every list and is almost always the wrong advice. It masks a stale AAAA record or a broken IPv6 path rather than fixing either, and it will be forgotten and cause a different problem in two years. Find the bad record instead.
Update the network adapter driver. Very rarely relevant to DNS. It survives on these lists because it is generic advice that occasionally coincides with an unrelated fix.
The pattern is worth naming: every item on that list is a fix for one of the six layers, and if you have identified the layer first you already know which one to reach for. Working the list from the top is how a five minute problem becomes an afternoon.
PitfallsWhere people go wrong
Testing DNS in a browser. It has its own cache, may use its own DNS server over HTTPS, and reports a certificate error as though the domain had failed to resolve. Test at the command line.
Restarting the router first. It works often enough to be reinforced and it destroys the evidence. Run the two ping test first, which costs ten seconds.
Setting a public DNS server on a domain joined machine. Internet domains resolve and nothing internal does. This is the most common self inflicted DNS fault in business networks, and it is usually somebody troubleshooting something else entirely.
Reading only the first DNS server in the settings. Machines hold several servers and the order is not always what you expect, particularly with a VPN adapter present. Read the whole list and the interface each one belongs to.
Assuming a slow resolve is a broken DNS server. A domain that resolves in two seconds is usually the first server timing out and the machine falling through to the second. Fix the first entry rather than adding a third.
Blocking outbound port 53 without providing a DNS server. A firewall policy stopping clients from reaching external DNS is correct only if internal servers are reachable and permitted to go out themselves.
Forgetting TCP 53. DNS uses UDP for ordinary answers and TCP for large ones and zone transfers. A firewall permitting only UDP breaks in ways that look intermittent, because it only fails on the large DNS records.
ComparisonThe four things that break, matched to the symptom each one produces
| Criterion | Local cache | Wrong resolver | Resolver unreachable | Record missing |
|---|---|---|---|---|
| Addresses work, names do not | Yes | Yes | Yes | Yes |
| Internal fails, external works | No | Yes | No | Possible |
| One name fails, others work | Yes | No | No | Yes |
| Everything fails, instantly | No | No | Yes | No |
| Everything fails, after a pause | No | No | Yes | No |
| Fixed by flushing the DNS cache | Yes | No | No | No |
| Fixed by checking another DNS server | Yes | Yes | Yes | No |
| Visible in dig +trace | No | No | No | Yes |
The last row is the one to reach for when nothing else has explained it. If +trace shows the authoritative server returning nothing, every cache in the chain is behaving correctly and the record is the problem.
FAQFrequently asked questions
What does DNS not resolving actually mean?
That a domain name did not turn into an IP address. The network may be perfectly fine, which is why the first check is whether an address works when the name does not.
How do I know it is DNS and not the network?
Ping an address such as 1.1.1.1, then ping a domain name. Address working and name failing is DNS. Both failing is a network problem, and DNS troubleshooting will not help.
What does flushing the DNS cache do?
Discards the DNS records the machine remembered, including negative answers. It fixes a domain that was broken and has since been fixed at the source, and nothing else.
Why do internal domains fail on the VPN?
The tunnel is not pushing the internal DNS settings, so the machine asks a public server that has never heard of your internal zone. It is the most common VPN complaint there is.
Why does it work in the terminal and fail in the browser?
The browser is resolving over HTTPS to its own resolver, which does not know your internal names. Turn encrypted DNS off in the managed browser policy.
What is DNS propagation?
A misleading name for cached records expiring. Nothing travels anywhere on the network. Each DNS server keeps its answer until the TTL runs out, then asks again.
How do I make a DNS change take effect quickly?
Lower the TTL a day before the change, not after. Once the old value is cached with a long TTL, you cannot shorten it retroactively.
What port does DNS use?
UDP 53 for ordinary queries and TCP 53 for large records and zone transfers. A firewall that permits only UDP breaks DNS intermittently.
What does a non authoritative answer mean?
That the answer came from a cache rather than from the server that owns the record. It is normal, and dig +trace is how you bypass it.
Why does one machine resolve and another does not?
They are almost certainly using different DNS servers. Compare the full settings on each machine rather than the first entry.
Can I flush a customer's DNS cache?
No. You control your own machines and your own resolvers. Everything beyond that is governed by the TTL you published.
What if the authoritative DNS server has no record?
Then nothing downstream can invent one. The fix is in the zone records, and no amount of flushing or restarting changes it.
What does DNS server not responding mean?
The Windows message DNS server not responding means the computer sent a query to its configured DNS server and got no answer. Either the server address is wrong, the server or router is down, or something between them is blocking port 53. Testing with a public resolver such as 1.1.1.1 shows quickly whether the fault is local.
Keep readingRelated concepts
Read next · Addressing What Is DHCP? A machine with a 169.254 address never got network settings at all, and no DNS command will help. Open this next9 min- Ports · 12 min What Is a Port Number? DNS uses UDP 53 and TCP 53, and a firewall permitting only one breaks it intermittently.
- Diagnostics · 11 min Ping and Traceroute The two ping test that tells you whether this is DNS or the network underneath it.
- DNS · 10 min The SOA Record, Field by Field The symptom a stale secondary actually produces.
- Remote access · 13 min Split Tunneling, and the Trade It Actually Makes What to check when the names break rather than the routes.
- Ports · 10 min Port 53, and Why DNS Needs TCP as Well as UDP The port every lookup in this checklist is using, and the second transport it falls back to more often than people expect.
- Diagnostics · 11 min A Network Troubleshooting Checklist, in the Order That Saves Time Where to go when the by name test is the one that fails.