Live data from Hacker News

DNS taking 48+ hours to propagate is a myth

simonluijk.com

11–20 of 28 posts

Re: DNS taking 48+ hours to propagate is a myth

#11
post #9
post #2

TL;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.

My apologies - I glossed over your explanation of trace, as I've used it for years for other purposes, without the primary intention being this. expunging my other resolver rants from my OP

Re: DNS taking 48+ hours to propagate is a myth

#13
post #5
post #4

Before 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.

Explaining that to clients is hard. We say "it'll take about 72 hours for everything to sync over". If we're switching them to a new IP, we'll leave the old server on until 72-96 hours after we update DNS. We seriously still see traffic on the old server that long after the change, and ~72 hours is about how long it takes to get ~99% updated.

Re: DNS taking 48+ hours to propagate is a myth

#14
post #8

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 app…

Yes I quite agree with you, for established domains. It's interesting that only 3% of resolvers are parent-centric.

I was referring more to when registering a domain. To prevent the IPS resolver caching a non existent NS record for negative TTL.

Re: DNS taking 48+ hours to propagate is a myth

#15
I think the big missing point here is that it can take up to 48 hours (or even 72 hours) for every ISP to reset their cache and get your new destination. Sure, I can always run dig or even dscacheutil manually to wipe my computer's DNS cache, and I'm pointed over at OpenDNS and Google's DNS so I don't really have to worry about DNS caching issues, but my customers aren't.

I can't say "Hey look, it works on my machine so you must have a lazy ISP, your fault!" when they say "Hey it's been 6 hours and my website doesn't work yet", the proper answer is simply that in most cases it takes up to 48 hours to work.

Re: DNS taking 48+ hours to propagate is a myth

#16
post #14
post #8

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 app…

Yes I quite agree with you, for established domains. It's interesting that only 3% of resolvers are parent-centric. I was referring more to when registering a domain. To prevent the IPS resolver caching a non existent NS record for negative TTL.

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.

Re: DNS taking 48+ hours to propagate is a myth

#17
post #7

Earlier quoted context omitted.

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…

http://www.ietf.org/rfc/rfc1034.txt:

The TTL is assigned by the administrator for the zone where the data originates. While short TTLs can be used to minimize caching, and a zero TTL prohibits caching, the realities of Internet performance suggest that these times should be on the order of days for the typical host. If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following the change.

and http://www.ietf.org/rfc/rfc1912.txt:

1-5 days are typical values.

Re: DNS taking 48+ hours to propagate is a myth

#18
Yeah this is bad advice. In the real world, it often takes a couple days to fully propagate as many ISPs take awhile to update their cache-- consider edge cases like rural satellite internet. Even with a brand new domain, here's a common problem: some clients will have clicked on the domain url in their email before the DNS is setup, and have a local cache of the wrong DNS.

Re: DNS taking 48+ hours to propagate is a myth

#19
post #7

Earlier quoted context omitted.

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…

Please provide further detail on these '"big" recursive resolvers' that ignore TTLs. I'm yet to see one in the wild and so I'm somewhat dubious of the claim.

(Please don't be vague - post the addresses of the resolvers in question.)

Re: DNS taking 48+ hours to propagate is a myth

#20
post #14
post #8

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 app…

Yes I quite agree with you, for established domains. It's interesting that only 3% of resolvers are parent-centric. I was referring more to when registering a domain. To prevent the IPS resolver caching a non existent NS record for negative TTL.

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).

Post reply on HN