Change DNS records safely

Before a planned move, inventory the current records and lower the relevant TTL. Do this early enough for the old TTL to expire.

Lowering a TTL does not remove answers already cached with the old, longer TTL. If the current TTL is 24 hours, lower it at least 24 hours before the move. Record the original value so you can restore it later.

Prepare the new service before changing DNS. For a website, verify its application, certificate, redirects, and data independently of public DNS. You can direct one HTTPS request to the new address while retaining the real hostname:

curl --resolve www.example.com:443:203.0.113.40 \
  https://www.example.com/

This tests the new endpoint with the correct TLS and HTTP hostname. It does not test the future public DNS answer.

Use a written change plan:

1. Export or record the current A, AAAA, CNAME, MX, and important TXT records.
2. Define the expected new answer and a rollback condition.
3. Lower the relevant TTL early and wait out the old TTL.
4. Test the new service.
5. Change the authoritative record.
6. Query authority directly, then compare several recursive resolvers.
7. Keep the old service working until old positive and negative caches have expired.
8. Restore a normal TTL after the result is stable.

Changing nameservers is a larger operation than changing one address record. Parent delegation caches are involved, and DNSSEC-enabled domains must coordinate DS data carefully. A stale DS record pointing at a newly unsigned or differently signed zone can cause validating resolvers to return SERVFAIL.

Do not judge completion only from your laptop. Its operating system, browser, router, and resolver may each cache data.

Your action is to write a reversible runbook for moving one test hostname. Include the old TTL deadline, preflight request, authority query, two resolver queries, rollback trigger, and time to retire the old endpoint.