It depends a lot on the prior state of the domain. If it was assigned at all, or is being transfered, then is prudent to wait out the TTL of the NS record-set on the parent zone. Here's how it works.
When a resolver tries to lookup the IP for my website - www.notesfromthesound.com - it probably has the name-server set for "com" cached, it knows those servers, so I'll skip that step for now, but the same principle applies at that level.
So, the resolver queries a com server, and gets a referal;
cuan% dig www.notesfromthesound.com @i.gtld-servers.net.
; <<>> DiG 9.6-ESV-R4-P3 <<>> www.notesfromthesound.com @i.gtld-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25366
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.notesfromthesound.com. IN A
;; AUTHORITY SECTION:
notesfromthesound.com. 172800 IN NS ns-593.awsdns-10.net.
notesfromthesound.com. 172800 IN NS ns-431.awsdns-53.com.
notesfromthesound.com. 172800 IN NS ns-1199.awsdns-21.org.
notesfromthesound.com. 172800 IN NS ns-1820.awsdns-35.co.uk.
;; ADDITIONAL SECTION:
ns-593.awsdns-10.net. 172800 IN A 205.251.194.81
ns-431.awsdns-53.com. 172800 IN A 205.251.193.175
Note the TTL on the NS record set; 2 days . This is the TTL for the rrset in the parent zone. That TTL means "Feel free send queries for names within the notesfromthesound.com zone to these nameservers for up to two days".
Now, when I query the authoritative nameservers for the child zone, I might get a different TTL value for the same rrset;
cuan% dig www.notesfromthesound.com @ns-593.awsdns-10.net.
; <<>> DiG 9.6-ESV-R4-P3 <<>> www.notesfromthesound.com @ns-593.awsdns-10.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29364
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.notesfromthesound.com. IN A
;; ANSWER SECTION:
www.notesfromthesound.com. 300 IN A 72.32.231.8
;; AUTHORITY SECTION:
notesfromthesound.com. 7200 IN NS ns-431.awsdns-53.com.
notesfromthesound.com. 7200 IN NS ns-593.awsdns-10.net.
notesfromthesound.com. 7200 IN NS ns-1199.awsdns-21.org.
notesfromthesound.com. 7200 IN NS ns-1820.awsdns-35.co.uk.
Just two hours. But as a resolver, which value do I go with? Some resolvers take the position that the child zone is most authoritative about the operator's intent. That's called "child centric". Some take the position that the parent zone's intent matters more, and we shouldn't be bugging the parent zone nameservers very often because of misconfigured child zones, that's called parent-centric.
Data from actual experiments suggests that at least 3% of resolvers are parent-centric; https://mex.icann.org/ar/node/22921 , and as an operator I can confirm that it's regular to see queries coming in for up to 2 days after an upstream delegation change upstream.
In fact, you really have to wait out the higher of the two relevant TTLs, or risk queries being black-holed.
The article suggests that both Google Public DNS and nominum are parent centric, which might be a significant portion of the 3% (or larger at this point).
These days with the number of resolvers that have fall-back catch-all records designed to redirect you to a search / suggest feature, I think that you also need to worry about positive TTLs.
You're right that if a domain is pristine, and has never been queried, that in all likelihood, you'll be able to have it resolvable within minutes, not hours, but this still seems like a relatively uncommon case.
In practice, people do query for their domain as its propagating, and do buy meaningful names that are likely to have some low-level background rate of queries, and there's not much to stop the legion of bots that are watching for whois updates either.
I guess I take the most issue with your headline. DNS taking 48+ hours to propagate is not a myth.
Problem is, both your link headline here and the premise headlined on your blog are flat wrong, and are going to give sysadmins everywhere headaches if clients come across your article and think they've learned something.
The RFC snippet quoted in this comments thread is the right approach: keep a long TTL in normal practice, shorten it at least double the TTL in advance of a change (e.g., if 2 day TTL, shorten it 4 days before changes), dropping it down to 3600 or 300 depending on your tastes, and bring it back up after the change is stabilized.
In the case of registering a brand new, never existed before, domain, avoiding cache poisoning can help.
But DNS taking up to (TTL x number of layers of cache) is not a myth. We routinely see 5 - 7 days (globally) on 1 and 2 day TTLs, and 2 - 3 days (globally) on 5 minute TTLs (thanks to ISPs with 1 day min TTLs).
When a resolver tries to lookup the IP for my website - www.notesfromthesound.com - it probably has the name-server set for "com" cached, it knows those servers, so I'll skip that step for now, but the same principle applies at that level.
So, the resolver queries a com server, and gets a referal;
Note the TTL on the NS record set; 2 days . This is the TTL for the rrset in the parent zone. That TTL means "Feel free send queries for names within the notesfromthesound.com zone to these nameservers for up to two days".Now, when I query the authoritative nameservers for the child zone, I might get a different TTL value for the same rrset;
Just two hours. But as a resolver, which value do I go with? Some resolvers take the position that the child zone is most authoritative about the operator's intent. That's called "child centric". Some take the position that the parent zone's intent matters more, and we shouldn't be bugging the parent zone nameservers very often because of misconfigured child zones, that's called parent-centric.Data from actual experiments suggests that at least 3% of resolvers are parent-centric; https://mex.icann.org/ar/node/22921 , and as an operator I can confirm that it's regular to see queries coming in for up to 2 days after an upstream delegation change upstream.
In fact, you really have to wait out the higher of the two relevant TTLs, or risk queries being black-holed.
TLDR; honestly, wait 2 days.