Fix DNS on Windows: Stop Using “Flushdns” Like a Ritual

February 25, 2026 • February 25, 2026 • Read: 20 min • Views: 1

Was this helpful?

If you’re reading this, you’ve probably watched someone type ipconfig /flushdns with the confidence of a wizard casting a spell. Sometimes it “works,” sometimes nothing changes, and sometimes it makes things worse by wiping the only useful clue you had: what the machine thought was true five seconds ago.

DNS failures on Windows are rarely solved by a single command. They’re solved by understanding which resolver is in play, which cache is lying, and which network component is “helping” you into a hole. Let’s stop doing DNS exorcisms and start doing diagnostics.

What `flushdns` actually does (and what it does not)

ipconfig /flushdns clears the Windows DNS Client resolver cache. That’s it. It does not:

Change which DNS servers you’re using.
Fix a broken VPN DNS policy.
Undo a bad search suffix list.
Remove a stale record from your company DNS server.
Reset Winsock, firewall rules, or proxy settings.
Fix an application that’s doing its own DNS (many do).

It can help when the cache contains a bad answer or a negative entry (NXDOMAIN) that you want to re-check immediately. It can also hide the evidence when you’re trying to learn whether the failure is “local cache” or “upstream DNS.” You don’t want to erase evidence until you know what you’re looking at.

Two important realities:

DNS issues are often policy issues. The machine is doing exactly what it was told, and what it was told is wrong.
Windows is not your only resolver. Browsers, VPN clients, security agents, and endpoint management tools can introduce their own caches and DNS behaviors.

Here’s the operational mindset: treat flushdns like restarting a service. Sometimes it’s a useful last step. It’s not a first step. If your first move is to delete state, you’ve chosen blindness.

Fast diagnosis playbook

This is the “you’re on a call, someone is yelling, and you need signal in 90 seconds” sequence. Run it in order. Don’t freestyle until you’ve nailed the category of failure.

1) Is this DNS or not-DNS?

Can you reach an IP address but not a name?
Is it only one hostname or all hostnames?
Is it only inside corporate domains (e.g., corp.example)?

2) Identify the active DNS path

Which interface is being used (Wi‑Fi, Ethernet, VPN, virtual adapter)?
Which DNS servers are configured on that interface right now?
Is a VPN enforcing DNS or split tunneling?

3) Compare resolvers

Does nslookup succeed while the browser fails?
Does PowerShell Resolve-DnsName give different results than nslookup?

4) Check for caching and negative caching

Is the local cache holding NXDOMAIN?
Are you racing TTLs (answers changing during incident)?

5) Only then: reset/flush as a controlled experiment

Flush the cache and re-query the same name.
Log what changed. If nothing changed, stop flushing.

Paraphrased idea from David J. Wheeler: All problems in computing can be solved by adding another layer of indirection—except the problems caused by indirection. DNS is indirection with feelings.

How Windows resolves names: the real order of operations

When someone says “DNS is broken,” they usually mean “name resolution is broken.” On Windows, name resolution can involve:

Hosts file (C:\Windows\System32\drivers\etc\hosts)
DNS Client service (cache + querying configured DNS servers)
DNS suffix search list (turning app into app.corp.example)
LLMNR (Link-Local Multicast Name Resolution) and NetBIOS in some environments
mDNS for .local scenarios (depends on components installed)
Proxy and PAC scripts (not DNS, but makes “can’t reach by name” look like DNS)
Application resolvers (browsers and runtimes may cache or use DoH)

Some of these are “helpful” until they aren’t. For example:

If hosts overrides a name, flushing DNS won’t change it. That override wins.
If your browser is using DNS over HTTPS (DoH), flushing Windows DNS may not touch the browser’s resolver path.
If the DNS server is fine but you’re querying the wrong one (VPN adapter took precedence), flushing doesn’t fix precedence.

One more nuance: nslookup is not “the Windows resolver.” It’s a diagnostic tool that talks to a DNS server. It can bypass parts of the Windows name resolution stack and caching behavior. When nslookup works but the app doesn’t, that’s not a contradiction—it’s your clue.

Joke #1: Flushing DNS to fix everything is like rebooting a printer to fix your tax return. It changes your mood, not the facts.

Interesting facts and historical context (because this got weird over time)

DNS is older than the web. DNS was designed in the early 1980s to replace manual HOSTS.TXT files that didn’t scale.
Negative caching is deliberate. Caching NXDOMAIN prevents repeated queries for non-existent names from hammering authoritative servers.
Windows DNS Client caching has been “sticky” by design. The cache exists to reduce latency and load, which makes it a suspect during fast-changing incidents.
Search suffixes were built for humans. Enterprises wanted mail or intranet to work without typing a full domain every time.
Split DNS predates modern VPN hype. Large organizations have long needed internal answers for internal zones, and different answers when off-network.
LLMNR exists because people hate typing. It’s a convenience protocol for local networks, but it’s also a security risk and often disabled in hardened environments.
DoH is partially a reaction to hostile networks. Encrypting DNS queries reduces on-path snooping and tampering, but can complicate corporate policy and incident response.
EDNS0 and larger responses changed failure modes. DNS answers got bigger (think DNSSEC, many records), and path MTU/fragmentation issues started showing up as “random DNS timeouts.”
“DNS server not responding” is often a lie. The DNS server may be fine; the client may be blocked from reaching it on UDP/TCP 53, or it’s querying the wrong interface.

Practical tasks: commands, outputs, and decisions (12+)

Every task below includes a command, what output means, and what decision you make. Use them as a toolbox. Don’t run them like a script you found on a forum.

Task 1: Confirm which DNS servers Windows is actually using

cr0x@server:~$ ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : LPT-0442
   Primary Dns Suffix  . . . . . . . : corp.example
   DNS Servers . . . . . . . . . . . : 10.20.0.10
                                       10.20.0.11

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . . : corp.example
   DNS Servers . . . . . . . . . . . : 10.20.0.10
                                       10.20.0.11

Ethernet adapter VPN:

   Connection-specific DNS Suffix  . . : vpn.corp.example
   DNS Servers . . . . . . . . . . . : 172.16.50.53

Meaning: You might have multiple adapters, each with different DNS servers. Windows will choose based on interface metrics and policies.

Decision: If the VPN adapter is active and has a DNS server, validate whether it should be authoritative for the names failing. If not, you’re looking at a precedence/metric or VPN policy issue, not a cache issue.

Task 2: Identify which interface is preferred (metrics)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface | Sort-Object -Property InterfaceMetric | Select-Object -First 8 | Format-Table -AutoSize"

ifIndex InterfaceAlias     AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp   ConnectionState
------- --------------     ------------- ------------ --------------- ----   ---------------
24      VPN               IPv4          1400         5               Enabled Connected
12      Ethernet          IPv4          1500         25              Enabled Connected
9       Wi-Fi             IPv4          1500         55              Enabled Connected

Meaning: Lower metric wins. Here, VPN is preferred for IPv4 traffic and often for DNS behavior.

Decision: If DNS failures happen only when VPN is connected, focus on VPN DNS servers, split DNS configuration, and NRPT/policies. Don’t bother with flushdns yet.

Task 3: Query using the Windows resolver (not nslookup)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName app.corp.example -Type A"

Name           Type TTL Section IPAddress
----           ---- --- ------- ---------
app.corp.example A   30 Answer  10.30.40.25

Meaning: This shows what the Windows resolver returns and the TTL it sees.

Decision: If Resolve-DnsName fails but nslookup works, you likely have local policy/caching or name resolution order issues. If both fail, suspect upstream DNS or network reachability.

Task 4: Query a specific DNS server to bypass “whatever Windows chose”

cr0x@server:~$ nslookup app.corp.example 10.20.0.10

Server:  dc01.corp.example
Address:  10.20.0.10

Name:    app.corp.example
Address: 10.30.40.25

Meaning: This confirms whether the target DNS server can answer correctly.

Decision: If querying a known-good DNS server works, but default queries fail, focus on which DNS server the client is actually using (adapter order, VPN, DHCP options, static DNS, security agent).

Task 5: Check for negative caching and what’s in the cache

cr0x@server:~$ ipconfig /displaydns

    app.corp.example
    ----------------------------------------
    Record Name . . . . . : app.corp.example
    Record Type . . . . . : 1
    Time To Live  . . . . : 18
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 10.30.40.25

Meaning: You can see what Windows cached and how long it intends to keep it.

Decision: If the cache contains NXDOMAIN or an old IP that no longer routes, flushing may be justified. But ask: why is it wrong? Bad upstream? Split brain? Stale records? Fix the source.

Task 6: Flush DNS cache (as a controlled test)

cr0x@server:~$ ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Meaning: Cache cleared. No guarantee that the next answer will be better.

Decision: Immediately re-run the same query and compare. If the answer doesn’t change, the cache wasn’t the problem.

Task 7: Verify the DNS Client service is running

cr0x@server:~$ powershell -NoProfile -Command "Get-Service Dnscache | Format-List Status,Name,StartType"

Status    : Running
Name      : Dnscache
StartType : Automatic

Meaning: The DNS Client service provides caching and some resolution logic.

Decision: If it’s stopped/disabled (sometimes due to “tuning” guides), expect strange behavior and poor performance. Set it back unless you have a very specific controlled environment.

Task 8: Check search suffix behavior (why short names fail)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientGlobalSetting | Format-List SuffixSearchList"

SuffixSearchList : {corp.example, prod.corp.example}

Meaning: When you type app, Windows may try app.corp.example and other suffixes.

Decision: If users report “short names used to work,” validate suffix list distribution (GPO, DHCP option 15/119, VPN policy). Fix the suffix list, not the cache.

Task 9: Confirm what DNS servers are set per interface (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"

InterfaceAlias ServerAddresses
-------------- ---------------
Ethernet       {10.20.0.10, 10.20.0.11}
VPN            {172.16.50.53}
Wi-Fi          {192.168.1.1}

Meaning: This makes it obvious when home Wi‑Fi DNS or a hotel captive portal DNS is in the mix.

Decision: If you see public or consumer DNS on an interface that should not be authoritative for internal zones, use split DNS correctly (VPN) or adjust interface precedence.

Task 10: Test reachability to DNS servers (don’t assume “responding”)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 10.20.0.10 -Port 53"

ComputerName     : 10.20.0.10
RemoteAddress    : 10.20.0.10
RemotePort       : 53
InterfaceAlias   : Ethernet
TcpTestSucceeded : True

Meaning: DNS primarily uses UDP, but TCP 53 matters for large responses and retries. This at least proves a path to TCP 53.

Decision: If TCP 53 fails, you may have firewall rules, VPN ACLs, or security software blocking DNS. That’s a networking/security fix, not a flushing fix.

Task 11: Detect if a proxy/PAC is masquerading as DNS trouble

cr0x@server:~$ netsh winhttp show proxy

Current WinHTTP proxy settings:

    Proxy Server(s) :  proxy.corp.example:8080
    Bypass List     :  (none)

Meaning: Some apps use WinHTTP proxy settings. A broken proxy can look like “DNS failure” because the app can’t fetch anything by name.

Decision: If name resolves but HTTP fails, inspect proxy/PAC and authentication. Don’t keep poking DNS.

Task 12: Check the hosts file for landmines

cr0x@server:~$ type C:\Windows\System32\drivers\etc\hosts

# Copyright (c) Microsoft Corp.
# ...
10.30.40.99   app.corp.example

Meaning: That single line overrides DNS. Forever. Until someone remembers it exists.

Decision: If the hosts file pins an old address, remove it and document why it was there. If it’s required (rare), manage it centrally, not by tribal knowledge.

Task 13: Reset Winsock (only when symptoms match)

cr0x@server:~$ netsh winsock reset

Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.

Meaning: This repairs some socket-layer problems caused by LSPs or network software, not “DNS records.”

Decision: Use when multiple networking operations fail in weird ways (not just one hostname). Expect a reboot requirement. If DNS is the only symptom, this is probably overkill.

Task 14: Reset the IP stack (when interface behavior is corrupted)

cr0x@server:~$ netsh int ip reset

Resetting Global, OK!
Resetting Interface, OK!
Resetting Neighbor, OK!
Resetting Path, OK!
Resetting , OK!
Restart the computer to complete this action.

Meaning: Resets TCP/IP configuration to defaults.

Decision: Use when you suspect the stack is poisoned by drivers, VPN clients, or manual tweaks. If the problem is clearly upstream DNS, this won’t help.

Task 15: Release/renew DHCP (when DNS servers came from DHCP)

cr0x@server:~$ ipconfig /release

Windows IP Configuration

No operation can be performed on Ethernet while it has its media disconnected.

Meaning: Here Ethernet isn’t connected, so release doesn’t apply. That itself is a clue.

Decision: Run this on the active interface scenario. If DNS servers are wrong due to DHCP options, renew can pull correct settings—if DHCP is configured correctly. If DHCP is wrong, fix DHCP, not endpoints.

Task 16: Validate if the failing name is returning multiple addresses (and whether one is dead)

cr0x@server:~$ nslookup api.corp.example 10.20.0.10

Server:  dc01.corp.example
Address:  10.20.0.10

Name:    api.corp.example
Addresses: 10.30.40.10
          10.30.40.11
          10.30.40.12

Meaning: Round-robin or multi-A records can make failures appear “intermittent” if one backend is down.

Decision: If one IP is dead, don’t flush caches on clients. Remove/health-check that record, fix the load balancing strategy, or repair the dead backend.

Common mistakes: symptom → root cause → fix

This is where most teams lose time: they treat a symptom as a diagnosis. Here are the repeat offenders.

1) “DNS is broken” but only one site fails

Symptom: Only app.corp.example fails; everything else resolves and works.

Root cause: Stale DNS record, wrong TTL expectations, or multi-record name where one IP is dead.

Fix: Query authoritative DNS servers directly and inspect records. Remove bad records, lower TTL for migrations, ensure monitoring removes dead endpoints from DNS or front with a load balancer.

2) `nslookup` works, browser doesn’t

Symptom: nslookup shows correct IP, but Chrome/Edge says name can’t be resolved or can’t connect.

Root cause: Browser DoH enabled, browser DNS cache stale, proxy/PAC issue, or the browser is attempting IPv6 first and failing.

Fix: Check browser DNS settings (including secure DNS/DoH), clear browser DNS cache if needed, validate proxy configuration, compare IPv4 vs IPv6 resolution and connectivity.

3) Works on VPN, fails off VPN (or the reverse)

Symptom: Internal names resolve only when VPN is connected, or VPN breaks public name resolution.

Root cause: Split DNS not configured correctly; VPN pushes DNS server for everything; interface metrics cause DNS to prefer the wrong adapter.

Fix: Correct split tunnel and DNS policies in the VPN client/profile. Ensure internal zones go to corporate DNS, public zones to local resolver (or a sanctioned resolver), and metrics behave as intended.

4) Random timeouts after “security hardening”

Symptom: DNS sometimes times out; retries succeed; large records fail more often.

Root cause: Firewall blocks TCP 53 or fragments; DNS responses exceed MTU; security software intercepts DNS.

Fix: Allow UDP and TCP 53 where appropriate, validate MTU (especially with VPN), and ensure DNS inspection products are compatible and correctly configured.

5) Short names stopped working

Symptom: intranet used to resolve; now only intranet.corp.example works.

Root cause: Search suffix list changed (GPO, DHCP option, VPN policy), or you moved networks with different suffix policies.

Fix: Restore the correct suffix search list and make it deterministic (GPO for domain-joined devices, well-defined DHCP options, consistent VPN settings).

6) “Flushdns fixed it yesterday” becomes the team’s process

Symptom: People flush caches daily; incident notes say “resolved by flushdns.”

Root cause: Underlying DNS record churn, low TTL migrations, or intermittent upstream failures—flushing just forces re-query and occasionally hits a good server.

Fix: Add observability: log DNS server health, measure NXDOMAIN rates, verify replication/zone transfer, and stop using endpoints as your canaries.

Three corporate mini-stories (how this fails in real life)

Mini-story 1: The incident caused by a wrong assumption

In a mid-sized enterprise, a team migrated an internal service from one subnet to another. They updated the A record, saw the new IP resolve on their own laptops, and declared victory. A few hours later, half the helpdesk tickets were “can’t log in,” and the other half were “works for me.” The worst kind of outage: the Schrödinger outage.

The wrong assumption was simple: “Once we update DNS, everyone will see it quickly.” The TTL was not low, and some clients were holding onto old answers. Worse, a handful of app servers used a local DNS cache inside the runtime, with a default TTL that ignored the record’s TTL. They were the ones failing the most, and they were the ones nobody checked first.

The response team started with endpoint advice. Flush DNS. Restart browsers. Reboot. Predictably, it “fixed” some machines and didn’t touch the servers that mattered. Every flush made the troubleshooting noisier because cached state was constantly being destroyed and recreated.

The fix was boring: they validated TTL, identified the authoritative servers, confirmed replication, then rolled the migration with a planned overlap window. They also documented the runtime-level DNS caching settings and adjusted them to respect TTLs or to use a resolver library with sane caching behavior.

After the postmortem, the team banned “flushdns fixed it” as a resolution note. If you can’t say what was wrong, you didn’t fix it—you just stopped looking at it.

Mini-story 2: The optimization that backfired

A security team rolled out a “privacy improvement” baseline: prefer encrypted DNS. Sounds good in a vacuum. They enabled a policy that pushed clients toward DoH with a small set of approved resolvers. On paper, it reduced exposure to hostile Wi‑Fi. In production, it broke split DNS for internal zones because those external resolvers didn’t know anything about internal names.

At first, the symptoms were subtle. Public websites worked. Internal apps intermittently failed, especially when users were off-network. People blamed VPN instability. Helpdesk blamed laptops. The VPN team blamed DNS. Everyone was correct in the worst possible way.

Meanwhile, some apps used the OS resolver; others used embedded resolvers. So the same machine could resolve git.corp.example in one tool but not in another. Engineers started doing what engineers do under pressure: they wrote a one-liner “DNS fix” script that flushed caches, restarted services, and toggled adapters. It reduced tickets while making root cause analysis harder.

The eventual fix wasn’t “disable DoH forever.” It was to implement a policy that honored split DNS: internal zones resolved via corporate DNS (typically via VPN), while public zones could use encrypted DNS if allowed. They also improved telemetry: “Which resolver did this query actually use?” turned out to be the missing graph.

Joke #2: DNS over HTTPS is great until you need DNS over “Hey, why is nothing resolving?”

Mini-story 3: The boring but correct practice that saved the day

A finance company had a rigid change process for DNS. Engineers hated it because it required a ticket, peer review, and a mandatory “TTL and rollback plan” field. It felt like bureaucracy until the day an internal zone was accidentally updated with a typo that pointed a critical service name at a non-existent IP.

The incident started as an alert storm: connection failures, retries, partial outages. Someone suggested flushing caches on the call. The incident commander said no—hold state, gather evidence. That was the moment discipline paid rent.

They pulled the current record set from the authoritative servers, compared it to the approved change request, and saw the mismatch immediately. Because the change process required recording the previous values, rollback was a clean revert. Because they required a TTL plan, the blast radius was predictable. And because they had a runbook that started with “verify authoritative,” they didn’t waste 45 minutes arguing about which laptop had which cache.

The fix took minutes, not because they were brilliant, but because they were consistent. “Boring” is a compliment in operations.

Checklists / step-by-step plan

This is the plan you can hand to a team and expect roughly consistent results. It avoids superstition and forces you to decide based on evidence.

Checklist A: When a user says “DNS is down”

Get the exact failing name(s) and error message(s). One name or many?
Ask whether it fails on VPN, off VPN, or both.
Run ipconfig /all and capture DNS servers and suffixes.
Run Resolve-DnsName the.name and save output.
Run nslookup the.name configured-dns-server to validate upstream.
If results differ, identify which resolver path the application uses (browser DoH, proxy).
Only after that: consider ipconfig /displaydns and /flushdns as a controlled test.

Checklist B: When only internal names fail

Confirm the user is using corporate DNS servers (not home router DNS).
Check VPN adapter metrics and DNS servers.
Validate search suffix list includes the internal domain.
Query the authoritative server for the internal zone directly.
Inspect whether the internal name exists in public DNS accidentally (split-brain risk).

Checklist C: When failures are intermittent

Query multiple times and record answers and TTLs. Look for rotating addresses.
Test connectivity to each returned IP (ping isn’t enough; test the real port/protocol).
Look for one dead backend in a multi-A record set.
Validate UDP and TCP 53 reachability to DNS servers (especially over VPN).
Check whether a security product is intercepting DNS queries or rewriting responses.

Step-by-step “stop the bleeding” plan for helpdesk

Collect: failing hostname, whether VPN is connected, and a timestamp.
Run and paste: ipconfig /all.
Run and paste: nslookup failing.name and nslookup failing.name <dns server from ipconfig>.
If the DNS server in ipconfig is wrong (e.g., home router while on VPN), escalate to VPN/networking with that evidence.
If the DNS server is correct but answers are wrong, escalate to DNS operations with the record evidence.
Only if the cache clearly holds a wrong answer: run ipconfig /flushdns and re-test. Document before/after.

FAQ

1) Why does `ipconfig /flushdns` sometimes “fix” it?

Because you forced a re-query, and the next query happened to hit a different DNS server, a different path (VPN came up), or a record had just been corrected upstream. That’s correlation, not a durable fix.

2) If flushing is not first, what is?

Identify the DNS servers and interface in use (ipconfig /all plus interface metrics), then compare OS resolver results (Resolve-DnsName) with direct server queries (nslookup name server).

3) Why does `nslookup` disagree with what apps do?

nslookup queries a DNS server directly and doesn’t always reflect the full Windows resolver behavior, suffix search behavior, or application-specific DNS (like DoH). It’s useful, not authoritative for “what the app will do.”

4) What’s the difference between clearing DNS cache and resetting Winsock?

Clearing DNS cache removes cached name-to-IP answers. Resetting Winsock repairs socket layer configuration and provider catalogs. Winsock reset is for broader “network stack is corrupted” symptoms, not for a single stale DNS record.

5) Can the DNS Client service being disabled cause issues?

Yes. Disabling it can break caching behavior and performance, and it can affect how the system handles name resolution. Unless you have a strict, tested reason, keep it running.

6) Why do internal names fail when I’m off VPN?

Because your current DNS servers (home router, ISP, public resolver) don’t know about internal zones. The fix is correct split DNS and routing via VPN, not repeated cache flushing.

7) How do I know if DNS over HTTPS is involved?

If browsers resolve differently than OS tools, suspect DoH. Check browser “secure DNS” settings and your enterprise policies. You can also compare results between Resolve-DnsName and browser behavior.

8) What if DNS resolves, but connections still fail?

Then it’s probably not DNS. It may be routing, firewall, proxy, TLS inspection, or the service itself. Validate connectivity to the resolved IP and port and inspect proxy configuration.

9) Should we lower TTLs to make DNS changes propagate faster?

Sometimes, yes—before a planned migration, lower TTL in advance, then raise it afterward. But don’t treat low TTL as “instant propagation,” and don’t forget application-level DNS caching can ignore TTLs.

10) Is editing the hosts file a valid fix?

As an emergency workaround for a single machine, occasionally. As a general solution, no. It bypasses central control, makes incidents harder, and tends to outlive the reason it was created.

Conclusion: next steps that actually stick

Stop letting ipconfig /flushdns be your team’s coping mechanism. It’s a tool, not a cure. The cure is figuring out which resolver path is failing and why.

Practical next steps:

Adopt the fast diagnosis playbook. Use it on every “DNS is down” ticket until it becomes muscle memory.
Standardize what evidence you collect: ipconfig /all, Resolve-DnsName, and a direct nslookup name server.
Harden your DNS change process: require TTL planning and rollback values. Make it boring on purpose.
Audit split DNS and DoH policies together. If security and networking don’t coordinate, users will become your integration test.
When you do flush caches, document the before/after result and the hypothesis you were testing. Otherwise you’re just mashing buttons.