DNS TTL: Choosing the Right Value

## DNS TTL: Choosing the Right Value TTL (Time to Live) is the number of seconds a DNS resolver is permitted to cache a DNS record before re-querying the authoritative server. It is one of the most important — and most misunderstood — DNS settings. Set it too high and your changes propagate slowly. Set it too low and you generate excessive query load and increase latency for users. The right TTL depends on the record type and how often it changes. ## How TTL Works in Practice When your browser queries `example.com` and receives an A record with `TTL 3600`, the resolver stores that answer for 3600 seconds (1 hour). Every subsequent query within that hour is answered from cache — fast, and without hitting your authoritative nameserver. After 3600 seconds, the cache entry expires. The resolver asks your authoritative nameserver again, receives the current value (which may have changed), and caches it for another 3600 seconds. The key insight: **TTL is a maximum cache time, not a minimum propagation time.** A resolver that cached your record 1 second before the TTL expired will re-query almost immediately. One that cached it 1 second after will hold the old value for the full TTL period. ## TTL Values by Record Type Different records have different change frequencies, and TTLs should reflect that: | Record Type | Recommended TTL | Rationale | |-------------|----------------|-----------| | NS records | 86400 (24h) | Almost never change | | SOA record | 3600–86400 | Set by nameserver software | | A / AAAA | 3600 (1h) | May change on server migrations | | CNAME | 3600 (1h) | Changes infrequently | | MX records | 3600 (1h) | Email servers change rarely | | TXT (SPF) | 3600 (1h) | Changes when adding senders | | TXT (DKIM) | 86400 (24h) | Stable once configured | | TXT (DMARC) | 3600 (1h) | May adjust policy periodically | | CAA records | 3600 (1h) | Stable, but can change on provider switch | ## Pre-Migration TTL Strategy The most critical time to think about TTL is **before** a migration. If you plan to: - Move your site to a new server (A record change) - Switch email providers (MX record change) - Transfer DNS to Cloudflare (NS record change) Lower the relevant TTLs to 300 seconds (5 minutes) at least 24–48 hours before the change. This way: 1. Existing caches expire with the old high TTL (up to 24 hours of waiting) 2. After caches expire, resolvers re-query and get the low TTL 3. When you make the actual DNS change, it propagates in ~10 minutes rather than ~24 hours 4. After the migration is stable, raise TTLs back to 3600 **Skipping this step is the most common DNS migration mistake.** Without pre-lowering TTLs, you might be waiting 24 hours for full propagation while users hit the old server. ## TTL and Query Volume Very low TTLs increase the number of queries hitting your authoritative nameserver. For most hosted DNS services (Cloudflare, Route 53, NS1), this is included in pricing and not a practical concern. For self-hosted BIND or PowerDNS, low TTLs on high-traffic domains can generate significant query load. The math: if a record has TTL 300 and 100,000 users look up your domain per day, each user's resolver re-queries every 5 minutes. Peak query rate ≈ 100,000 ÷ 300 = ~333 queries/second to your authoritative server. With TTL 3600, that drops to ~28 queries/second. ## Minimum TTL: The SOA Record The SOA record contains a `MINIMUM` field (also called `MINIMUM TTL`). This value is now used for **negative caching TTL** — how long resolvers cache a "record does not exist" response. If someone queries `api.example.com` and gets NXDOMAIN (not found), the resolver caches that negative response for the SOA MINIMUM seconds. Even after you add the `api` record, resolvers that cached the NXDOMAIN continue returning it until the negative TTL expires. Keep SOA MINIMUM around 300–600 seconds to allow quick recovery from accidentally deleted records or delays in adding new ones. ## TTL Best Practices **Do not set TTL to 0.** A TTL of 0 theoretically means "do not cache," but behavior varies by resolver. Some cache anyway. It also guarantees every user lookup hits your authoritative server, which is inefficient. **Use 3600 for most records.** One hour is a practical balance between propagation speed and cache efficiency. **Use 86400 for stable records.** NS records and DKIM TXT records change rarely — long TTLs reduce query load without meaningful downside. **Use 300 during migrations.** Temporarily drop to 5 minutes before planned changes, then raise back after stability is confirmed. **Monitor before raising TTL after migration.** After a migration, confirm traffic is flowing to the new server for at least 15–30 minutes before raising TTLs back to 3600. This gives you a fast rollback window if something is wrong. ## TTL in Cloudflare Cloudflare's free plan enforces a minimum TTL of 300 seconds on proxied records and allows as low as 60 seconds on unproxied records. Paid plans allow TTLs down to 30 seconds. For Cloudflare-proxied records, the TTL you set has little effect on end users — Cloudflare's edge caches and serves responses from its global network, not directly from your authoritative nameserver. The TTL is mainly relevant to other tools querying your DNS directly. ## Checking Remaining TTL ```bash # The TTL in dig output decreases as the cache ages dig example.com A # Query a specific resolver to see its current cached TTL dig @8.8.8.8 example.com A +noall +answer ``` If you see `TTL 3540` where you set `TTL 3600`, that record was cached 60 seconds ago and will expire in 3540 more seconds. ## Next Steps - Understanding DNS Propagation — understand how TTL affects propagation timing - DNS During Domain Migration — step-by-step TTL management during DNS migrations - Setting Up DNS for Your Domain — set TTLs correctly from the start