What is DNS TTL? How to Configure It for Faster DNS Propagation

TTL, or Time To Live, is a numeric value (in seconds) in a DNS record that tells resolvers around the world how long to cache that record before asking the authoritative DNS server for fresh data. This value directly controls how quickly DNS changes propagate globally — and it's one of the first things you should adjust before migrating hosting or changing an IP address.

How DNS TTL Works (Caching at Resolvers)

When a user types example.com into their browser, their ISP's DNS resolver checks its cache. If the record is cached and the TTL hasn't expired, it returns the cached IP immediately. Only when the TTL expires does the resolver query the authoritative DNS server for updated data.

Example: If TTL = 3600 (1 hour) and a resolver just fetched the record, it will wait 1 hour before querying again. Even if you change the IP immediately, users whose resolver has the old cache will see the old IP for up to 1 hour.

The key concept to grasp is that TTL does not count down from your authoritative DNS server — it counts down independently at every DNS resolver around the world. In practice, a DNS query travels through several layers of caching before reaching your authoritative server: the browser's own DNS cache, the operating system's stub resolver, and most importantly the recursive resolver run by the ISP or a public DNS provider such as 1.1.1.1 or 8.8.8.8, which serves millions of users simultaneously.

When an ISP's recursive resolver fetches your record into its cache, it starts counting down its own copy of the TTL. Suppose user A visits your site at 10:00, causing the resolver to cache the value with a 3600-second TTL. If user B (on the same ISP) visits at 10:30, they receive the cached answer instantly without ever touching your authoritative server, and that cache stays valid until 11:00. This is exactly why a DNS change does not take effect for everyone at once: each resolver started its TTL countdown at a different moment, so the window during which users worldwide see the new IP is staggered rather than instantaneous.

On top of that, some recursive resolvers enforce their own maximum cache TTL — for example, refusing to cache anything longer than 24 hours even if you set a higher value — while others impose a minimum TTL to keep query load down. This is why the TTL you set is best thought of as a recommendation to resolvers rather than an absolute command they are guaranteed to honor.

Recommended TTL Values by Record Type

Choosing the Right TTL for Each Record

There is no single TTL value that fits every record, because each record type has a different change pattern and risk profile. The simple guiding principle is: records that "change often or might need an emergency update" should use a low TTL, while records that are "very stable and rarely change" can use a high TTL to reduce load and improve resilience. The table below summarizes recommended values along with the practical reasoning behind each.

A practical note: many people mistakenly keep TTL permanently low "just in case they need to change something," but this forces resolvers to query your authoritative DNS far more often than necessary, adds latency to the first page load for each user, and increases the risk of an outage if your DNS server has a temporary problem. The correct approach is to "set a high default and only lower it when planning a change" — not to leave it permanently low.

TTL and DNSSEC: What You Need to Know

DNSSEC (Domain Name System Security Extensions) adds a layer of cryptographic signatures to DNS records, protecting against cache poisoning and spoofing attacks. When DNSSEC is enabled, TTL values become even more critical, because each signature record (RRSIG) has its own validity window that must be coordinated with the TTL of the records it covers.

The key rule is that the TTL of a DNSSEC-signed record should not exceed half of the signature validity period. If it does, resolvers may serve stale cached records whose signatures have already expired, causing users to see SERVFAIL or BOGUS errors that are difficult to diagnose. Most managed DNS providers set signature validity at 14–30 days, so keeping your main record TTLs below 7 days (604800 seconds) is a safe ceiling.

When rotating DNSKEY material (the cryptographic keys underpinning your DNSSEC chain), you should lower the DNSKEY TTL well in advance — just as you would lower an A record TTL before a server move. This ensures that all resolvers pick up the new key quickly once it is published, minimizing the validation gap during key rollover. AsiaGB supports DNSSEC on all domains registered through the platform, so you can enable this protection without managing keys manually.

TTL and CDN / Reverse Proxy Layers

When you use a CDN such as Cloudflare, AWS CloudFront, or Fastly, the caching picture becomes more complex. On top of DNS caching at resolvers, CDN edge nodes maintain their own cache layer spread across global points of presence.

A common source of confusion is that DNS TTL and CDN cache TTL are entirely separate concepts. DNS TTL tells resolvers how long to keep the IP address of the CDN edge, while CDN cache TTL (configured via Cache-Control headers or the CDN dashboard) tells edge nodes how long to serve a cached version of your content before pulling a fresh copy from your origin server. These two values run in parallel and must be planned independently.

The scenario that catches most administrators off guard is switching from one CDN provider to another, or removing CDN entirely to serve directly from the origin. The correct sequence is: lower your DNS TTL 24–48 hours before the switch, wait for stale caches to expire, then update your CNAME or A record to the new destination. Skipping this step means some users may continue hitting the old edge for several hours, receiving incorrect content or errors.

# Trace the full DNS resolution chain including CDN CNAME:
dig +trace example.com A

# Inspect CDN response headers to confirm cache behavior:
curl -I https://example.com | grep -i 'cache\|age\|x-cache'

Some CDN providers (including Cloudflare's "Override TTL" feature) can force browsers to cache DNS answers for a fixed period regardless of what your DNS record says. If you have such an override enabled, disable it before planning any IP or hosting migration — otherwise the override will counteract your carefully lowered DNS TTL.

TTL and Email Deliverability

The TTL values for email-related records — MX, SPF (TXT), DKIM (TXT), and DMARC (TXT) — have a direct impact on whether your outbound mail reaches the inbox or gets flagged as spam. When a receiving mail server checks whether a message is legitimate, it queries DNS for the sender's SPF, DKIM, and DMARC records. If those records were recently changed and the receiving server has an older cached version, the authentication check may fail temporarily, causing messages to be rejected or delivered to junk folders.

This situation arises most often when migrating email providers — for example, switching from shared hosting mail to a dedicated email service. Operators who overlook TTL during such migrations often report a wave of bounced or spam-tagged messages lasting anywhere from one hour to a full day, depending on the original TTL values.

The safest approach when switching email providers is to lower the TTL for MX, SPF, and DKIM records at least 48 hours before the cutover. Configure the new provider fully — including its DKIM key in your DNS — then switch the MX record, wait for propagation, and verify send and receive before removing the old configuration. This sequence virtually eliminates mail loss during the transition window.

How to Lower TTL Before a Server / DNS Move

Reducing TTL in advance is a critical best practice before any hosting migration. It ensures that when you change your IP address, the update propagates to all users as quickly as possible.

1. Lower TTL 24–48 hours in advance: Go to DNS Management and reduce your A Record TTL to 300 (5 minutes)
2. Wait for the old TTL to expire: If your previous TTL was 3600, wait 1 hour for all resolvers to pick up the new TTL value
3. Perform the hosting migration: Change the IP address in your DNS records
4. Check propagation: Use dnschecker.org to verify the new IP is visible worldwide
5. Restore TTL: After the migration is confirmed stable, increase TTL back to 3600 or 86400

How to Check the Current TTL of a Domain

Using Command Line

In the dig output, the number between the domain and record type is the remaining TTL. For example: example.com. 3600 IN A 1.2.3.4 — "3600" is the TTL in seconds.

Online Tools

• dnschecker.org — Check TTL from DNS servers in multiple countries simultaneously
• mxtoolbox.com/DNSLookup.aspx — View all DNS records with TTL values
• whatsmydns.net — Monitor global DNS propagation in real time

TTL Values to Avoid

• TTL = 0: Some resolvers interpret this as "no caching," but behavior varies — some may reject the record entirely
• Permanently low TTL (60–300): Forces resolvers to query your authoritative server constantly, increasing load and latency
• Extremely high TTL (over 86400): Emergency IP changes will take very long to propagate