Plan a DNS change with authoritative checks, TTLs and a rollback record

A DNS change is a distributed configuration change. The control panel where you edit a record may not host the authoritative zone, and recursive resolvers can continue returning an earlier answer until its cache expires. A written plan makes the intended change, dependencies and recovery path visible before customers are affected.

Identify the zone that actually answers for the domain

dig example.com NS +short
dig example.com SOA +noall +answer
dig example.com A +noall +answer
dig example.com AAAA +noall +answer
dig example.com MX +noall +answer
dig example.com TXT +noall +answer

Record the nameservers delegated at the registrar and the DNS provider responsible for them. A local hosting panel can contain a complete-looking zone that nobody on the public internet uses. For a delegated subdomain, inspect that subdomain separately rather than assuming the parent zone owns every record.

Save the exact old values, including priorities, TTLs, record types and trailing names where your DNS interface requires them. Export the zone if supported. Keep the change record private when it contains internal service details, but remember that ordinary public DNS records are publicly queryable.

Separate the website change from mail and delegation changes

• A and AAAA records direct IPv4 and IPv6 web traffic; changing only one can split visitors between servers.
• MX records choose mail exchangers. Do not replace them just because the website moved.
• SPF, DKIM and DMARC TXT records affect sending identity and should be reviewed against the actual mail services.
• NS and DNSSEC changes have wider consequences than a single web record and need a separate migration plan.

An apex CNAME is constrained by DNS rules and provider-specific alias features. Use the record type supported by the authoritative provider, and do not create a CNAME at a name that must also contain ordinary MX or TXT records. Check the provider documentation before copying a record pattern from another zone.

Prepare the new destination before changing DNS

curl --resolve example.com:443:192.0.2.40 \
  --silent --show-error --fail --dump-header - \
  --output /dev/null https://example.com/

The resolve override changes the destination for this request while retaining the URL hostname for HTTP and TLS verification. The new server needs the correct virtual host, application configuration and a trusted certificate for that hostname. A certificate error is useful evidence to fix; disabling verification would conceal it.

Test login, forms, uploads and application dependencies as well as a static page. Check the www hostname separately if it is supported. For a private origin normally reached through a CDN, use the documented origin validation method rather than making the origin publicly accessible merely for a test.

Lower TTL early enough to be useful

If the existing TTL is 86400 seconds, lowering it five minutes before a cutover does not evict copies already cached for a day. Publish a lower TTL at least one full previous TTL before the planned change where possible. A 300-second TTL can make a controlled cutover easier, but the appropriate value depends on the provider and the service.

dig @ns1.example.net example.com A +noall +answer
dig @ns1.example.net example.com AAAA +noall +answer
dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer

Replace ns1.example.net with a nameserver obtained from the actual delegation. Public resolver checks are samples, not proof that every client has refreshed. Negative answers can also be cached, so creating a record that previously did not exist has different cache behavior from changing an existing answer.

Apply a small change and observe both destinations

Make only the reviewed changes and query every authoritative nameserver. Confirm the returned address, TTL and record type, then compare a few independent recursive resolvers. Watch HTTP errors, certificate failures and application activity on both old and new hosts during the transition.

For a database-backed site, keep the write strategy explicit. If two servers accept independent orders or edits while DNS caches differ, DNS alone cannot reconcile their databases. Use a maintenance window, a shared backend or an application-supported replication and cutover procedure.

Define rollback and finish the record

Rollback usually means restoring the recorded values at the authoritative service. That is another DNS change and is subject to caching; it is not an immediate global reversal. Keep the old service and certificate working through the observation window, and decide how any writes on the new service will be reconciled before reverting.

After the migration is stable, return TTLs to the intended operational values, remove temporary overrides and record the final answers. Treat an unexpected AAAA record, forgotten CDN rule or stale mail route as a dependency to investigate rather than repeatedly changing unrelated records.

Primary documentation

• cPanel Zone Editor
• BIND dig command reference
• curl command-line reference