Constantine A. Murenin wrote:
Are you suggesting that geolocation is inaccurate enough to misplace
Europe with Asia?Yes, of course.
Think mobile.
Why are you insisting that mobile will have wrong geolocation?
Because the GGSN is nowhere near the customer's location.
Your two examples are quite the opposite of each other, I don't know
if this was your intention.
In the first case, when a US-based (and/or ARIN issued) address space
is moved to Europe or Africa, a server-based geoloc would result in
suboptimal results, but a client-based geoloc would very likely
provide sought-after results.
In the second, VPN case -- exactly the opposite -- server-based would
work great, client based would be suboptimal.
Does it show that geoloc is hard to get right?
Yes.
But what I don't understand is why everyone implies that the status
quo with round-robin DNS is any better.
C.
Doesn't the Happy Eyeballs address selection algorithm work even when all the potential address are on the same network (be it IPv4 or v6)?
As many have pointed out physical location and network location don't always quite correlate. Just recently I've made a change in colos that brought my servers both 400 miles closer to my house, and 30ms further away via the network, and the transit providers in all cases had "Time Warner" in the name.
But what I don't understand is why everyone implies that the status
quo with round-robin DNS is any better.
I don't think anyone believes round robin DNS records is better. It's
that attempting to do better requires adding onto or changing
standards that must maintain backwards compatibility and thus nearly
useless until everyone adopts it, or hack jobs that have hilariously
funny failure scenarios that are unavoidable because it comes down to
"guess work".
You got a lot of answers telling you to not even try, and I don't know that you can configure any of them in 5 minutes.
That being said there are lots of options that might be "good enough":
- PowerDNS has a Geo backend - http://doc.powerdns.com/html/geo.html
- There are various patches for Bind
- Gdnsd - https://github.com/blblack/gdnsd
- GeoDNS - https://github.com/abh/geodns
I use the latter for the www.pool.ntp.org service where it sends users to one of about 4000 local servers ("pops") in about 100 countries about 15 billion times a month.
Ask
I haven't done it yet but gdnsd appeared to be the one to use when I
tested some stuff out. The idea was to deligate a geo.domainname.com
zone to gdnsd and have it perform the GEO DNS lookups. The PowerDNS
one, while testing it, gave me problems trying to figure out how to get
the geographical data since the readme I was using was out of date and a
lot of the information lead to non-existent links etc.
If this is for http and similar user-accessed (not machine accessed)
traffic, you could do what some large manufacturers and shipping companies
do: Provide a (relatively) low-bandwidth "Select where you are in the
world" global landing page which then redirects to a different
domain/subdomain for each region. This also lets them direct relatively
localized content easily. For example, panasonic.com can list items sold
mass-market for the US, panasonic.nl for the Netherlands, and
panasonic.com.au for Australia. Yes, you may well run into times that a
user in the US goes to the .au site because s/he wants to research an .au
product that isn't detailed on the US page but this is not the bulk of your
traffic (and, if through stats, you find it becomes so, you can work on
your design so that it isn't).
- Eric
Does it sound too complicated and pointy? Yes, it's not exactly
trivial, and not as good as BGP, but better than having 300ms latency
from a simple round-robin.
It sounds like you are asking about Geolocation, when what you really
want is latency-based selection. Latency is more complicated, and
influenced by factors other than purely Geographic location.
Furthermore, distance doesn't work all that well as a measure of
latency: it only defines the latency, in the best case scenario for a
link between the geo locations.
Why not just have the browser send a SYN packet to every IP in the
A/AAAA RRSET?
Whichever webserver's response to the connection handshake is received
first wins (lowest RTT latency); the other two or three connections
are just dropped, so there is some minor waste, in exchange for
picking the lowest RTT destination.
Now another alternative would be for the local network operator to
offer some sort of "latency lookup service";
Based on implementing packet inspection, and gathering statistical
information RTT and average throughput and retransmit rates
experienced during network users' TCP handshakes to remote prefixes,
aggregated at an AS level.
So the browser could query the latency lookup service for the
hostname, and receive a DNS reply annotated with an estimated
historical average latency, drop rate, throughput for the IP prefix
inquired about.
Or in fact... have the lookup service re-order or filter the query
result, so the responses with higher than a certain cutoff latency
are placed last in the response, or filtered/deleted from the
response, when there are at least 3 better choices.