Change a DNS record safely

What it means

Change a DNS record safely by identifying the active authoritative zone, saving the exact RRset and TTL, preparing the destination, applying only the intended difference, and verifying authority, caches and the service separately. Keep a rollback plan before editing. A successful save in a DNS dashboard is not proof that every visitor sees the new answer. Lowering the TTL now does not shorten the remaining lifetime of answers already cached elsewhere. This procedure covers a website A-record change, not a nameserver, DNSSEC or email migration. DNS caching · Record editing

Try it

Simulation — rehearse a change without contacting a DNS provider. The initial authoritative www.example.com. A answer is 192.0.2.10 with TTL 300. At virtual time 100, prepare a change to 192.0.2.20 with TTL 60. Inspect the full diff before applying it, query the two independent resolver caches, verify the endpoint and try Rollback. Reset restores every field, stage, cache, clock, error and result.

This is not a live DNS checker. Only documentation-space IPv4 addresses are accepted, and no credentials or real domain are needed. Without JavaScript, the starting example remains visible: resolver A cached the old answer at time 0, so at time 100 it has 200 seconds remaining; resolver B has no saved answer yet.

Establish the authorized environment

Use the DNS provider account or deployment process you are authorized to manage. Identify the exact fully qualified owner name, class, record type and complete value set. An RRset groups records with the same owner, type and class; editing one visible value without considering the rest can unintentionally remove a required destination. The lab deliberately uses one-value A data to make the boundary inspectable. RRset rules

Confirm which service is authoritative for the relevant zone and whether a subdomain is delegated elsewhere. A similarly named hosted zone in an old account might not be the one used by the live delegation. The lab's wrong-authority preset stops rather than pretending it can diagnose or repair delegation from a dashboard selection.

For read-only DNS inspection, a tool such as ISC's dig can select a server and record type and display response status, flags, answers and TTL. Check the syntax for the version you actually have. Preserve enough output to distinguish an authoritative answer from a recursive one; an address copied without query context is insufficient evidence. The cited manual was observed as BIND 9.20.30. This article does not install tools or supply a write command against a fabricated production zone. dig documentation

Save the original and protect unrelated records

Before editing, securely save the current zone configuration through the provider's supported export or versioning process and separately record the target RRset and TTL. Include a timestamp and the provider/zone identity. A saved file is useful only if you know how the authorized process restores the intended data. Do not paste private operational configuration into this example.

For a website-only A change, explicitly preserve MX, mail-related TXT such as SPF, DKIM and DMARC, CAA, delegation records and unrelated addresses. Also inspect the same web hostname's AAAA record: an unchanged IPv6 destination may still receive traffic. That does not justify deleting it as a shortcut. A needed IPv6 migration belongs in a separately reviewed scope.

The table is a scoped safety rule. Real zone software may update its SOA serial as part of publishing; the synthetic SOA is schematic and does not model that management behavior. An ordinary apex CNAME conflicts with the zone's required data. Provider-specific alias or flattening products are not identical to an ordinary CNAME and are not modeled here. CNAME coexistence

Prepare and verify the destination first

Prepare the new site before directing traffic to it. Verify the intended hostname, HTTPS, representative pages and any application data using the provider's supported staging or hostname-testing method. Keep certificate verification enabled. Merely reaching an IP address does not prove that the correct virtual host and certificate are configured.

Document the previous working destination and a way to restore it. For a stateful application, establish how data writes remain consistent during a transition; changing DNS is not a data-copy mechanism. This article's static synthetic endpoint has no live writes, and the ready/broken selector is a supplied observation, not an actual TLS or application test.

Choose a maintenance or migration window appropriate to the service. If a lower TTL is part of the plan, publish that lower TTL sufficiently in advance of the destination change for the prior cache lifetime to run down under the ordinary model. A provider's own publication interval and resolver cache lifetimes are different things. Do not label one provider's status message a global propagation guarantee. TTL planning · Provider publication

Apply the smallest inspected difference

The rehearsal requires an inspectable plan before Apply. Its diff must change only www.example.com. A and that RRset's TTL. The simulation rejects protected-record presets, unknown authority, an apex CNAME, an empty address and invalid TTL input without partially changing the zone. Acceptable TTL input here is an integer from 0 through 3600 seconds; that is an educational boundary, not the DNS protocol's entire range or a recommendation to use zero.

In a real provider interface, review the equivalent name, type, values, TTL and routing-policy fields before saving. Stop if the preview includes deletions, another owner/type, unplanned nameserver changes or a different zone. Do not use a broad zone replacement to achieve a one-record edit. Apply once, then inspect the observed state rather than repeatedly submitting an operation with an unknown outcome.

Verify three different layers

First verify the authoritative result using the actual authoritative service, checking the intended owner/type and complete answer set. A provider save acknowledgement alone is not that query. Next inspect representative recursive answers, including remaining TTL and the resolver used. Finally verify the website through the intended hostname, retaining HTTPS and testing meaningful routes. Each observation answers a different question.

The model gives an exact arithmetic example, not a worldwide countdown:

Resolver A saved 192.0.2.10 at t=0 with TTL 300.
At t=100 the authority changes to 192.0.2.20 with TTL 60.
A still has 200 seconds remaining; its expiry is t=300.
Resolver B, queried at t=100, saves the new answer until t=160.

At time 160, B needs a fresh answer under the model's ordinary policy; A can still reuse its old entry. At time 300, A also needs a fresh answer. A zero-TTL answer is displayed but is not retained for reuse. Negative answers have their own caching rules, and serve-stale behavior can extend use of old data under defined conditions; neither is reduced to this two-resolver timeline. Negative caching · Serve stale

STOP and rollback

Stop before applying if authorization, authority, destination readiness or the saved original is uncertain. Stop after applying if the authoritative answer differs from the intended plan, an unrelated service breaks or the endpoint fails its verification. Preserve observations and identify the layer rather than changing additional records speculatively.

Rollback restores the exact saved target RRset and its TTL through the authorized process. Then recheck authoritative data and the application. It does not clear remote resolver caches. In the lab, query B after the change and then roll back: B can still show the new address until its own entry expires. The previous address returns at the authority immediately in the model, not simultaneously in every cache.

Keep both destinations in the safe condition required by the plan during this interval. Do not delete the former deployment merely because one resolver has changed. Retain evidence of what was applied and restored. Reset is different: it restarts the educational world, including its caches and clock, which no real DNS rollback can do globally.

In practice

Use a compact change record: authorized owner/type, saved before-state, destination check, intended diff, verification observations and rollback condition. A successful outcome means the scoped authoritative data is correct and the intended service works, with remaining cache differences understood. It does not mean every resolver was measured or every related service was migrated.