Flushing DNS clears a local cache; it does not clear every resolver on the Internet. Use it when the local device appears to hold a stale answer, then compare the result with the resolver and authoritative zone instead of repeatedly resetting the network.
Where an old answer can live
A name lookup can involve application caching, an operating-system resolver cache, and a recursive DNS server. The authoritative server publishes the source records, while other layers may reuse answers. A TTL tells a cache how long an answer can remain valid; it is not a scheduled push notification to every device.
Negative results can be cached too. If you queried a hostname before creating it, an earlier nonexistent-name response may temporarily outlive the change. That differs from a connection error after a valid address has already been returned.
Inspect and clear the Windows cache
ipconfig /displaydns
ipconfig /flushdns
nslookup example.comUse an elevated terminal if the operation requires permission. The first command can show cached names, the second clears the local resolver cache, and the final query helps inspect an answer from a DNS server. They test different layers, so do not assume every application has now forgotten its own stored answer.
A browser using encrypted DNS can choose a resolver independently of the system configuration. Fully restarting an application may refresh its own state, but check its resolver settings before interpreting a disagreement with command-line output.
A realistic DNS migration timeline
Suppose an A record had a TTL of 3600 seconds. Lowering it to 300 immediately before the move does not shorten copies already cached under the old TTL. Lower the TTL sufficiently ahead of the change, allow earlier caches to age out, and keep the old service working during the transition where practical.
After changing the record, check the authoritative zone and selected recursive resolvers. Some answers may temporarily differ. A typo in the new record will not fix itself by waiting longer, so distinguish a correct new authoritative answer from an unpublished or incorrect change.
When flushing helps—and when it does not
- One device holds an old address: a local flush and application restart are useful comparisons.
- Several devices receive the same old resolver answer: investigate that resolver or wait for its valid cache to expire.
- The authoritative zone is wrong: edit the correct DNS record first.
- DNS is correct but HTTPS fails: inspect routing, service listeners, certificates, and firewall rules.
Do not release a DHCP lease or reset the entire network stack merely to clear a DNS cache. Those operations interrupt connectivity and address separate problems. Record the hostname, record type, resolver, answer, and time; that small log makes a migration issue much easier to resolve.
Put it into practice
References & further reading
Protocol standards and official documentation supporting this guide. Device menus and provider policies vary; use the documentation for your equipment when applying a change.