Restoring DNS TTL After a Successful Cutover

Problem Statement

You lowered TTL to a short value before the move so resolvers would pick up the new origin quickly and a rollback could take effect in minutes. Now the cutover is stable, but leaving TTL at 60–300 seconds permanently multiplies query volume against your authoritative servers, raises resolution latency, and adds an availability risk if those servers ever blip. This page, part of TTL Optimization Strategies, covers when and how to raise TTL back to its normal operating value and how to verify the restoration took effect.

TTL value timeline across a cutover TTL is high before migration, lowered ahead of cutover, held low during the soak window, then raised back to normal once stable. TTL Across the Cutover Timeline Normal TTL Low TTL Restored TTL before window cutover + soak stable fast rollback possible
TTL drops ahead of cutover for agility, then returns to its normal value once the migration is confirmed stable.

When to Use This Approach

  • The new origin has served production traffic cleanly through at least one full business-traffic cycle.
  • Error rates, latency, and conversion metrics are back to or better than the pre-migration baseline.
  • You no longer expect to invoke a DNS-level rollback, and any rollback would now follow your Migration Rollback Playbooks at a deliberate pace rather than an emergency one.
  • DNS query volume or authoritative server load has risen noticeably because of the short TTL.
  • It has been long enough since cutover that no further per-second agility is required.

Step-by-Step Instructions

1. Confirm Stability Before Raising Anything

Raising TTL trades rollback agility for efficiency, so only do it once you are confident you will not need a fast revert. Check that the new origin has been clean for a defined soak window — typically 48 to 72 hours of normal traffic — before touching the records.

# Confirm the live record still resolves to the NEW origin everywhere
for r in 8.8.8.8 1.1.1.1 9.9.9.9; do
  echo -n "$r -> "; dig @$r example.com A +short
done

2. Decide the Target TTL Value

Pick a TTL that balances cache efficiency against future change agility. Common choices are 3600 seconds (1 hour) for records you may revisit and 86400 seconds (24 hours) for genuinely static records. Avoid jumping straight to a multi-day TTL on records you might need to edit again soon.

# Typical restored TTL targets
A / AAAA (active origin)      3600   # 1h — easy to revisit
CNAME (CDN / stable target)   3600   # 1h
MX / NS (rarely change)       86400  # 24h

3. Raise TTL via the AWS CLI (Route 53)

For Route 53, an UPSERT change with the new TTL republishes the record. The TTL field is what resolvers will honour going forward; the record value stays the same.

# Republish the A record with a restored 3600s TTL
aws route53 change-resource-record-sets \
  --hosted-zone-id Z123EXAMPLE \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "A",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "203.0.113.10"}]
      }
    }]
  }'

4. Raise TTL via the Cloudflare API

On Cloudflare, patch the existing record and set ttl to the target in seconds. Note that ttl: 1 means “automatic” on Cloudflare; use an explicit value like 3600 to pin a concrete TTL.

# PATCH the DNS record to a 3600s TTL (auth header omitted for brevity)
curl -X PATCH \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"type":"A","name":"example.com","content":"203.0.113.10","ttl":3600}'

5. Apply the Change Across All Migrated Records

Do not raise TTL on only the apex record. Sweep every record you lowered before the move — A, AAAA, CNAME, and any subdomains in scope — so the whole zone returns to its normal cache behaviour consistently.

# Audit which records still carry a short TTL
dig @ns1.example-dns.net example.com A +noall +answer
dig @ns1.example-dns.net www.example.com CNAME +noall +answer
dig @ns1.example-dns.net example.com AAAA +noall +answer

The choice of target value is a trade, and it helps to see both sides plotted rather than argued. A short TTL buys agility and costs query load plus a sharper dependency on your nameservers being reachable; a long one does the reverse. Steady state should sit where the agility you actually need is cheapest.

Rollback agility against authoritative query load for four TTL values Four candidate TTL values plotted against how quickly a change takes effect and how much authoritative query load they generate, with 3600 seconds marked as the usual steady-state choice and 300 seconds as the migration-window choice. Pick the cheapest TTL that still gives the agility you need 60 s cutover hour only 300 s migration window 3600 s usual steady state 86400 s static records only high low query load fast rollback slow rollback Nothing sits in the bottom-left corner — that is the whole reason TTL is a scheduled decision rather than a setting.
The two costs move in opposite directions, so "correct" depends entirely on whether you are currently expecting to change the record.

Worked Example

Before the move, example.com A record carried a 3600s TTL. The day before cutover it was lowered to 300s for agility (the procedure in How to Lower DNS TTL Before Migration).

Cutover happened on Monday. By Thursday, after roughly 72 hours of clean traffic, the record still reads the short TTL:

# Authoritative before restoration — still 300s
$ dig @ns1.example-dns.net example.com A +noall +answer
example.com.   300   IN   A   203.0.113.10

The team runs the Route 53 UPSERT from step 3 to set TTL back to 3600. Authoritative immediately reflects the new TTL:

# Authoritative after restoration — back to 3600s
$ dig @ns1.example-dns.net example.com A +noall +answer
example.com.   3600   IN   A   203.0.113.10

Recursive resolvers will keep honouring the old 300s cache window until their current entries expire, then they will cache the next answer for the full hour. Query value is unchanged throughout, so there is zero user-facing impact.

That last paragraph hides the detail people most often trip over when they check their own work. Raising a TTL is not retroactive, and the authoritative answer changes instantly while the resolver population does not. For a period equal to the old short value, resolvers keep serving from caches created under the previous policy, so a spot check against a public resolver immediately after the change will still report 300 s and look like a failure.

Why a raised TTL does not appear at resolvers immediately The authoritative server reports the new 3600 second TTL the instant it is published, while a recursive resolver continues serving its existing 300 second cache entry until that entry expires and only then adopts the longer value. Publishing is instant; adoption is one old TTL away Authoritative Recursive resolver 300 s 3600 s — published, effective immediately here still serving its 300 s entry refreshes, now caches for 3600 s you run the UPSERT here Check the authoritative nameserver to confirm the change landed; check a public resolver only after the old window has lapsed. Both are correct at the same time — they are answering different questions.
The gap between the two lanes is the old TTL, which is why the verification below queries the authoritative server first and a public resolver second.

Verification

# Authoritative must report the restored TTL
dig @ns1.example-dns.net example.com A +noall +answer | awk '{print $2}'
# Expect: 3600

# After existing recursive caches expire, public resolvers report the higher TTL too
dig @8.8.8.8 example.com A +noall +answer

The restoration is confirmed once the authoritative answer shows the target TTL and, after the previous short-TTL caches lapse, public resolvers begin returning answers with the higher TTL while still pointing at the correct new origin.

FAQ

How long should I wait after cutover before raising TTL? Wait until the new origin has handled at least one full peak-traffic cycle cleanly — commonly 48 to 72 hours — and your error-rate, latency, and conversion metrics match or beat the pre-migration baseline. Raising TTL earlier removes the fast DNS rollback path before you have proven you will not need it.

Does raising TTL break anything for users mid-flight? No. The record value stays identical, so resolvers continue returning the same correct IP; only the cache duration changes. Resolvers honour their existing cached entry until it expires, then cache the next answer for the new, longer TTL with no interruption.

Should I keep TTL low permanently for easier future changes? Generally no. A permanently low TTL multiplies query load on your authoritative servers and makes those servers a sharper single point of failure. Restore to a normal value such as 3600s and simply lower it again ahead of any planned future change. The single-point-of-failure argument is the stronger of the two: with a one-hour TTL, a resolver holding your record can keep answering correctly through a complete authoritative outage lasting most of an hour, and your users never notice. At 60 seconds that buffer is gone, and your site’s availability becomes directly coupled to your DNS provider’s.

What is a reasonable soak period if traffic is highly seasonal? Measure the soak in traffic patterns rather than hours. The point of waiting is to have seen the new origin handle every kind of load it will meet, so a site whose difficult hour is Monday morning has not really been tested by a quiet weekend. Wait for at least one instance of your genuine peak, plus any scheduled batch job — nightly imports, reporting runs, invoice generation — that has not yet executed against the new infrastructure. For most sites that is 48 to 72 hours; for a business with a monthly cycle it may sensibly be longer.

Should the restoration be one change or a staged climb? One change is fine going up, unlike coming down. The staircase on the way down exists because each reduction only becomes effective after the previous, longer value expires — an ordering constraint that does not bite in reverse. Going from 300 s straight to 3600 s takes full effect within 300 seconds, so there is nothing to stage. The only reason to climb gradually is if you are not yet certain you are finished with the record, in which case an intermediate 900 s is a reasonable hedge.

Who should own the restoration, and how does it not get forgotten? Give it a named owner and a scheduled date at the time you lower the TTL, not afterwards. Restoration is the classic orphaned migration task: it is not urgent, nothing breaks when it is skipped, and the people who lowered the value have by then moved on to closing out the migration. The result is a zone left permanently at 60 seconds, quietly paying query costs and carrying an availability risk nobody chose. Create the ticket during the pre-flight phase, dated for the end of the soak window, and treat the migration as incomplete until it is closed.

Related

← Back to TTL Optimization Strategies