Load balancing via DNS is entirely dependent on the behavior of caching DNS resolvers. Clients are beholden to how answers are sorted and it’s rarely fair. Even with a zero second TTL, the TTL of answers is often ignored. The situation is even worse with a TTL, as the answers are rarely re-resolved after the expiration. The JVM, for example, is notorious for defaulting to ignoring TTL entirely ruining round-robin load abounding via DNS. That’s not to say that it can’t be defective but its limitations should be well understood.
This is a nice write up about DNS RR and Happy Eyeball behavior. It was known to me, that all browsers do not treat TCP resets from one IP automatically as a fault on the domin and try the other IPs as well.
But I doubt the cloudflare results, especially in failure condition. Even with nginx this is solved by default (see proxy_next_upstream and the server behavior in upstream). And I'd be baffled, if they would not have cared about in pingora.
Are you sure, Cloudflare resolved more than one IP as its target?
I believe the story is that this used to be a feature of the Pro plan. Then they removed the distinction from pricing page, documentation, etc. but this behavior still stayed in the Free plan. At least that's my guess based on the information up till now.
You cannot control the behavior of your clients. This is a post about studying the behavior of common browsers and as you see, there is no single common pattern.
If you really care about latency: Use BGP anycast.
Load balancing via DNS is entirely dependent on the behavior of caching DNS resolvers. Clients are beholden to how answers are sorted and it’s rarely fair. Even with a zero second TTL, the TTL of answers is often ignored. The situation is even worse with a TTL, as the answers are rarely re-resolved after the expiration. The JVM, for example, is notorious for defaulting to ignoring TTL entirely ruining round-robin load abounding via DNS. That’s not to say that it can’t be defective but its limitations should be well understood.
Hey, thanks for such an insightful post. You can get free arm based servers from Oracle. It all depends on availability though. Attaching link below:
https://www.oracle.com/cloud/free/
Thanks!
Shouldn't the article end with a conclusion that Round Robin DNS shouldn't ever be used for Load Balancing? 🤔
Round robin dns docs https://developers.cloudflare.com/dns/manage-dns-records/how-to/round-robin-dns/
This is a nice write up about DNS RR and Happy Eyeball behavior. It was known to me, that all browsers do not treat TCP resets from one IP automatically as a fault on the domin and try the other IPs as well.
But I doubt the cloudflare results, especially in failure condition. Even with nginx this is solved by default (see proxy_next_upstream and the server behavior in upstream). And I'd be baffled, if they would not have cared about in pingora.
Are you sure, Cloudflare resolved more than one IP as its target?
I believe the story is that this used to be a feature of the Pro plan. Then they removed the distinction from pricing page, documentation, etc. but this behavior still stayed in the Free plan. At least that's my guess based on the information up till now.
Look at the HN discussion:
https://news.ycombinator.com/item?id=41955912
brilliant. So what should i use to ensure my end user gets the nearest edge location irrespective of the load ?
You cannot control the behavior of your clients. This is a post about studying the behavior of common browsers and as you see, there is no single common pattern.
If you really care about latency: Use BGP anycast.