DNS Troubleshooting on Windows: When the Internet Works but the Intranet Doesn’t

One of the more frustrating problems in IT is when a user says:

“The internet works, but this one internal site doesn’t.”

At first, it sounds simple. Public websites load fine. Email works. Teams works. But the internal app still refuses to open, or it loads painfully slowly.

In situations like that, the application itself is not always the real problem. Quite often, the issue is one layer lower: DNS.

That is also why I think DNS is worth understanding in a practical way, not just as a protocol you read about once and then forget. In day-to-day admin work, name resolution problems show up more often than people expect.

A very typical scenario

Let’s take a neutral example.

A user tries to open:

http://intranet-app01/portal

What they see is something like this:

• the page does not open at all, or takes too long to load,
• public websites still work,
• nslookup intranet-app01 returns an IP address,
• but the internal application still behaves as if something is wrong.

At that point, it is very tempting to say:

“If nslookup works, DNS is fine.”

I used to think that too in simpler cases. But in real environments, that conclusion is often too optimistic.

Why nslookup helps — but does not always tell the full story

nslookup is still a useful tool. It is quick, simple, and good for checking what a DNS server returns for a given name.

The catch is that a successful nslookup result does not always mean the client is resolving names cleanly in real use.

Microsoft’s own DNS client troubleshooting guide shows why this matters. If a machine has multiple DNS servers configured and some of them are unreachable, Windows may still eventually resolve the name — but only after retries and timeouts. From the user’s point of view, that can look like “the app is slow” or “the site is broken,” even though DNS eventually returns an answer.

So when I troubleshoot DNS now, I try not to stop at:

“Does the name resolve?”

A better question is:

“How does it resolve, from where, and how long does it take?”

How Windows actually resolves a name

One detail I find especially useful from Microsoft’s troubleshooting article is that Windows does not immediately send every query to a DNS server.

The client typically goes through these steps:

1. check the local DNS cache
2. check the Hosts file
3. query the DNS server

That means a “correct” answer is not always coming from the place you think it is.

Sometimes the client is using:

• an old cached entry,
• a negative cache result,
• or a static entry in the Hosts file.

So even when name resolution appears to work, it is still worth asking whether you are looking at live DNS behavior or just local state.

A simple workflow I usually follow

When an internal hostname behaves strangely, I try not to jump between random fixes. I usually go through a short set of checks in the same order.

It does not solve every case, but it helps narrow things down quickly.

1. Check the client’s DNS configuration

I usually start with:

ipconfig /all

This gives me a quick view of:

• which DNS servers are configured,
• in what order,
• and whether anything looks off right away.

If I see multiple DNS servers, I want to know whether all of them are still reachable. Microsoft notes in its DNS troubleshooting guide that unreachable DNS servers can introduce noticeable delays because the client keeps trying before moving on.

That is one of those things that can make an application feel broken even though the underlying name eventually resolves.

2. Compare the default result with a specific DNS server

Next, I usually run:

nslookup intranet-app01
nslookup intranet-app01.corp.example 192.0.2.53

The first command tells me what happens with the machine’s default DNS configuration.

The second helps remove some ambiguity, because I am querying a specific DNS server directly.

According to the official nslookup documentation, you can provide the DNS server explicitly in non-interactive mode, which makes this a useful comparison step.

3. Test the same name with Resolve-DnsName

After that, I often repeat the test in PowerShell:

Resolve-DnsName -Name intranet-app01.corp.example
Resolve-DnsName -Name intranet-app01.corp.example -Server 192.0.2.53

Microsoft’s Resolve-DnsName documentation describes it as functionally similar to nslookup, and I find it really useful when I want clearer, more structured output.

It is especially helpful when I want to compare answers from:

• the default client path,
• and a specific DNS server I actually trust for that zone.

This does not automatically fix anything, of course, but it helps answer a more precise question:

“Is the issue really DNS, or is it the path the client is taking to get the answer?”

4. Inspect the local DNS cache

If the results still feel inconsistent, I check the local resolver cache:

ipconfig /displaydns

Microsoft’s ipconfig reference explains that /displaydns shows the DNS resolver cache, including entries loaded from the local Hosts file and recently resolved records.

I like this step because it helps explain a lot of confusing cases.

For example:

• maybe the client is not querying DNS at all anymore,
• maybe it is holding on to an old result,
• maybe there is a local entry that makes the test misleading.

5. Flush the cache if I suspect stale local state

If I think the cache might be part of the problem, I clear it:

ipconfig /flushdns

Again, this is documented by Microsoft in the ipconfig command reference.

I would not treat this as a magic fix, because it is not. But it is a reasonable troubleshooting step when I want to remove stale local state before testing again.

6. Check whether the short name is the real issue

This is probably one of the most common things behind “it works for some people but not for others.”

Users often type:

http://intranet-app01

instead of:

http://intranet-app01.corp.example

That difference matters more than it seems.

Microsoft’s DNS troubleshooting guide includes examples showing how the DNS suffix search list can affect resolution time and behavior. If the suffix list is long, badly ordered, or just not aligned with the environment, short-name resolution can become slow or inconsistent.

So sometimes the problem is not that DNS is “down.”

Sometimes the problem is simply that:

• the short name is ambiguous,
• the client is trying the wrong suffixes first,
• or the right answer only shows up after too many failed attempts.

What usually turns out to be wrong

In many environments, DNS is not completely broken.

It is just slow, inconsistent, or slightly misleading.

In practice, I have found that the most common causes are things like:

• the primary DNS server is unreachable,
• DNS servers are configured in a bad order,
• the client is using a cached result,
• the Hosts file contains an override,
• users rely on short names instead of FQDNs,
• the DNS suffix search list is too long or poorly ordered,
• or the application is simply less tolerant of delays than a browser is.

That is why I try not to stop at “nslookup works.”

That statement may be true and still not explain the user’s experience.

The question I actually want to answer

When I troubleshoot something like this, I am not really asking:

“Does the name resolve?”

I am usually asking:

“How is the client resolving it, what is it talking to first, and where is the delay happening?”

That small shift in thinking helps a lot.

It turns troubleshooting from random guessing into a more predictable workflow.

A quick checklist I like to keep in mind

Here is the short version:

1. ipconfig /all
2. nslookup shortname
3. nslookup FQDN <specific_DNS_server>
4. Resolve-DnsName -Name FQDN
5. Resolve-DnsName -Name FQDN -Server <specific_DNS_server>
6. ipconfig /displaydns
7. ipconfig /flushdns
8. test the FQDN instead of the short name
9. review DNS server order and suffix search list
10. only then move deeper into the application itself

Final thought

A lot of DNS issues do not look like DNS issues at first.

They look like browser problems, application issues, random network instability, or “something weird on this one computer.”

But sometimes the underlying cause is much simpler than that:

the client is asking the wrong place, in the wrong order, for too long.

That is why I try to troubleshoot DNS methodically instead of jumping straight into random fixes. It saves time, and it usually makes the actual problem easier to explain — both to yourself and to the user who just wants the internal site to work again.

Further reading

If you want to dig a bit deeper, these official Microsoft references are worth bookmarking:

• nslookup command reference
• Resolve-DnsName PowerShell documentation
• ipconfig command reference
• Troubleshoot DNS client name resolution issues