Why DNS changes 'don't take': separate TTL, propagation, and rollback

EDITORIAL PRACTICE

TTL is the setting that decides how long a change takes to arrive

TTL (Time to Live) is the cache retention time set per DNS record. Cloudflare explains that TTL controls how long each record is cached and — as a result — how long it takes for record updates to reach your end users. A resolver that has answered once will keep answering from cache until the TTL expires instead of asking the authoritative server again. 'Propagation' is simply the world's caches expiring, one by one.

Long TTLs have real benefits: as the same documentation notes, longer TTLs speed up DNS lookups by increasing the chance of cached results — but updates take longer to go into effect. Speed in steady state and agility at change time are a trade-off, and TTL is the dial you set per situation.

Know the ranges. On Cloudflare, DNS-only records accept TTLs from 30 or 60 seconds at the low end, depending on plan, up to 1 day, and Auto means 300 seconds. Arriving at change day without knowing your current TTLs is the first step toward trouble.

TTL is per-record. Within one domain, the A record, the MX record, and each subdomain can carry different TTLs. Identify exactly the records being migrated and check those TTLs; a blanket 'we shortened the TTL' almost guarantees one target record was left out.

A TTL change itself also propagates on the old TTL's schedule. Shortening a TTL only starts working after caches holding the old, longer TTL expire. With a current TTL of one day, the short-TTL regime begins a day after you set it — the whole change plan must be counted backwards from that wait.

A classic trap is the internal network being the last place still returning the old value. If the corporate DNS has its own caching or forwarding setup, the outside world finishes propagating while the office alone keeps reaching the old destination. Including the internal resolver among the verification points is what finds that 'only we are stuck' state early.

Note also that cache retention is not governed solely by the authoritative settings: some resolvers and devices handle TTL with quirks of their own. Treat TTL as a strong guideline rather than an absolute guarantee, and for important changes design the schedule and the communications around the slowest realistic case.

Sources: [1]

EDITORIAL PRACTICE

Start days before: shorten TTLs and inventory the records

DNS change work starts days before anyone presses the button. Stage one is the record inventory: every record tied to the system being migrated, with current values, TTL, proxy status, and dependencies on certificates and mail authentication. The inventory table becomes the day-of procedure and the rollback procedure at once.

Stage two is pre-shortening: lower the target records' TTL to a short value such as 300 seconds, timed so the old TTL's caches have expired by change day. Propagation on the day then completes within minutes. Skipping pre-shortening means the day's propagation carries the full old TTL.

Some records cannot be shortened. For proxied records, Cloudflare documents that TTL is Auto at 300 seconds and cannot be edited. Proxied records propagate fast but offer no TTL design freedom; which treatment a target record has changes how the day runs.

Inventory the non-DNS dependencies too: systems with hard-coded destination IPs, certificate issuance that depends on DNS validation, SPF records still referencing the old destination. DNS change failures often present as a broken assumption outside DNS itself, which is why dependency discovery belongs in the pre-change stages.

Communicate the window to stakeholders in advance. During propagation, some users reach the new destination and some the old, so both systems must be live, with data synchronization and write-destination handling decided beforehand. A DNS change looks like network work but is part of the whole system's migration.

Fold pre-shortening into the change approval flow. State the shortening date and the earliest feasible change date in the plan and get them approved; if the reason for the wait is not explainable, the schedule gets compressed and the unshortened change recurs. Keeping the mechanism explanation as boilerplate in the plan template removes the need to persuade every time.

Record in the inventory, too, where each record is managed and who holds change permission for it. Whether a change can happen at all is often decided by where the permission sits, and discovering on the day that nobody present can touch a record is a pre-technical failure to eliminate early.

Sources: [1]

EDITORIAL PRACTICE

On the day: change in stages, verifying as you go

Make the day's changes in small slices: change one record, verify propagation and behavior, then proceed. Changing everything at once is faster, but when something breaks you cannot identify which change caused it. Staging is not about slowness; it is about preserving isolatability.

Order the slices from low impact to high. Rehearse the procedure on a test subdomain or a low-traffic path before touching the main records — including verifying that the verification method and the rollback method actually work, not just the change method. The production run should never be the first execution of the rollback path.

During propagation, traffic legitimately arrives at both old and new destinations. Watch that data handling behaves as designed in that window: no split writes, no unexpected access in the old side's logs. Propagation time is not waiting time; it is dual-running monitoring time.

Fix the completion criteria in advance: at which checkpoints must the new value be returned, and how far must old-destination traffic decay, before you call it done. Without criteria, the completion call depends on the operator's feel, and the old system gets stopped too early. Stopping the old system is its own stage, separate from propagation completing.

Log as you work: change times, values changed, verification results. That log becomes the incident timeline if anything goes wrong and the evidence for the rollback decision. Making the working memo the formal record is what removes person-dependence from DNS changes.

Short observation windows between stages also help. They exist to watch propagation progress and business-log anomalies, with lengths set by TTL and business criticality and written into the procedure as numbers. Back-to-back changes without observation make it hard to pair a symptom's start time with its cause.

Include the day's communication structure in the procedure. Execution, propagation verification, and business-path checks are often held by different people; decide who verifies what, where results converge, and at what points the decision-maker is briefed. Half of DNS-change confusion comes not from technology but from scattered communication.

Sources: [1]

EDITORIAL PRACTICE

Verify propagation by place and by resolver

Judging 'has it propagated' from your own machine on your own network is the classic trap. Caches are independent per resolver, so one resolver returning the new value while another still returns the old is a normal state. Verification separates several public resolvers from the internal corporate resolver.

Work in two layers: first query the authoritative servers directly to confirm the correct value is published, then observe each resolver's cache state. Without that separation, configuration errors and cache residue get conflated. If the authoritative answer is right and stale answers are within their TTL, that is not an incident; it is propagation in progress.

Pre-decide how user reports are handled. 'I still see the old page' is evidence about that user's resolver cache, not about your configuration. Give support a triage procedure: how to check the resolver, and the expected wait for the record's TTL.

Verification includes the real business path. Correct name resolution does not guarantee the destination accepts the traffic: certificates, firewalls, and application allowlists can still reject it. DNS completion and business-path completion are different checks, and the latter is judged together with the business owner.

Record results with timestamps: which resolver began returning the new value, and when. That record becomes the evidence base for TTL design and wait times in the next change; accumulated numbers are what make change plans realistic.

Standardize the verification toolkit: queries against the major public resolvers, a direct authoritative check, and a real business-path check, documented as one set. A standardized set reduces operator variance and makes recorded results comparable across changes.

User reports can themselves serve as propagation telemetry: their volume and their skew by region or access line hint at which resolvers still hold cache, and watching the count decay over time is a measured view of propagation progress.

Sources: [1]

EDITORIAL PRACTICE

Proxied records are a different problem from TTL

Behind a CDN or reverse proxy, the DNS-visible address and the actual destination are deliberately separated. Cloudflare documents that proxied records have a TTL of Auto, set to 300 seconds, which cannot be edited — a design that lets assigned anycast addresses change quickly. Propagation is fast under proxy, but control over the destination moves into the proxy's own configuration.

In such setups, the change is often not 'edit the DNS record' but 'edit where the proxy points'. Procedures must state explicitly whether the change object is the DNS value or the proxy's origin setting; confusing the two produces the classic 'we changed it and nothing happened' on the day.

Troubleshooting layers change too. Through a proxy, users see the proxy's addresses, and isolation proceeds DNS, then proxy, then origin. The 'DNS change problem' that turns out to be an origin certificate problem is born from collapsing those layers.

Mail records sit outside proxying: MX and authentication TXT records do name resolution as their job and are treated differently from web proxying. Never assume a whole domain is 'proxied'; confirm the treatment per record. That is why the inventory carries a proxy column.

Proxying also changes who you call. When the DNS provider, proxy provider, and server operator are different parties, the isolation result decides the contact. Confirm each layer's owner and contact route at planning time, not during the incident.

Under a proxy, remember the extra cache layers: browser and CDN caches can keep showing old content after name resolution is already correct. DNS propagation and content caching are different phenomena, and the report-triage procedure should check them in order.

Sources: [1]

EDITORIAL PRACTICE

Rollback is not an undo; it is another change

The key premise of rollback design is that reverting also takes propagation time. After a revert, resolvers that cached the new value keep returning it for its TTL. 'We rolled back but it isn't fixed' is usually not a failed rollback; it is the same cache mechanics applying in both directions.

Decide rollback early. The further propagation has spread users across old and new, the larger the dispersion a rollback creates. Set a time limit for watchful waiting in advance; when symptoms persist beyond it, execute the rollback. Decision delay translates one-to-one into a longer confusion window.

Prepare the rollback procedure as a pair with the change procedure: values to restore, order, verification after restore, and the conditions under which you would change again. It presumes the old values are recorded in the inventory table; a procedure that relies on remembering old values on the day is not a procedure.

Include the data dimension. What happens to data written at the new destination? If rollback splits the data, the merge method must be decided too, or you can return at the network layer but not at the business layer. In many cases the data state, not DNS, decides whether rollback is even possible.

When you do roll back, record the cause: configuration error, missed dependency, or propagation mis-estimate. Rollback is not concealment of failure; it is input to the next change plan. An unrecorded rollback teaches nothing and repeats itself.

Rehearse rollback once as well. Run a change and a rollback end to end on a small subdomain and surface procedure stalls and verification gaps. A DNS rollback has too wide a blast radius to be first attempted under production pressure; the rehearsal log doubles as revision material for the procedure.

After a rollback, organize the conditions for the next attempt within the same case: is the cause resolved, and how will TTL handling and staging change next time. Including the redesign for the retry in the case's completion criteria keeps a single failure from ending the migration.

Sources: [1]

EDITORIAL PRACTICE

Leave the change in a ledger and make the next change easier

Keep change history per domain and record: before and after values, TTL, date and time, purpose, operator, verification results, and whether a rollback occurred. With that history, 'why does this record have this value' is answerable years later. Infrequently touched systems are exactly the ones that become untouchable without recorded intent.

Add periodic inventory: unused subdomains, records still pointing at retired systems, records with no owner. Stale records are migration hazards and, as abandoned destinations, security problems as well. Run both per-change and annual inventories.

Revisit steady-state TTL design from the change history: records that change often get shorter TTLs, stable core records longer ones. There is no need for one uniform value; change frequency is the evidence base for the allocation.

Include adjacent areas in the ledger: certificate renewal methods that rely on DNS validation, and the SPF and DKIM record set. These are the areas most often hit by DNS changes, and putting them on the change checklist prevents secondary incidents.

DNS is unglamorous, but it is the entrance to every connection. Turning its changes into a typed procedure — pre-shortening, staged execution, layered verification, prepared rollback, written history — removes most migration-day chaos, and the type outlives the operator who wrote it.

Store the ledger together with the change request and approval records. Values alone do not preserve 'why it was changed'; pairing the request's purpose and approver with the value history makes both audit response and handover to a future operator completable from the one ledger.

Finally, rehearse the pattern on a small change first. Running the full sequence — inventory to records — on a low-impact record removes procedural anxiety when the real migration comes. The pattern's value lies in having been validated on a small change before the large one.

Sources: [1]