DNS Changed, but Your Website Still Opens the Old Server?

Last Edited

by

Editorial Team

in

Three glass hourglasses with different amounts of sand remaining, surrounded by network cables and server racks.
Cached DNS answers have independent countdowns, so users do not all see a change at the same moment.

On Windows, this provides a basic alternative for the same resolver comparison:

nslookup -type=A app.example.com
nslookup -type=A app.example.com 1.1.1.1

Microsoft documents nslookup’s optional server argument. Its normal output does not provide dig’s TTL detail.

3. Check the Address Type and the Application

An A record maps a name to IPv4. An AAAA record supplies IPv6. Updating one does not update the other. Repeat the relevant lookups with AAAA instead of A; a working IPv6 path may lead a browser to an address you overlooked.

If command-line results are correct but one browser behaves differently, check its resolver settings and application state. A browser can use a separately selected encrypted DNS provider; Chrome’s Secure DNS settings are one example. Private browsing does not guarantee a fresh lookup through the same resolver your command-line tool queried.

On Windows, you can inspect and clear the DNS Client cache:

ipconfig /displaydns
ipconfig /flushdns

This clears the local cache described in Microsoft’s ipconfig documentation. It does not clear an ISP’s resolver, every browser cache, or a CDN’s content cache.

If the application reaches the expected server address but shows old content, investigate the website, reverse proxy, or content cache. Another DNS edit is unlikely to solve that problem.

Two Reasons Waiting Can Be Misleading

Negative caching: a resolver can remember that a name does not exist (NXDOMAIN) or that a requested record type is absent (NODATA). Creating the missing record does not instantly erase that earlier answer. RFC 2308 derives the negative-cache TTL from the lesser of the SOA record’s TTL and its MINIMUM field, rather than from the newly created A record’s TTL.

Serve-stale behavior: some resolvers can return expired data when they cannot refresh it successfully. RFC 8767 defines this resilience mechanism. Therefore, the old record’s original TTL is not an absolute upper bound in every failure scenario.

Neither case justifies waiting indefinitely. Persistent failures require checking the relevant authoritative responses and resolver behavior.

Plan the Next Change Around Evidence

Before a planned address change, reduce the TTL early enough for old cached copies to expire, then verify that the shorter TTL is published. Keep the old endpoint available during the transition where practical, and plan data synchronization so users reaching different endpoints do not create divergent writes.

After the change, compare authoritative answers, recursive answers, and the application’s actual destination. There is no universal “48 hours” test. The migration is ready when the intended records are published, the resolution paths you depend on have been checked, and the application works at the destination they return.

Search