DNS TTL and Propagation: Impact on CDN Performance

DNS Time to Live (TTL) is the single most consequential DNS setting for CDN operations. It controls how long recursive resolvers and client machines cache DNS responses before requesting fresh answers from the authoritative nameserver. Setting this value too high locks users into stale routing decisions during failovers. Setting it too low floods authoritative nameservers with unnecessary queries and adds latency to the first request in every TTL window.

For organizations operating content delivery networks, DNS TTL is not merely a DNS configuration detail. It is a performance and reliability lever that directly affects failover speed, traffic distribution responsiveness, and the overhead cost of every user's first page load. This guide examines how TTL works in CDN contexts, what values to use, and how to manage the propagation process during migrations and incidents.

How Does DNS TTL Work in CDN Architectures?

When a user's browser resolves a CDN hostname like cdn.example.com, the query traverses a chain of DNS servers. The authoritative nameserver for the domain returns an IP address along with a TTL value. Each component in the resolution chain, including recursive resolvers (like Google's 8.8.8.8 or Cloudflare's 1.1.1.1), operating system stub resolvers, and the browser's internal DNS cache, stores this response for the specified TTL duration.

During the TTL window, no new DNS queries are sent for that hostname. The cached IP address is used directly. When the TTL expires, the next request triggers a fresh DNS lookup, which may return a different edge server IP based on current geo-routing decisions, server health, or load balancing algorithms.

CDN providers use DNS as a primary traffic steering mechanism. The CDN's authoritative DNS server evaluates each query's source IP (or EDNS Client Subnet data) and returns the IP of the optimal edge server. The TTL determines how frequently this routing decision can be updated for each user. Understanding the full DNS resolution process is essential for grasping how TTL interacts with CDN routing.

What TTL Values Should You Use for CDN Domains?

Optimal TTL values depend on the DNS record's role in your CDN architecture. The following table provides recommended ranges based on common CDN configurations:

Most major CDN providers default to 60-second TTLs for their edge DNS responses. Cloudflare uses 300 seconds for proxied records. AWS CloudFront returns 60-second TTLs for its distribution CNAMEs. Fastly recommends 30-60 seconds for domains behind their CDN.

What Is the Real Cost of Low TTL Values?

Every expired TTL triggers a fresh DNS resolution, which adds latency to the request that causes the re-lookup. The cost manifests in several ways:

Increased DNS query volume: A TTL of 30 seconds means each recursive resolver queries the authoritative server 2,880 times per day per domain, compared to 288 times with a 300-second TTL. For high-traffic sites with millions of users behind thousands of resolvers, this can generate millions of additional DNS queries daily.

Added latency on TTL expiry: A DNS lookup adds 5-100 milliseconds to the request that triggers it. With a 30-second TTL, roughly 3% of all requests (assuming steady traffic) pay this penalty. With a 300-second TTL, only 0.3% of requests incur the DNS overhead. Analyze this tradeoff with CDN performance metrics to find the right balance.

Resolver query limits: Some ISP resolvers throttle query rates from high-volume authoritative servers, which can cause intermittent resolution failures during traffic spikes. Very low TTLs exacerbate this risk.

The Case for Low TTLs

Despite the costs, low TTLs provide critical operational benefits:

• Fast failover: When an edge server or PoP goes down, the CDN's health check system updates DNS to route traffic elsewhere. Low TTLs ensure users pick up the routing change within seconds rather than minutes.
• Traffic steering agility: CDN providers continuously optimize routing based on real-time latency measurements. Low TTLs allow these optimizations to take effect quickly, improving the match between content routing decisions and actual network conditions.
• Migration flexibility: During CDN migrations or origin changes, low TTLs minimize the window during which some users hit the old configuration and others hit the new one.

Why Is Instant DNS Propagation a Myth?

A common misconception holds that setting a TTL to zero (or very low values) achieves instant propagation of DNS changes worldwide. In practice, several factors prevent truly instant propagation:

Resolver minimum TTL enforcement: Many recursive resolvers enforce minimum cache times regardless of the authoritative TTL. Google Public DNS enforces a minimum of 30 seconds. Some ISP resolvers cache for 300 seconds or more. This means your 0-second TTL is effectively 30-300 seconds depending on which resolver the user queries.

Operating system DNS caching: Windows caches DNS responses for up to 300 seconds by default (configurable via the DNS Client service). macOS and Linux also maintain stub resolver caches with their own minimum retention periods.

Browser DNS caching: Chrome caches DNS for 60 seconds. Firefox uses its own DNS cache with similar retention. These browser-level caches are independent of OS and resolver caches, adding another layer of stale DNS persistence.

Caching chain multiplication: A DNS change must propagate through the authoritative server, each recursive resolver that has cached the old record, the OS stub resolver, and the browser cache. Even if each layer respects the TTL, the worst-case propagation time is the previous TTL value (not the new one), because resolvers cached the old record with the old TTL.

In practice, expect DNS changes to reach 95% of users within one to two times the previous TTL value, plus 30-60 seconds for resolver minimum caching. Full worldwide propagation to 100% of users may take 24-48 hours due to outlier resolvers with non-compliant caching behavior.

What Is DNS Negative Caching and Why Does It Matter?

Negative caching is the often-overlooked counterpart to standard DNS caching. When a DNS query returns an error response, specifically NXDOMAIN (domain does not exist) or SERVFAIL (server failure), recursive resolvers cache that negative result according to the SOA record's minimum TTL field.

This creates a dangerous scenario during CDN configuration changes. If a misconfigured DNS zone momentarily returns NXDOMAIN for your CDN domain, resolvers worldwide will cache that "does not exist" response. Even after you fix the configuration, affected resolvers continue returning the negative cached result until the SOA minimum TTL expires, which is typically 300 to 3600 seconds.

Mitigating Negative Caching Risks

• Set the SOA minimum TTL to a reasonable value (300 seconds) rather than the default of 3600 seconds. This limits how long negative responses persist.
• Never delete DNS records before adding replacement records during migrations. Add the new record first, verify it resolves correctly, then remove the old one.
• Test DNS changes in a staging environment or with a low-traffic subdomain before applying to production.
• Monitor DNS resolution from multiple global vantage points using services that test resolution from diverse resolver networks.

How Should You Manage TTL During CDN Migrations?

CDN migrations, whether switching providers or changing architectures, require careful TTL management to minimize user impact. The following timeline provides a proven migration protocol:

Phase 1: TTL Reduction (48 Hours Before Migration)

Lower the TTL on all affected DNS records to 60 seconds. Wait at least 48 hours, which is the maximum reasonable cache duration of the previous (higher) TTL. This ensures all resolvers worldwide have picked up the shorter TTL before you make the actual change.

This step is critical and often skipped. If your current TTL is 3600 seconds and you change both the TTL and the DNS target simultaneously, some resolvers will cache the old IP for up to 3600 seconds, creating a prolonged split-brain scenario.

Phase 2: DNS Cutover

Change the DNS records to point to the new CDN. With a 60-second TTL, 95% of traffic will shift to the new CDN within 2-5 minutes. Monitor both the old and new CDN during this period. Key metrics to watch include error rates, latency, and cache hit ratios on the new CDN.

Phase 3: Stabilization (24-48 Hours After Migration)

Keep the low TTL in place for 24-48 hours after migration. This provides fast rollback capability: if issues emerge on the new CDN, you can revert the DNS change and traffic will shift back within minutes. Once satisfied with the new CDN's performance, raise the TTL back to your standard operating value.

Phase 4: TTL Restoration

Increase the TTL to your target value (typically 300 seconds for CDN CNAME records). The higher TTL takes effect immediately for new lookups, but existing cached records with the 60-second TTL will expire within 60 seconds and pick up the new, longer TTL on their next resolution.

How Do CDN Providers Handle TTL Internally?

CDN providers manage their own DNS infrastructure with sophisticated TTL strategies that go beyond simple static values. Understanding these internal mechanics helps explain the behavior you observe:

Dynamic TTL adjustment: Some CDN providers reduce TTL values automatically when they detect edge server issues, allowing faster rerouting during incidents. Once the incident resolves, TTLs increase back to normal values. This dynamic behavior is invisible to the domain owner but directly affects how quickly failover occurs.

Anycast DNS: CDN authoritative DNS servers themselves use anycast routing, meaning the DNS query goes to the nearest DNS PoP rather than a single central server. This reduces DNS resolution latency and increases DNS infrastructure resilience, which partially offsets the latency cost of low TTLs.

EDNS Client Subnet (ECS): Modern CDN DNS servers use EDNS Client Subnet information to make routing decisions based on the user's actual location rather than the resolver's location. When ECS is in play, the resolver must cache responses per client subnet prefix, which increases cache fragmentation and makes each cached entry serve a smaller population of users.

What Are Best Practices for DNS TTL in CDN Operations?

Based on operational experience across production CDN deployments, these practices provide the most reliable DNS behavior:

• Use 60-second TTL for CDN edge records as a default. This balances failover speed with DNS query overhead for most workloads.
• Never set TTL below 30 seconds in production. Most resolvers ignore lower values, so you gain no benefit while adding authoritative server load from non-compliant resolvers that do honor it.
• Pre-lower TTL before any DNS change. Reduce TTL at least 48 hours before planned changes. This is the single most important DNS migration practice.
• Monitor DNS resolution from multiple locations. Use global DNS monitoring to verify propagation status and detect resolver-specific caching anomalies.
• Set SOA minimum TTL to 300 seconds. This limits negative caching duration if DNS errors occur.
• Document your TTL strategy. Record the rationale for each record's TTL value so future operators understand why a given value was chosen.

DNS TTL is a deceptively simple setting with profound impact on CDN reliability and performance. The right TTL value is always a tradeoff between routing agility and query efficiency. By understanding how TTL interacts with the full CDN request flow, resolver behavior, and traffic management strategies, CDN operators can tune this critical parameter for optimal delivery under both normal conditions and incident response scenarios.