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

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.

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.

Related

← Back to TTL Optimization Strategies