DNS records and TTLs: prepare a change you can verify

Identify the authoritative zone and the people who control it

Separate the domain registrar, authoritative DNS provider and hosting destination in your notes. They may be operated through different accounts. The registrar controls domain registration and delegation, while the authoritative DNS service publishes the zone records that resolvers query. Moving a website to a new host does not necessarily require changing either the registrar or the nameservers.

Find the active authoritative nameservers and export or privately record the current zone before editing it. Include exact names, types, values and TTLs, not only a screenshot of the main website record. Confirm who can approve and restore a change. A DNS dashboard in an old account is not evidence that its records are still authoritative for the domain.

Treat a nameserver migration as a separate change with its own validation. It can affect the entire zone, including email and verification records. When only the web destination is changing, keeping the existing DNS authority and editing the relevant address or alias record often makes the scope easier to review.

Know what each record contributes

For example, example.com may have an A record and www.example.com may alias it through a CNAME. Review both user-facing names. An address change for the first can affect the alias, while an unrelated hostname may still point directly at the old server. Zone-apex alias features vary by DNS provider; follow its documented mechanism rather than assuming every interface accepts an ordinary apex CNAME.

Do not leave an old AAAA record behind when the IPv4 destination moves. Some clients may continue reaching the obsolete IPv6 service while others use the new IPv4 address. Confirm the intended IPv6 availability before publishing that path. Likewise, a website move is not a reason to replace MX or TXT records when the mail service is staying where it is.

Plan for answers already in caches

TTL gives a DNS answer a cache lifetime. Reducing it on the authoritative record does not shorten an older answer already cached elsewhere. If the existing value is 86,400 seconds and you want a 300-second value for a planned switch, lower it sufficiently in advance for the previous lifetime to pass. Those values illustrate planning; the options available depend on the DNS service and record.

DNS can also cache an answer saying a name does not exist or has no requested record. That negative cache is governed by DNS rules and zone information, rather than the TTL of a record you add afterwards. Avoid discovering this during a launch by testing the new hostname only after it has deliberately been published and allowed for in the plan.

A TTL is not a countdown to a simultaneous worldwide switch. Clients, recursive resolvers and existing application connections do not all refresh together. Keep the previous endpoint controlled through the overlap. If the application accepts writes, the migration plan must define a single data authority while traffic can still arrive at more than one address.

Verify the DNS answer, then the service behind it

• Record the previous value and the exact intended replacement.
• Query each authoritative nameserver for the affected name and record type.
• Compare responses from more than one recursive resolver and note remaining TTLs.
• Check every public hostname and both IP families that are actually published.
• Test HTTPS and representative application behaviour using the real hostname.
• Observe residual traffic before raising the TTL or retiring the old endpoint.

Differentiate an authoritative mistake from a cached old response. If the authoritative servers disagree, investigate the zone publication or delegation. If authority is correct but one resolver still has an older answer, compare its remaining lifetime before making another unrelated edit. Repeatedly changing values can make the observation window harder to interpret.

A correct address answer does not prove a valid certificate or working virtual host. HTTPS uses the requested hostname, and the application must recognise it. If a proxy or CDN is part of the design, understand which returned address represents that intermediary and which origin setting controls its backend. Keep the DNS result and origin-service test as separate checks.

Protect DNSSEC validation and keep rollback realistic

If DNSSEC is enabled, a nameserver or signing-provider migration must account for the parent DS record and the new signing keys. A mismatch can cause validating resolvers to reject answers. Follow the documented migration procedure for both providers and the registrar, including applicable cache lifetimes. Do not delete trust records or disable validation as an improvised first response to an unexplained web error.

Keep the previous DNS values with the change record, but remember what they can reverse. Restoring an old address changes where future resolutions lead; it does not copy back customer data accepted by the new application. Use the separate migration plan to decide when traffic rollback is safe and when data reconciliation is required. Finish only after the application, mail dependencies and recovery copies have been checked.