On Mon, Jan 4, 2016 at 2:48 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Mon, 04 Jan 2016 17:23:20 -0500, Christopher Morrow said:
https://developers.google.com/speed/public-dns/faq?hl=en
there I asked jeeves for ya!
So in how many of the 196 or so extant countries does 8.8.8.8 resolve to a host which, when it sends a query up the chain, appears to be in the same country as the machine that made the original query?
With 43 subnets for servers and only 13 unique airport codes, the conclusion is that without additional fun and games, locating based on the DNS for 8.8.8.8 will be incorrect for *most* countries. Probably gets the continent right.
If you're load-balancing by country, you've already lost. It turns out the USA has more users than Luxembourg, Samoa, Monaco, Bermuda, and Andorra *combined*. On Mon, 04 Jan 2016 14:17:56 -0800, Owen DeLong said:
Further, 8.8.8.8 actually fully supports EDNS0 Client Subnet capability, so if the geo-IP balancer in question wants, they can eliminate the failure mode you are describing in that case.
Which only helps for people using 8.8.8.8. Client Subnet does help the issue, but it doesn't actually fix it until support is near ubiquitous across intermediate nameservers that have clients in other geographic locations...
(I believe that the fact that Google found a need to create EDNS0 Client Subnet *at all* is proof that using the DNS address for localization is problematic...)
And again - it's still something that needs work upstream to support, and you *still* have to deal with the case where the intermediate DNS server doesn't do Client Subnet.
Not all auth servers need to support Client Subnet... just those that want to do DNS-based load-balancing in a more fine-grained level than already achieved by Google's multiple datacenters. And while I don't know what software most companies use for their DNS-based load-balancing, I'd guess that adding Client Subnet support is a minor feature request relative to the other required logic. Damian