DNS Propagation and TTL: What Site Owners Actually Need to Know

TTL: time resolvers may cache an answer

TTL (time to live) is a hint in seconds: “you may reuse this answer without asking again for up to N seconds.” Lower TTL before a planned change so stale caches expire faster; raise it afterward to reduce query load.

Some resolvers enforce minimum or maximum cache behavior; extremely low TTL everywhere can increase latency and provider query costs without guaranteeing instant global consistency.

Propagation vs caching confusion

“Propagation” is often misused. Authoritative data usually updates in one place; what varies is when each recursive resolver refreshes its cache. Tools that query a single public resolver can disagree with another region’s resolver.

Test with multiple vantage points (different DNS providers’ web checkers, `dig +trace`, or resolver APIs) and compare to your own ISP or office resolver.

Safer cutover playbook

• Lower TTL 24–48 hours before the change if traffic allows.
• Keep old infrastructure alive until the longest plausible cache window has passed.
• Validate TLS certificates and HTTP redirects on the new target before switching the name.
• Document rollback: which record values revert you to the previous stack.

CDNs and CNAME flattening

If you terminate TLS at a CDN, the public often sees the CDN’s answers. DNS changes at the origin may be invisible until the CDN’s own configuration or origin hostname is updated.

ALIAS/ANAME records at DNS providers solve apex-domain constraints but add another layer—know who serves the final A/AAAA records.