Troubleshooting
Open DNS Resolver Comparison →1. Inventory the service and prepare recovery
List website hostnames, redirects, certificates, application services, scheduled jobs and persistent data. Verify a restorable backup and note the current DNS records and TTLs. Keep secrets outside the repository. Define the destination and a rollback decision point before moving traffic.
2. Validate the destination before cutover
Use a staging hostname or an administrator-controlled hostname override to check the new origin. Verify static routes, API behavior, redirects and persistent data. When using a temporary hostname, repeat certificate and hostname-sensitive checks with the production hostname before declaring readiness. Keep staging out of search indexing with a host-specific noindex policy.
3. Coordinate the final data transfer
For single-writer services, stop old writers and schedulers before the final copy, then verify ownership, permissions and checksums at rest. Start the new writer only after transfer verification. Do not rerun an old snapshot over new data after the destination has accepted writes. Database migrations need a database-specific replication or backup/restore plan.
4. Change the intended DNS records
Update only the public website’s origin records. Preserve unrelated portal and mail records. Check both A and AAAA so IPv6 visitors do not continue reaching the old origin. Lowering a TTL helps only after previously cached records expire. For proxied CDN records, public DNS usually shows CDN addresses; validate origin routing in the CDN configuration and server logs.
5. Validate the production hostname
Check DNS Health & DNSSEC, HTTP Status, SSL Certificate, redirects and the application’s essential flows. Test both IP versions from the networks you can access. A DNS-provider change may require a coordinated DS update at the registrar. Do not publish a new AAAA record until that origin’s IPv6 path works.
6. Keep rollback consistent with new writes
Retain the old environment and backups while monitoring the new service. If no destination writes have occurred, a traffic rollback may be straightforward. Once new writes exist, stop and reconcile data before restoring old writers or switching traffic back. DNS rollback alone does not undo data changes and cached answers may keep reaching both environments.
Worked example
Illustrative cutover checklist Old writers: stopped Final backup: verified and retained New service: ready; one writer A/AAAA or CDN origin configuration: reviewed Production HTTPS and essential flows: tested New writes occurred: yes Rollback: requires data reconciliation, not only a DNS change
What to check next
- Record the current configuration and verify recovery material.
- Validate staging and plan production-hostname checks.
- Stop old writers, transfer final data and verify the destination.
- Change the intended origin records and immediately test production.
- Monitor the new service; do not restart the old writer or repeat the old transfer after new writes.