If you know all of your clients, then you don't even need DNS. But, you don't know all of your clients. Nor do you always know your upstream DNS provider.
Design for failure. Don't fabricate failure.
Design for failure. Don't fabricate failure.
A large number of services successfully achieve their failure tolerances via these kinds of DNS methods. That doesn't mean all services would or that it's always the best answer, it just means it's a path you can consider when designing for the needs of a system.
It is an absurd train of thought that nobody in their right mind would consider... just like using DNS-RR as a replacement for load balancing.
LWS get away with it because of Anycast...
https://www.cloudflare.com/en-gb/learning/cdn/glossary/anyca...
More directly - is there some set of common web client I've been missing for many years that just doesn't follow DNS TTLs or try alternate records? I think the article gets it right with the wish list at the end containing a Amazon Route 53-like "pull dead entries automatically" note but maybe I'm missing something else? I've used this approach (pull the dead server entries from DNS, wait for TTL) and never caught any unexpected failures during outages but maybe I haven't been looking in the right places?
If you mean it's possible to design something with round-robin DNS in a way that more clients than you expect will fail then absolutely, you can do things the wrong way with most any solution. Sometimes you can be fine with a subset of clients not always working during an outage or you can be fine with a solution which provides slower failover than an active load balancer. What I'm trying to find is why round-robin DNS must always be the wrong answer in all design cases.
Yes. There are tons of people with outdated and/or buggy software still using the internet today.
I don't understand why anyone would argue for this as a solution when there are near zero effort better ways of doing this that don't have any of the negative downsides.
Running load balancers does have a downside, every single design choice other than "don't do anything" is another point of configuration and cost. Round-robin based DNS solutions often require nothing more than adding a second A record and are possible the simplest solution to many problems for that reason. Many cloud DNS systems offer automatic pullout functionality if that's even a need, keeping cases where pullout is a must still not needing to move to more complex answers.
Solutions only make sense in context of what service one is delivering, not in what thinks sounds sexiest, what is the absolute best, or what could be a possible problem in some other use case. That you can think of a case it could possibly not work out is not the same thing as an example of why it's a bad design for everyone - or even that scenario. If you can't gather data the answer is to find a way to do so and make a data driven decision, not swag based on personal opinion. Not every app is only correctly scoped when resources are put in to make it a fluid 144 FPS native experience in <1 MB package, not every DC needs 2n redundancy to be up enough for its customers, not every database needs to be designed to scale to a billion users, and not every web service needs a load balancer to be reliable enough for the use case.
If you get to the point of needing what you think RRD is providing you, then you might as well do it using a solution that doesn't have the negative side effects of RRD.
If you are going as far as using a cloud dns system with "automatic pullout", then you might as well just use a cloud dns, like CF, that solves the round robin dns known issues for you.
An example of a time failover needs to be instant or failover doesn't matter at all is completely unrelated to whether or not there are times "somewhat decent" failover is needed. Not to mention times load balancing primary role may be to balance the load rather than boost redundancy.
As my personal example: waiting a seconds (or a couple minutes in the absolute worst case) to reconnect to a web terminal session in the occasional failover is not an impacting issue, waiting for someone to troubleshoot and diagnose a single server outage (a couple of minutes to many hours in the worst case) is an event worthy of handing out free vouchers to do the training another time. We've never had to do the latter due to remote training infrastructure failover issues in many years without a traditional load balancer (despite many outages) and it's allowed the training infrastructure to be extremely lightly staffed.
As the example from the blog: waiting seconds (or a couple minutes in the absolute worst case) for free map tiles to load in the occasional failover is probably preferable when weighed against things spending limited money on load balancers vs additional servers for all-round performance and scalability (tying back to the "balance the load" use case being the bigger value per dollar).
> If you are going as far as using a cloud dns system with "automatic pullout", then you might as well just use a cloud dns, like CF, that solves the round robin dns known issues for you.
Not sure what you mean here, CF's cloud dns is indeed one example of what I meant by a cloud dns system with "automatic pullout". It's referenced in the article, Zero Downtime Failover. Perhaps you meant to say "why not just use Cloudflare Load Balancing at that point" instead? The answer to that, if it were the question, is it's a paid addon ("Running load balancers does have a downside") as mentioned in the article. If that wasn't the intended question, then yes - you've got it, though I'm not sure how it's "might as well" rather than exactly what was said to use.
If I had to guess (and I could be very wrong) you come more from a background on the for profit high end datacenter hosted services side. Large scale, high performance, bleeding edge services for high dollar, 2n redundancy, high dollar equipment support contracts, the idea of not having cold spares on site for things with n+2 (or more) hot redundancy unthinkable given the target SLAs shouldn't allow waiting for equipment to show up until redundancy levels are back. That's fine and dandy. It's a fun type of environment and comes with certain assumptions... but trying to apply the common sense logic you'd use in those kinds of scenarios like "just assume you need full load balancers if you're going to make any uptime guarantee at all" doesn't necessarily apply to everyone else in all other scenarios. That's why engineering starts with asking more about what in the use case drives that decision rather than declaring a solution universally wrong out of the gate.
I don't know if there is such a list but older versions of Java are pretty famous for caching the DNS responses indefinitely. I don't hear much about it these days so I assume it was probably fixed around Java 8.