DNS taking 48+ hours to propagate is a myth
simonluijk.com
DNS taking 48+ hours to propagate is a myth
1–10 of 28 posts
Re: DNS taking 48+ hours to propagate is a myth
#2TL;DR: You have a fine point to test a new domain's resolving status using dig +trace to not poison your cache. Existing domains need not apply.
You may need to explain your theory on your own website, to bring it back up under this load elsewhere... I can't get to your article because its down, but I see you have your TTL set to 72 hours:
www.simonluijk.com. 259200 IN CNAME simonluijk.com.
simonluijk.com. 259200 IN A 46.102.244.108
simonluijk.com. 172800 IN NS a.ns.zerigo.net.
simonluijk.com. 172800 IN NS b.ns.zerigo.net.
simonluijk.com. 172800 IN NS d.ns.zerigo.net.
simonluijk.com. 172800 IN NS c.ns.zerigo.net.
;; Received 261 bytes from 192.12.94.30#53(e.gtld-servers.net) in 114 ms
So someone could have a combination of 48 hour TTL cache'd response for your domain's DNS servers, and 72 hour cache'd response by your own DNS servers for your record. Thats not even taking in to account resolvers which ignore the TTL values and substitute their own.
Update: Finally got your article to load. Yes, for a brand new domain, manually testing resolution using dig +trace first, until you confirm it works (avoiding poisoning your cache with a negative response) is a fine suggestion.
Surely the registrar warnings exist for the more likely scenarios of any changes to existing domains. Added TL;DR at the top.
Update 2: Removed alternative resolver rants, and updated to emphasize the dig +trace option - as per author's comment below, and original article.
Re: DNS taking 48+ hours to propagate is a myth
#3This just isn't universally true. Some ccTLDs will indeed take anywhere from 12 to 48 hours to update.
If you are launching a service on a new domain and are about to link to that domain to make the launch public, do not assume that just because its working on your computer after 10 minutes that it is working for the rest of the US, or the world.
Re: DNS taking 48+ hours to propagate is a myth
#4Before 2004 Verisign only updated the authoritative DNS twice a day.
Then they changed it in January 2004 to every five minutes.
So yes, if you are an "old timer" you may remember it really taking up to 48 hours for everywhere around the world to be able to find a new .com
But also what they mean by 48 hours is for existing DNS, some users around the world may be on ISPs that heavily cache DNS.
Even wifi routers today have some persistent DNS caches and people rarely reboot or turn them off.
We moved a site a few weeks ago and the old IP still got some hits until last week. I gave up trying to trick all the caches and just used iptables to forward the packets from the old server to the new until everything finally caught up.
Re: DNS taking 48+ hours to propagate is a myth
#5Before 2004 Verisign only updated the authoritative DNS twice a day. Then they changed it in January 2004 to every five minutes. So yes, if you are an "old timer" you may remember it really taking up to 48 hours for everywhere around the world to be able to find a new .com But also what they mean by 48 hours is for existing DNS, some users around the world may be on ISPs that heavily cache DNS. Even wifi routers toda…
That's true, but "48 hours to propagate" is misleading because it sounds as though that's business as usual for DNS -- instead of the reality, in which rogue DNS servers cache beyond domains's declared TTL.
Re: DNS taking 48+ hours to propagate is a myth
#6People who know how DNS really works don't need to know that it doesn't really "propagate" in the conventional sense.
People who don't know how DNS works (and don't care) can be given it as a useful abstraction. If you have worked in tech support with people who want things to work and quite rightly don't want to know how the sausage is made, this might be ideal.
With anything, it depends on the audience.
Re: DNS taking 48+ hours to propagate is a myth
#7TL;DR: You have a fine point to test a new domain's resolving status using dig +trace to not poison your cache. Existing domains need not apply. You may need to explain your theory on your own website, to bring it back up under this load elsewhere... I can't get to your article because its down, but I see you have your TTL set to 72 hours: www.simonluijk.com. 259200 IN CNAME simonluijk.com. simonluijk.com. 259200 IN…
This is actually sadly exactly what the author missed in their article. DNS propagation is directly controlled by the TTL setting on a domain entry.
TTL stands for Time To Live, this is the number (in seconds) that the DNS entry tells people to keep it active in the DNS server cache's (presuming the DNS server will not over-ride this for either a higher or lower number, which is entirely their choice but not common.) This is done so that any request to adomain.com will not have to require a DNS lookup to the main serve for every page request.
It is true that if you have not done a lookup on the domain, then your computer and DNS servers would presumably not have any active DNS records for the domain. So you can make a change and "viola" within 5 minutes (the next time you visit the site) you will have the updated record. However, if you had recently done a DNS inquiry and eceived the record for the old DNS entry, you will need to wait for the old DNS entry to expire before the DNS server you are using will choose to look it up again. This doesn't go into any of the fun of what happens when you have 2 or more DNS servers setup, but ultimately what people are seeing is that the "48 hour" waiting period is substantially less, however most ISPs will stick to this default number to reduce worrisome support from their clients who think otherwise but don't know anything about how DNS works so support will never be able to explain this in laymen terms (or wait, did I just do that?)
Re: DNS taking 48+ hours to propagate is a myth
#8It 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:
;; ->>HEADERNow, 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:
;; ->>HEADERData 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.
Re: DNS taking 48+ hours to propagate is a myth
#9TL;DR: You have a fine point to test a new domain's resolving status using dig +trace to not poison your cache. Existing domains need not apply. You may need to explain your theory on your own website, to bring it back up under this load elsewhere... I can't get to your article because its down, but I see you have your TTL set to 72 hours: www.simonluijk.com. 259200 IN CNAME simonluijk.com. simonluijk.com. 259200 IN…
I was not expecting so much traffic. I kicked in a few more gunicorn instances. Hope that helps.
Well thats the point of using the -trace option. It makes dig act as the resolver bypassing all of the caches.
Re: DNS taking 48+ hours to propagate is a myth
#10TL;DR: You have a fine point to test a new domain's resolving status using dig +trace to not poison your cache. Existing domains need not apply. You may need to explain your theory on your own website, to bring it back up under this load elsewhere... I can't get to your article because its down, but I see you have your TTL set to 72 hours: www.simonluijk.com. 259200 IN CNAME simonluijk.com. simonluijk.com. 259200 IN…
This is actually sadly exactly what the author missed in their article. DNS propagation is directly controlled by the TTL setting on a domain entry. TTL stands for Time To Live, this is the number (in seconds) that the DNS entry tells people to keep it active in the DNS server cache's (presuming the DNS server will not over-ride this for either a higher or lower number, which is entirely their choice but not common.)…
me: web hosting sysadmin also dealing with clients. Yes, people really do freak out about DNS problems, and we quote 72 hours because we have clients on 6 continents.
Realistically, it takes 30 minutes - 4 hours for DNS updates to stick. Use http://host-tracker.com/ to check the IP of your site -- that's what we do. It tests something like 80 locations, and the results show the IP returned.
You are absolutely correct regarding the TTLs, and although I've seen well-intentioned help articles suggesting things like setting your TTL to 10-300 seconds...most "big" recursive resolvers will ignore TTLs below 3600 seconds (1 hour), so this doesn't really help.
Props to anyone who knows what RFC covers this behaviour and cites a minimum valid TTL. I'm not aware of any, but I'm not totally up on my RFCs :)