DNS Records & Concepts
What is DNS TTL?
DNS TTL, Time To Live, is a value set on each DNS record that specifies how many seconds DNS resolvers should cache that record before discarding it and fetching a fresh copy from the authoritative nameserver. It is the expiry timer attached to every cached DNS response, the clock that determines when a resolver stops serving an old cached value and queries for an updated one.
TTL is measured in seconds. A TTL of 3600 means a resolver caches the record for one hour, 3600 seconds, before the cached copy expires and the resolver must query the authoritative nameserver again. A TTL of 300 means the record is cached for five minutes. A TTL of 86400 means it is cached for 24 hours.
Every DNS record has a TTL, A records, AAAA records, CNAME records, MX records, TXT records, NS records, and all others. Each record’s TTL is set independently, different record types for the same domain can have different TTLs reflecting how frequently each is expected to change.
TTL is one of the most practically important DNS concepts for anyone managing domain redirects and migrations. It is the primary lever for controlling DNS propagation speed, lower TTL values mean changes propagate faster, higher TTL values mean changes propagate more slowly but DNS resolution is more efficient. Understanding when to raise and lower TTL, and by how much, is a core skill in DNS management.
How TTL works
When a resolver queries an authoritative nameserver for a DNS record the nameserver returns the record value along with the TTL. The resolver stores both, the record value and an expiry time calculated from the TTL. The expiry time is the current time plus the TTL duration.
While the cached copy is fresh, before the expiry time, the resolver serves it to any client requesting the same record without querying the authoritative nameserver. This is what makes DNS fast, the vast majority of DNS lookups are served from resolver caches rather than from authoritative nameservers directly.
When the expiry time passes the cached copy is marked as stale. The next request for the record triggers a fresh query to the authoritative nameserver. The nameserver returns the current record value, which may or may not have changed since the last query, along with a new TTL. The resolver caches the fresh copy and the cycle begins again.
The TTL value received by a resolver represents the full caching duration from the perspective of the authoritative nameserver. However the resolver passes along the remaining TTL, not the original TTL, when it serves the cached record to clients. A client that queries a resolver 30 minutes after the resolver cached a 3600-second TTL record receives a response with a TTL of approximately 1800, the remaining time before the resolver’s cache expires. This decremented TTL ensures clients and downstream caches do not cache the record longer than the authoritative nameserver intended.
TTL values and their practical meanings
TTL values exist on a spectrum from very short to very long and each range has practical implications for how DNS records behave.
Very low TTL, 60 to 300 seconds: records with very low TTLs are refreshed frequently, every one to five minutes. This provides near-real-time propagation of DNS changes. After a record update most resolvers receive the new value within minutes. The trade-off is increased query load on authoritative nameservers, every resolver worldwide queries more frequently. Very low TTLs are appropriate during DNS migrations and when rapid failover capability is needed.
Low TTL, 300 to 900 seconds: records refreshed every five to fifteen minutes. Balances reasonably fast propagation with manageable query volume. Appropriate for records that change occasionally and where propagation within fifteen minutes is acceptable. Good as a pre-migration TTL when planning DNS changes.
Standard TTL, 3600 seconds: one hour. The most common default TTL used by DNS providers and the value seen on the majority of DNS records. Propagation of changes completes within one to two hours. Query load on authoritative nameservers is reasonable. Appropriate for most records in stable configurations.
High TTL, 86400 seconds: 24 hours. Records cached for a full day before resolvers recheck. Very low query load on authoritative nameservers. Propagation of changes can take up to 24 hours. Appropriate for highly stable records that change very rarely, NS records, records pointing to stable long-term infrastructure.
Very high TTL, 604800 seconds or more: one week or longer. Extremely low query load. Propagation of changes can take a week or more. Rarely appropriate except for records that essentially never change.
TTL and DNS propagation
TTL is the primary driver of DNS propagation speed. The relationship is direct, lower TTL means faster propagation, higher TTL means slower propagation.
When a DNS record is changed the change takes effect immediately on the authoritative nameserver. But resolvers that have cached the old value continue serving it until their cached copy expires. The maximum time any resolver can serve the old value is the TTL that was set on the record before the change, the TTL value that was attached to the last successful cache refresh.
This is why the TTL that matters for propagation speed is the TTL that was in place before the change was made, not the TTL set on the new record. Changing the TTL to 60 seconds at the same time as changing the record value does not make the change propagate in 60 seconds. Resolvers that cached the old record when it had a 3600-second TTL will serve the old value for up to one hour regardless of what TTL the new record has.
This is also why the correct approach to speeding up propagation is to lower the TTL well in advance of a planned DNS change, not at the moment of the change. The lower TTL must propagate to all resolvers before it takes effect. Only after all resolvers have refreshed their cache with the lower-TTL version does making the actual DNS change produce fast propagation.
The pre-migration TTL reduction strategy
The most important TTL management technique for anyone planning DNS changes, particularly for domain migrations and redirect management setups, is the pre-migration TTL reduction. Executed correctly it reduces the propagation window from hours or days to minutes.
Step 1, identify the current TTL: check the current TTL on the records being changed. Most DNS records default to 3600 or 86400 seconds.
Step 2, lower the TTL well in advance: reduce the TTL to a low value, 300 seconds is a common target, at least 24 to 48 hours before the planned DNS change. The time needed is at least the current TTL duration, if the current TTL is 86400 seconds changing it now means the lower TTL does not reach all resolvers for up to 24 hours.
A safe rule is to lower the TTL at least one full current-TTL duration before the planned change date. If the current TTL is 3600 lower it at least one hour before the change. If the current TTL is 86400 lower it at least 24 hours before, and ideally 48 hours to account for resolvers that may cache longer than the specified TTL.
Step 3, make the DNS change: once the lower TTL has propagated to all resolvers, verified by checking from multiple locations, make the actual DNS record change. With a TTL of 300 in place most resolvers will fetch the updated record within five minutes. Full propagation typically completes within 15 to 30 minutes.
Step 4, monitor and verify: use propagation checking tools to verify the change is reaching resolvers worldwide. Check from multiple geographic locations and multiple resolvers.
Step 5, raise the TTL after stability: once the DNS change is stable and verified raise the TTL back to a normal value, 3600 or higher. A permanently low TTL unnecessarily increases DNS query volume. The low TTL was needed only during the migration window.
TTL values for different record types
Different DNS record types have different change frequencies and different consequences for incorrect values. This informs appropriate TTL values for each.
A records and AAAA records: typically 3600 seconds for stable production servers. Lower, 300, during migrations or when quick failover is needed. Higher, 86400, for very stable infrastructure that never changes.
CNAME records: similar to A records. 3600 seconds is standard. Lower during setup and testing. Higher for stable long-term configurations.
MX records: 3600 to 86400 seconds. Email routing is stable, MX records rarely change and high TTLs reduce query load from mail servers worldwide checking MX records on every email delivery.
TXT records: varies by use. Verification records, 3600 is fine. SPF and DKIM records, 3600 to 86400 since they change infrequently. TXT records used for SSL certificate renewal validation, lower TTL allows faster propagation of updated validation values.
NS records: 86400 or higher. Nameserver assignments change very rarely. High TTLs reflect the stability and reduce unnecessary query load. Note that NS record TTLs at the TLD level are controlled by the TLD registry, not the domain owner.
CAA records: 3600 to 86400. Certificate authority authorisations change infrequently. Standard or high TTLs are appropriate.
SOA record minimum TTL: the negative response TTL. 300 to 3600 seconds. Lower values allow newly created records to become visible quickly to resolvers that cached a negative response. Higher values reduce unnecessary re-queries for non-existent names.
TTL and redirect management
TTL management is central to redirect management in several specific contexts.
Connecting a domain to redirect infrastructure: when connecting a domain to redirect management via CNAME record or A record update the DNS change propagates according to the TTL on the record being changed. Lowering TTL before the connection reduces the window during which some visitors still reach the old server rather than the redirect infrastructure.
Domain migration redirects: a domain migration, redirecting an old domain to a new one, involves DNS changes on both domains. The old domain’s DNS records must be updated to point to the redirect infrastructure. The new domain’s DNS records must be correctly configured to serve the destination content. Both sets of changes have propagation windows governed by their respective TTLs. Coordinating TTL reduction across both domains ensures the migration window is minimised.
Failover and disaster recovery: redirect management can function as a failover mechanism, redirecting traffic from a primary domain to a backup when the primary is unavailable. The TTL on the primary domain’s DNS records determines how quickly failover traffic reaches the redirect infrastructure. A high TTL means visitors continue attempting to reach the unavailable primary server for hours after the failover redirect is configured. A low TTL, maintained continuously for failover-critical records, enables rapid failover.
SSL certificate provisioning: when a redirect management platform provisions SSL certificates via DNS validation it creates or checks specific DNS records. The TTL on these records affects how quickly the certificate authority can verify ownership and issue the certificate. Low TTLs on validation records allow faster provisioning.
TTL in HTTP caching vs DNS TTL
DNS TTL is sometimes confused with HTTP cache-control headers and HTTP caching TTL values, both control how long something is cached before being refreshed but they operate at completely different layers.
DNS TTL: controls how long DNS resolvers cache DNS record values. Measured in seconds. Set on individual DNS records. Governs DNS propagation speed. Affects the network routing layer, which server a browser connects to.
HTTP cache-control TTL: controls how long browsers and CDNs cache HTTP responses, web pages, images, stylesheets, API responses. Set in HTTP response headers, Cache-Control: max-age=3600. Governs how long cached web content is served before the browser requests a fresh copy. Affects the content layer, what content is displayed once a connection is established.
Both are TTL values in the general sense, both specify how long something should be cached, but they are completely separate systems operating at different levels of the internet stack. Lowering DNS TTL to speed up DNS propagation has no effect on HTTP caching. Setting a long HTTP cache-control max-age has no effect on DNS caching.
Checking TTL values
Current TTL values on DNS records can be checked using standard DNS query tools.
dig command: on Linux and macOS:
The response includes the TTL for each record in the answer section, the number in the third column of each record line. The TTL shown in a resolver response is the remaining cache time, decremented from the original TTL. To see the original TTL query the authoritative nameserver directly:
Checking remaining cache time: querying the same record twice from the same resolver shows the TTL decrementing between queries, confirming the resolver is caching correctly and showing how much time remains before the next refresh.
nslookup: on Windows and other platforms nslookup shows TTL values in its output when the debug option is enabled:
Online tools: web-based DNS lookup tools typically display TTL values alongside record values. Checking from multiple locations shows whether different resolvers are caching different TTL values, which can indicate that a recent TTL change has not fully propagated.
Common TTL mistakes
Not lowering TTL before planned DNS changes: the most common and impactful TTL mistake. Making a DNS change with a high TTL already in place means the propagation window is as long as the existing TTL, potentially 24 hours or more. Always lower TTL at least one TTL duration before planned changes.
Lowering TTL too close to the change: lowering TTL one hour before a DNS change when the current TTL is 86400 seconds means the lower TTL has not reached most resolvers before the change is made. The propagation window remains determined by the old high TTL. Lower TTL well in advance, at least the full current TTL duration before the planned change.
Forgetting to raise TTL after migration: leaving a low TTL in place permanently after a migration unnecessarily increases DNS query volume and can be a minor factor in slower DNS resolution for some visitors. After a migration is stable and confirmed raise TTL back to a normal value, 3600 or higher.
Setting TTL too low permanently: a TTL of 60 seconds on production records means resolvers query the authoritative nameserver every minute from everywhere in the world. For high-traffic domains this generates enormous DNS query volume. Reserve very low TTLs for pre-migration windows and failover-critical configurations.
Setting TTL too high on records that need to change: a 7-day TTL on an A record that will need to be updated for a planned server migration means waiting at least a week between lowering the TTL and being able to make the change with minimal propagation delay. Set TTL values that reflect how often a record is realistically expected to change.