Domains & DNS
DNS cutover validation: prove the new destination before and after the switch
DNS cutover validation is the proof that authoritative nameservers, recursive resolvers, and the application all agree after a change. Checking one browser on one network is not enough because it may be using a cached answer, a local hosts entry, or a different DNS path than customers.
Validate authoritative servers first
Query every authoritative nameserver for the changed record and confirm they return the intended value, TTL, and zone serial where relevant. A mismatch between authoritative servers should be fixed before blaming public propagation.
For delegated zones, confirm the parent still points to the expected nameserver set.
Compare several recursive resolvers
Query the resolver used by your network and at least a few independent recursive services. Differences during TTL expiry can be normal; persistent differences after the old TTL window deserve investigation.
Record the exact answer and timestamp from each resolver. A generic “propagated” badge is not enough evidence.
Test the service by hostname
DNS success only proves address selection. Verify TLS certificate coverage, HTTP status, redirects, application login, forms, background jobs, mail routes, and other functions that depend on the hostname.
When a CDN or reverse proxy is involved, separately confirm the origin configuration where practical.
Define a cutover-complete threshold
Keep the source environment until authoritative data is correct, representative recursors return the new path, real traffic is reaching the destination, and changing application data is coherent.
- Check every authority.
- Sample independent recursive resolvers.
- Test the actual application hostname.
- Retain source until traffic and writes are verified.