Don't like ads? Go Ad-Free Today 

DNS Record TTL Expiry Calculator

DeveloperMathNetworking

ADVERTISEMENT · REMOVE?

INPUT

Auto Process

OUTPUT

Client Side

ADVERTISEMENT · REMOVE?

Guide

DNS Record TTL Expiry Calculator

Plan DNS changes with confidence. Paste the records you just queried, set the moment they were fetched, and this calculator pinpoints the exact second every cached copy expires across resolvers — plus the safer “all-zones clear” propagation window for your migration.

How to Use

Paste one record per line in the DNS Records box. Format: TYPE TTL [name] — for example A 3600 example.com.
Set Fetched At to when those values were last queried (leave blank to use the current time).
Optionally enable the recommended TTL reduction schedule for a step-by-step migration plan.
Watch the live countdown in the results table to know precisely when each cached record expires.

Features

Multi-record batch input — calculate expiry for A, AAAA, MX, CNAME, TXT, NS, SOA, SRV, CAA and more in a single pass.
Live countdown — every row ticks down to the second, so you know when a resolver will refresh.
Exact expiry datetime — converts TTL seconds into a precise wall-clock timestamp based on the fetch time you choose.
Safe propagation window — surfaces TTL × 2 alongside each record, the conservative wait before assuming global cache clearance.
Migration TTL schedule — opt-in plan that steps you from the current TTL down to 300s before the change and back up after.
Forgiving input parser — accepts spaces, tabs, or commas as separators and ignores comment lines starting with # or ;.
Validation hints — flags unknown record types and TTL values that fall outside RFC 2181 bounds.
Human-readable durations — TTL seconds are also rendered as 2h 30m 10s for at-a-glance comparison.

When to Use This Tool

Planning a server, CDN, or email provider switch and need to know when the world will see the new records.
Investigating why an old IP is still being served and want a reliable countdown to the last cache clearing.
Rolling back a DNS change and trying to estimate how long stale entries will keep arriving at the old endpoint.
Building a runbook that tells the on-call engineer exactly when verification is safe to start.

 FAQ

What does TTL actually mean for a DNS record?

TTL (Time To Live) is a counter, in seconds, that a recursive resolver attaches to a cached DNS answer. Once that counter reaches zero, the resolver must discard the cached copy and query the authoritative nameserver again. Shorter TTLs make changes propagate faster but increase query volume and cost; longer TTLs improve cache efficiency at the price of slower convergence.
Why is the safe propagation window suggested as TTL multiplied by two?

In practice, different resolvers fetched the record at different moments, and some intermediaries (including misbehaving clients) hold cached copies slightly past the official TTL. Doubling the TTL is a widely used field heuristic that absorbs both the staggered fetch times and any clock or implementation drift, giving operators a conservative window before assuming a record is cleared everywhere.
Why are extremely large or negative TTL values rejected?

RFC 2181 limits DNS TTL values to a 32-bit unsigned integer, with the top bit reserved, so anything above 2147483647 is non-conformant and treated as zero by many resolvers. Negative or non-integer values have no defined meaning on the wire, so the calculator surfaces these as input errors rather than silently producing misleading expiry times.
What is the rationale for lowering TTL before a planned DNS change?

Caches you cannot see hold copies of the previous record until their TTL expires. By lowering the TTL well in advance — typically at least one full TTL period beforehand — and then waiting for the old long TTL to drain from caches, every resolver eventually starts honoring the new short TTL. After the cutover, raising the TTL back up restores normal cache efficiency and reduces query load on authoritative nameservers.