When DNS has changed but an application still reaches the old server, compare authoritative answers, the client’s chosen resolver, its local cache and the application’s actual connection. Include negative caching and the internal DNS server’s cache. A correct lookup alone cannot prove that an established application session moved.
This guide concerns Windows DNS clients and servers, with Azure DNS documentation used only for its explanation of records and TTL. It does not deploy Azure resolvers or alter VPN routing. All procedures are source-researched and untested; no DNS record, cache or application was changed.
Record the migration contract
Before investigating, establish the intended name, record type, old endpoint, replacement endpoint and the moment the change was made. Preserve the previous record values and TTL as well as the new values. Record the zone owner and any separate internal and external DNS views.
Identify the application’s actual connection name. It may use a short name, fully qualified name, alias or literal IP address. A change to one public name cannot affect a client that connects through a separate private alias or hard-coded address.
List the relevant populations: office clients, VPN clients, hosted session hosts, remote users and integrations. Their DNS servers and access paths may differ. A successful test from the migration engineer’s workstation covers only that path.
Define which system may accept writes during the transition. If both old and new application copies can process work, DNS caching can become a data-authority problem. Decide how the original instance is restricted or drained using the application’s supported migration design. Do not depend on DNS alone to prevent duplicate writes.
Understand what TTL does
The time to live, or TTL, specifies how long a DNS answer may be cached before it is queried again. Microsoft explains that behaviour in its DNS record guidance. A cache that obtained the previous answer before the change can continue using that answer within its remaining lifetime.
Reducing the authoritative record’s TTL at the moment of cutover does not retroactively shorten a lifetime already held by another cache. That is a consequence of the caching model, so plan any intended TTL reduction early enough for previously cached answers to expire.
Do not promise a universal “DNS propagation time”. The observed result depends on which servers are authoritative, which resolvers clients use, their existing cache state and the application’s connection behaviour. The authoritative record change and the client’s first request to the new application are separate milestones.
TTL also does not direct an existing TCP or application session to disconnect and reopen elsewhere. Treat connection draining or client reconnection as an application operation with its own owner and impact. Record it separately from DNS cache behaviour.
Check the authoritative data first
Have the DNS operator query the authoritative service for the exact name and record type. Confirm the answer matches the approved replacement and that the expected zone actually owns the name. Microsoft’s DNS server troubleshooting guide begins by distinguishing authoritative-data problems from recursive-resolution problems.
Inspect all relevant records in the chain. An alias can point to another name whose address is separately cached or maintained. An IPv4 address change does not automatically change an IPv6 record, and a familiar hostname can exist in separate internal and external zones.
Record the answer, responding server, time and applicable TTL using the approved diagnostic tool. Preserve an unsuccessful answer too. A timeout, a name-not-found response and an unexpected address are different findings.
If the authoritative data is wrong, correct that specific record through the approved change process. Do not flush caches throughout the environment to conceal an incorrect source answer. Clients will simply obtain the wrong answer again.
Follow the client’s real resolver path
On an affected Windows client, inspect its actual network and DNS-server configuration. Compare it with a client that behaves correctly. Include the active VPN or remote-access context rather than assuming the settings observed before connection still govern the request.
Microsoft’s DNS client troubleshooting guidance distinguishes short-name and fully qualified name tests and points to DNS suffix configuration where those behave differently. A short name can resolve through a different suffix from the one the migration team changed.
Use the established DNS diagnostic tool to query the configured resolver for the exact name and record type. Where necessary, query a specified resolver to separate server differences. Record which tool was used because not every test exercises the same cache path.
In particular, Microsoft states that nslookup does not use the client’s DNS cache S1. A correct nslookup answer therefore does not prove that an application using normal client resolution has discarded its previous result. This is a common reason for apparently contradictory observations.
The article does not provide a blanket cache-flush command. A targeted cache reset can be a reviewed diagnostic action, but first preserve the answer and its origin. Clearing evidence on every machine makes the cause harder to reconstruct and may affect unrelated lookups.
Compare resolver answers with the Windows cache
These untested Windows commands need an approved client and reachable DNS servers; they do not flush caches or change records R1, R2. Replace the reserved example addresses with the verified internal resolver and authoritative server. Query the full hostname, including the final dot:
ipconfig /displaydns
nslookup -type=A app.example.test. 192.0.2.53
nslookup -type=A app.example.test. 192.0.2.54
nslookup -type=AAAA app.example.test. 192.0.2.53
The second server is useful only if it is actually authoritative for that zone and permits the query. Record each responder, answer, alias and address family. An internal split-DNS zone can legitimately differ from the public zone.
ipconfig /displaydns shows the Windows client resolver cache. Microsoft identifies Name does not exist under the failing name as a cached negative response S1. A name queried before creation can therefore remain unavailable locally even after the authoritative record exists. Preserve that evidence before the owner decides whether a targeted cache clear is justified.
An organisation's Windows DNS server also caches answers S2. Clearing a PC cannot clear that server's cache. The DNS owner should inspect the server's cached answer and upstream path separately; this article supplies no blanket server-cache flush.
RFC 2181 section 8 describes TTL as a maximum caching lifetime, not a mandatory retention period R3. The statement that a newly reduced authoritative TTL cannot retroactively shorten an already held cached answer is reasoning from that model: caches learn the new value when they obtain a new answer. Resolvers may discard entries sooner.
Confirm which endpoint the application used
Correlate a fresh synthetic request with access logs or an approved environment identifier on the old and new application servers. A browser showing a familiar login page does not establish which copy generated it.
If the application still uses the original endpoint while the relevant DNS query returns the replacement, inspect its connection lifetime and supported caching behaviour. Look for application configuration that bypasses the changed name. Work with the software owner rather than assuming Windows is the only cache involved.
Use a fresh test session where appropriate, but record what changed. Closing an application, restarting a service and clearing a system cache test different hypotheses. An improvement after doing all three at once does not identify the cause.
For a database-backed service, also confirm the backend destination. The web frontend may have moved correctly while its database connection still reaches the original environment. This is an application dependency check, not proof that the public DNS cutover failed.
Keep certificate and authentication failures distinct
Once a client reaches the replacement, verify the hostname remains valid for TLS and the intended authentication path. A certificate warning is not a reason to switch the connection to an IP address or disable verification. Doing so changes the identity being tested.
Likewise, SQL integrated authentication may require the correct service identity for the retained alias. The companion Kerberos article covers that investigation. Do not undo a correct DNS change simply because an unrelated destination prerequisite was missed.
Record each boundary separately: expected DNS answer, correct listener, accepted certificate, authenticated identity and usable business operation. This makes partial success visible without claiming the application is ready merely because resolution works.
If a network path fails only after the move, pass the exact client, resolved address and destination port to the network owner. Use the firewall and VPN owners’ supported diagnostics for those faults. Repeating DNS changes will not repair a missing return route.
Design a return plan that accounts for writes
Restoring the old DNS value is another DNS change with its own cache and connection behaviour. It is not an instantaneous reversal. Retain the same resolver and application-path observations when assessing the return.
More importantly, determine whether the new application has accepted writes. If it has, redirecting users to a stale old copy can lose or split business work. The data owner must approve reconciliation or a supported return procedure before traffic moves back.
Keep the old environment available only under the agreed authority and access controls. Retaining it for evidence or reversal does not mean leaving its schedulers, integrations and write endpoints active. The scheduled-jobs companion article explains those activation decisions.
Do not use a second unplanned DNS change as the first troubleshooting step. Preserve the current answers and identify the failing boundary before expanding the incident.
Accept the cutover with observed evidence
Verify the relevant client populations through their normal access paths. Record the authoritative and recursive answers, the endpoint actually serving requests and the application result. Include IPv4/IPv6 or alias differences where the application uses them.
Account for existing sessions through a supported drain or reconnection plan. Agree the observation interval from actual TTLs, connection behaviour and business requirements rather than selecting an arbitrary delay.
The old instance’s lack of recent traffic is useful evidence only within the logging scope. Check scheduled integrations and infrequent clients before retiring it. Keep unresolved populations listed with owners instead of declaring the whole migration complete from a single successful browser session.
Limitations
Windows client/server diagnostics are the reference. Application caches, encrypted DNS clients, split DNS and persistent connections need separate evidence. The Microsoft client troubleshooting page displays 7 August 2020; its examples are not proof of every current application’s resolver behaviour.
Acceptance checklist
- Authoritative and intended recursive answers recorded by address family.
- Client positive/negative cache and internal server cache distinguished.
- Actual application destination and connection lifetime checked.
- Write authority and data reconciliation included in any return decision.
Learning notes
- A correct authoritative record does not mean every cached answer has expired.
- DNS query tools and applications can exercise different cache paths.
- Traffic reversal must preserve writes already accepted by the new system.
Related reading: SQL Kerberos After Migration: Check SPNs and NTLM Use; Renew IIS TLS Certificates and Verify the Live Endpoint; Scheduled Jobs After Migration: Prevent Duplicate Work.
Sources and review status
Sources accessed 30 October 2026. Exact displayed dates, scope and claim mapping are in the accompanying evidence file. Revised after independent review; independent recheck pending. All examples remain untested and no lab validation is claimed.
- Troubleshooting DNS clients | Microsoft Learn
- Troubleshooting DNS Servers | Microsoft Learn
- DNS Zones and Records Overview | Microsoft Learn
Additional revision sources: