DNS propagation / TTL

TTL (Time To Live) is a value attached to every DNS record that tells resolvers how many seconds they’re allowed to cache an answer before checking again, as Cloudflare’s own DNS documentation also explains. “DNS propagation” describes the real-world delay after a DNS change before every resolver worldwide that cached the old answer has that cache expire and fetch the new one — it isn’t instant, and the wait is bounded mainly by whatever TTL was set on the old record, not by the change itself. A short TTL (like 300 seconds) set in advance of a planned change, such as a server migration, lets the old answer expire quickly once the real change happens; a long-standing TTL of 86400 seconds or more means stragglers can take a full day or more to catch up. TTL is defined as part of the DNS resource record format in RFC 1035; RFC 2181 — whose IETF Datatracker page lists the later RFCs that update it — clarifies how resolvers are meant to treat conflicting TTLs for the same record set. Because each resolver’s cache expires independently, two resolvers queried at the same moment can briefly return different, both-currently-valid answers during that propagation window — see DNS answers that differ between resolvers for how to tell that ordinary case from an actual problem. Some large public resolvers let anyone shorten that wait for their own cache only: Google Public DNS’s FAQ describes a Flush Cache tool that refreshes its cached answers for common record types and most domain names without requiring proof of domain ownership, which does nothing for any other resolver’s cached copy.

AdminKit’s DNS propagation check queries four named public resolvers at once and reports whether they already agree, rather than checking one resolver at a time.

DNS propagation / TTL is part of AdminKit’s DNS cluster; the full AdminKit glossary lists other related terms.