How long does DNS propagation take? The TTLs we measured

Nothing is pushed across the internet when you save a DNS record. The authoritative nameservers answer with the new value within seconds, and every other resolver keeps whatever it cached until that answer's TTL runs out. The DNS propagation glossary entry explains the mechanism. What people call propagation time is one of three numbers:

• You changed an existing record. The worst case is the TTL the old record was served with. You set that number yourself, which is why lowering it a day ahead of a planned change works.
• You created a record that did not exist. If a resolver asked for the name before you created it, it cached the answer "nothing here" and keeps it for the zone's negative TTL. Your DNS host sets that number in the zone's SOA record, and most hosts do not let you change it.
• You changed nameservers. The delegation lives in the parent zone at the registry. Resolvers that cached it keep asking the old nameservers until the longer of two TTLs runs out: the registry's on its NS records, and the old DNS host's on its own copy of them. You cannot shorten the registry's.

On 2026-09-23 we sent DNS queries straight to each zone's authoritative nameserver, with recursion off, so every TTL is the full value the source hands out rather than a cached copy counting down. For each top-level domain we read the TTL on the NS records it returns for a well-known domain, and the SOA it returns for a name that does not exist. For each zone we read its SOA record.

The negative TTL follows IETF, section 5:

When the authoritative server creates this record its TTL is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.

So a zone whose SOA says MINIMUM 86400 but is itself served with a TTL of 900 gets a 15-minute negative TTL, not a day. 5 of the 36 zones have a MINIMUM larger than their SOA TTL, so their MINIMUM field alone would overstate the wait.

This is the slow one. .com, .net, .uk hand out the NS records for every domain under them with a TTL of 2 days. A resolver that looked up your domain just before you switched nameservers may keep sending queries to the old DNS host for that long, or longer if the old host's own copy of those NS records carries a bigger TTL. Keep the old host serving correct records until the change has settled.

The second column matters for newly registered domains. Until the domain is delegated, the registry answers "no such domain", and a resolver that asked early keeps that answer for the TLD's negative TTL.

Across the 36 zones below, the median negative TTL is 15 min. 33 of 36 are at an hour or less, and 3 are a day or more (linode.com, he.net, cloudns.net). The sample is the zones of registrars and DNS hosts themselves, a handful of SaaS companies, and dc.mrneon.online, the zone where DoDomain proved its Domain Connect templates. It shows the spread, not a market share.

Zones on Cloudflare's standard DNS returned 1800 seconds (30 minutes), except basecamp.com, hey.com and 37signals.com, which returned 60; shopify.com, on Cloudflare's Foundation DNS, returned 300. Amazon Route 53 zones returned their SOA with a TTL of 900 seconds, so their negative TTL is at most 15 minutes whatever their MINIMUM says.

A zone that asks for a two-day negative TTL does not always get it. The two most widely deployed open-source resolvers put a ceiling on how long they keep a negative answer. ISC:

The default max-ncache-ttl is 10800 seconds (3 hours).

NLnet Labs documents cache-max-negative-ttl with "Default: 3600", one hour. On resolvers running either default, a missing record in any of the zones above reappears within three hours at most. Public resolver services and ISPs may configure their own ceilings, and they do not publish them all.

• Do not look a record up before it exists. A single query for the name, from you, a monitoring tool or an impatient verification step, plants the negative answer. Create the record first, then check.
• Check the authoritative nameservers, not a resolver. IETF requires the SOA in every negative answer ("Name servers authoritative for a zone MUST include the SOA record of the zone in the authority section of the response"), so the source always knows the truth without a cache in the way. The DNS propagation checker reads the authoritative answer and three public resolvers side by side.
• Make sure you edited the right place. If the authoritative answer is wrong, no amount of waiting helps. The usual cause is a record added at the registrar while the zone is served somewhere else. The DNS provider detector shows which host actually answers, and registrar vs DNS host explains the difference.
• For a planned change, lower the TTL first. Drop the record's TTL to a few minutes, wait one full old TTL, then make the change.

When your customers add a record for your product, the negative TTL is the delay they feel. A verify button that queries a public resolver before the customer has saved the record can make the next several minutes, or hours on some hosts, look like failure. DoDomain checks each record at the domain's authoritative nameservers, so a record counts as live as soon as the customer's DNS host serves it, and it keeps re-checking connected domains afterwards. The TXT record verification entry covers the ownership step, and how to let customers use their own domain covers the whole feature.

All external pages retrieved 2026-09-23. Quotes are verbatim. The TTL tables are DoDomain's own measurements from 2026-09-23.

1. IETF, RFC 2308: Negative Caching of DNS Queries (DNS NCACHE). How long a resolver may cache a 'no such name' or 'no such record' answer, and where that number comes from.
2. ISC, BIND 9 Configuration Reference. BIND's default ceiling on how long it keeps a negative answer.
3. NLnet Labs, unbound.conf(5). Unbound's default ceiling on how long it keeps a negative answer.