Verify DNS TTL Before a Migration

Inspect TTLs across authoritative and public resolvers, lower them ahead of a cutover, and confirm propagation before switching traffic.

~20 mindnsmigrationoperations

Task

Avoid a stale DNS answer delaying a planned failover long after the switch is supposed to be complete.

When to use this

A team moves an API to a new load balancer and updates the A record. The old record had a one-hour TTL, and some clients keep hitting the decommissioned address for almost an hour, producing intermittent connection errors.

Prerequisites

dig or a DNS lookup tool
Access to the DNS provider API or control panel
Knowledge of the planned cutover time

Steps

1. Record the current TTL from the authoritative server and from public resolvers.

dig +noall +answer api.example.com A
dig @1.1.1.1 +noall +answer api.example.com A
dig @8.8.8.8 +noall +answer api.example.com A

Expected output: All answers show the same address and TTL, for example 300, confirming there is no split-horizon difference.

2. Lower the TTL to 60 seconds at least two old TTL periods before the cutover.

curl -s -X PATCH \
  "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/dns_records/$RECORD_ID" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"ttl":60}'

Expected output: The record returns ttl 60 in the API response and the zone edit is logged.

3. Wait for the old TTL to expire, then confirm all resolvers return the shorter TTL.

for resolver in 1.1.1.1 8.8.8.8; do dig @$resolver +noall +answer api.example.com A; done

Expected output: Every resolver reports a TTL of 60 or less before the change window begins.

4. Switch the record and verify answers converge on the new address.

dig +short api.example.com A && dig @1.1.1.1 +short api.example.com A

Expected output: Both queries return only the new load balancer address within the TTL window.

Troubleshooting

Problem

The provider ignores the requested TTL

Solution

Some providers enforce a minimum, and proxied records often use a fixed TTL; temporarily disable proxying or accept the provider minimum and plan a longer window.

Problem

One resolver still returns the old address after the TTL

Solution

Check for a second authoritative server or a forgotten CNAME; use dig +trace to see which server still serves the old data.

Limitations

You cannot flush third-party resolver caches; only waiting out the TTL guarantees convergence.
A TTL of 0 is not honored by every resolver and should not be used as a shortcut.

TTL is a countdown you control

Every DNS answer carries a time to live. Resolvers may cache it for that many seconds, and clients may cache longer. The practical rule is to lower the TTL before you need flexibility, then wait at least two old TTL periods so caches expire. Changing the record and lowering the TTL in the same step does not help, because resolvers already hold the old value.

Check every view

Query the authoritative nameservers directly and at least two public resolvers. If the authoritative answer differs from the public one, a proxy, a secondary DNS provider, or split-horizon configuration is in play. Also look for CNAME chains: the TTL of the final A record governs, but intermediate CNAMEs can add their own caching.

dig +noall +answer api.example.com A
dig @1.1.1.1 +noall +answer api.example.com A

Execute the cutover

Confirm the short TTL has propagated before the window. During the switch, update the record once and avoid rapid flip-flopping, which can extend the time resolvers hold inconsistent values. Keep the old endpoint running until at least one TTL after the change, then decommission it and watch error rates for stale clients.

Plan for the exception

Some clients ignore TTLs: JVMs cache DNS for the process lifetime, some mobile SDKs resolve at startup, and connection pools keep using the old IP. For those, keep the old address reachable during the migration or add a retry with re-resolution. After the migration, restore a normal TTL and document the actual convergence time observed.