A DNS failure after recreating a service reminded me that negative DNS responses can be cached too.

The application had deployed successfully, but:

nslookup app.example.internal

returned:

NXDOMAIN

Clearing the Windows cache did not fix it:

ipconfig /flushdns

The useful test was querying another DNS resolver directly:

nslookup app.example.internal <dns-server>

One resolver returned the address while the resolver being used by the workstation continued returning NXDOMAIN.

That proved:

Application     ✓
DNS record      ✓
One resolver    ✓
Client resolver ✗

The hostname had been queried during a period when the record did not exist, and that negative answer had been cached by another resolver layer.

The important troubleshooting question therefore isn’t just:

Have I flushed DNS?

It is:

Which resolver is actually returning this answer?

Windows, VPN/ZTNA clients, browsers, local proxies and upstream resolvers can all introduce additional DNS behaviour.

ipconfig /flushdns only clears the Windows DNS client cache. It cannot clear a separate resolver’s cache.

When a recently created or recreated hostname unexpectedly returns NXDOMAIN, comparing answers from different resolvers can quickly distinguish an authoritative DNS problem from stale negative caching.