I can't edit my post but I should note that there is an edge case I'm aware of where this kind of solution might not be the fastest solution for the end user, and this would likely affect what filepicker.io are doing too.
The edge case is that some DNS providers (Google, OpenDNS) already pick what they feel is the closest end point.
I haven't fully investigated this, and I don't know whether it is affecting some users. But when I implemented my solution I was aware that it might be possible for some small subset of users, for this to not result in a faster connection than if I'd done nothing at all (the closest resolver to Google may actually be further from the customer than the local server I run).
I'm just betting that for the vast majority of users this does bring about a noticeable increase in speed.
Google runs lots of DNS servers. You (your ISP) pick the 8.8.8.8 closest to you. That will in turn do the lookup and get the linode closest to google dns, which should also be close to you.
If you're using a North American Google DNS server, you'll get answers that say NA. If you use the DNS server in Europe, you'll get answers that say EU.
I'm assuming Google doesn't try to sync and cache between 8.8.8.8 instances, but I don't see why they would. That's a lot of work for no benefit.
IIRC the google public DNS service has cache coherency intra location, but not inter.
From what I've seen end users hit a google dns cluster in the approximate geo area. However I e definitely seen odd peering of a public DNS node in EU hitting provider anycast nodes in NA.
If a request via 8.8.8.8 surfaced at a DNS server in North America, and DNSMadeEasy (in my example) then answered that request with a "Oh, you must be in North America, well for you the IP address of the web site is"... then you might not have got the answer you expected.
i.e. You might be in Spain, and using OpenDNS (or Google) the DNS query against DNSMadeEasy might surface on the East Coast of the USA, and as such you'd end up at Linode Newark rather than Linode London.
That particular example is pure speculation, but it illustrates the point.
As I said, I believe that the amount this must happen is just a slight edge case and as a whole isn't worth troubling about. But it is there as an edge case I'm aware of.
And if someone reads this thread and thinks, "Hey, this distributing SSL stuff is a great idea.", then as always, caveat emptor and check whether any potential issues that might arise are an issue for you and your application.
The edge case is that some DNS providers (Google, OpenDNS) already pick what they feel is the closest end point.
I read about that stuff over here a while ago: http://tech.slashdot.org/story/11/08/30/1635232/google-and-o...
And this comment explains it best: http://tech.slashdot.org/comments.pl?sid=2404950&cid=372...
I haven't fully investigated this, and I don't know whether it is affecting some users. But when I implemented my solution I was aware that it might be possible for some small subset of users, for this to not result in a faster connection than if I'd done nothing at all (the closest resolver to Google may actually be further from the customer than the local server I run).
I'm just betting that for the vast majority of users this does bring about a noticeable increase in speed.