DNS TTL Checker — Time to Live for All Records

When you change an A record during a datacenter move, resolvers worldwide continue serving the old IP until their cached entry expires. TTL is the maximum seconds they may cache. A TTL of 86400 means some clients need up to 24 hours to pick up your new address without manual cache flush.

Operations teams temporarily lower TTL days before a change, wait for old caches to expire, execute the change, verify, then raise TTL again for stability. This tool documents starting TTL so that playbook has real numbers.

It is normal for NS records to carry long TTL while CDN CNAMEs use short TTL for rapid failover. MX TTL affects mail routing updates. TXT for verification tokens sometimes uses short TTL during setup then increases later.

Our snapshot lists all types returned by the aggregator — not a single zone file view. External DNS hosts may apply different defaults per type even when you set a global default in their UI.

Authoritative servers publish TTL in each RRset. Some resolvers cap TTL or apply minimums. What you see here reflects the resolver path used by our service at query time, which matches what most public clients experience.

Private corporate resolvers may enforce higher minimum TTL, slowing internal propagation relative to the public Internet.

If critical A records show 43200 seconds, schedule at least 12 hours between TTL lowering and the cutover event. Add buffer for anycast and regional variance. Document queriedAt timestamps in change tickets.

After successful migration, avoid immediately jumping TTL to extremely high values until you confirm stability — gradual increases reduce rollback pain.

MX and TXT records for SPF and DKIM carry their own TTL. Lower them before mail provider switches alongside web A records. Mail queues retry across TTL windows — misjudging TTL extends dual-delivery or bounce periods.

Pair TTL review with our email deliverability checker when planning mail infrastructure moves.

CNAME at the edge often uses low TTL while upstream targets change dynamically. Reading TTL on each hop clarifies which layer drives propagation delay.

Some providers flatten CNAME to A at the edge — TTL on visible A records may differ from underlying CNAME TTL at the authoritative host.

During DDoS or compromise, teams swap DNS to scrubbing centers or clean IPs. Knowing current TTL estimates how fast traffic shifts globally. Emergency TTL lowering at the provider still waits for previous TTL to expire once.

Keep a pre-documented TTL snapshot for production domains to avoid guessing during outages.

TTL values can change if your DNS admin edits them between checks. queriedAt anchors each snapshot in time for audit trails.

Re-run after edits to confirm the provider applied new TTL. Propagation of TTL changes themselves follows the previous TTL until caches refresh.

It does not edit DNS, recommend optimal TTL universally, or predict exact per-resolver cache state. It lists advertised TTL on returned records only.

Historical TTL trends require external monitoring — see our DNS record history tool for snapshot guidance with change-tracking notes.