[jameshart]

Used to work in the DNS business. "It will take up to 24 hours to propagate" is a way to manage expectations and prevent support calls from coming in within the first 24 hours after a DNS change, not a reflection of actual DNS propagation times.

[aroch]

I don't know how things work now, but at least a few years ago there were plenty of DNS server that would take basically the full 48hours to update, regardless of TTL.

[ceejayoz]

I think the rise of no-fixed-IP load balancers like Amazon ELB has dramatically reduced that.

[rev_bird]

Aren't the IPs of the load balancers more or less fixed, though?

[syncsynchalt]

Using a PaaS like Elastic Beanstalk will mean a new load balancer on each publish, and those can happen multiple times per hour in a busy day.

[vacri]

I'm not a netadmin, so don't know the innards of how it all works, but one day I watched a domain of ours pointing to an amazon load-balancer spread across multiple AZs - the IP address would change in DNS every so often, flipping between the AZs, presumably.

[gr8balls04]

Implementations will differ for "elastic" software defined load balancing so understand this is not a definitive statement applicable to all cloud service providers. In the case of AWS a default ELB set to serve one zone might have one IP. If it is configured to serve to 3 zones it may then have 3 IP addresses. These are minimums and they do change randomly so AWS warns you not o set A Records to IPs of those.

This is not hardware. This is software defined networking which you should apply one of the rules of good cloud design which is to expect failure - and this is a feature - IPs change. Deal with it. ;)

Further we have the TTL issue noted and an very interesting thing happens there. If you use a default of say 300 or more seconds for your FQDN in the DNS record which has even a CNAME to an ELB set of FQDNs (if multiple ELBs for example) then your going to have a condition at some times where that 300 seconds is still ticking down when the say 60 second TTL for the ELB's fqdn expires and or the ELB IP itself has changed. In that time span your resolved IP may be assigned to another ELB and traffic going to your platform hits some other platform. So perhaps at the first 1 second mark of your 300 second TTL start the AWS ELB TTL has expired and perhaps is assigned to nothing - your traffic gets failure to connect - then the IP is assigned to some other FQDN and your traffic hits some other ELB. (Your church patrons now get porn perhaps.) The flip side is true and interesting to watch in logs.

How to take advantage of this feature? Oh that is fun. Marketing? Route all such identifiable traffic to good bad or ugly ends?

This situation should be expected.

[danellis]

I hate the term "DNS propagation". It confuses people, and makes them think things that aren't true, like a new domain isn't usable until it "propagates" through the Internet.

[nucleardog]

Again, managing expectations.

We tell clients that we've launched their site, but that the DNS changes might take up to 48 hours to propagate.

Realistically, from our office and to most of the world it's probably live within 5 minutes. One of our local ISPs happens to be one of those irritating ones that just ignores your TTL and caches records for days at a time.

Sometimes one of their servers will end up with the new record and one with the old. That combined with peoples' home routers caching records (again, sometimes ignoring TTLs) can lead to fun situations where the site might load fine for a couple hours (hit the good ISP server, local router cached) then the old site for a couple of hours (hit the bad server, local router cached...).

I used to try and explain it to people but after having enough people freak out about how their site switched back, it's not live yet, etc, etc... I just tell them it's going to take 48 hours. If it's visible earlier it's a pleasant surprise, and if it takes two days I don't get any panicked phone calls.