TTL Inspector
Look up the time-to-live for any DNS record type to see how long resolvers will cache the result.
| # | TTL | Equivalent |
|---|
About the TTL Inspector
TTL, or time to live, controls how long DNS resolvers are allowed to cache a record before checking for an updated value. Getting TTL right is a balancing act, too long and changes take ages to propagate, too short and you create unnecessary load on your name servers from constant repeat queries. This tool shows you the TTL set on every record type for a domain at a glance, helping you spot values that are inconsistent or worth reconsidering before you next make a change.
How it works
DNSbyte queries a domain's main record types and reports the TTL returned for each one, displayed in both seconds and a more readable format such as minutes or hours. Comparing TTLs across record types on the same domain often reveals inconsistencies, for example a very low TTL on the A record but a very high TTL left over on an old, unused TXT record.
There is no universally correct TTL, the right value depends on how often a record is likely to change and how much tolerance you have for delayed propagation if it does.
Frequently asked questions
What TTL should I use for a record I rarely change?
For stable records that change infrequently, such as MX records, a longer TTL of several hours up to a day is generally fine and reduces unnecessary query load on your name servers. There is little benefit to a short TTL on something you do not expect to touch.
Should I lower my TTL before making a planned change?
Yes, this is a common and effective practice, lower the TTL on the record you plan to change a day or so in advance, wait for the old, longer TTL to fully expire everywhere, then make your change. Resolvers will then pick up the new value much faster because they are only caching it for the new, shorter period.
Is there a minimum or maximum TTL I can set?
Most DNS providers allow TTLs from as low as a few seconds up to many days, though some impose a practical minimum to prevent abuse. Extremely low TTLs under 60 seconds are rarely necessary outside of active migrations.
Why do NS records typically have a much longer TTL than other records?
Name server records change very rarely and are queried extremely frequently by resolvers worldwide, so a long TTL, often 24 to 48 hours or more, significantly reduces global query load without meaningfully affecting how the domain functions day to day.
My TTL says 3600, what does that mean in practical terms?
3600 seconds equals one hour, meaning a resolver that has cached this record will not check for an updated value again until that hour has passed, even if the record changes in the meantime.