Actually that does make sense. Because those locations can be stored without a registar request.
And because most registars charge people who do a huge amout of location requests its probably cheaper to do it through the dns. But... its also risky because I often use a dns in NL :) So its not a smart way to work. On 31 December 2010 13:38:34 Soh Kam Yung wrote: > Among the responses to the original posting was this comment. Does it > make sense? > > ===== > Keith Brady 5:21pm on Monday, December 20th, 2010 # Reply > > The “somehow uses our DNS routing to determine our location” is > actually quite straightforward. All major internet services (Akamai > and Google included) look up the IP address of the querying DNS server > (usually your ISP’s server) in a location database (something like > doing ‘whois w.x.y.z’ to look up RIPE et al) to figure out your > approximate location and serve the IP address of a nearby point of > presence (e.g. Datacenter or peering point). > > The tricky bit there is that they use the IP address of the DNS > server, not the original requester. Usually that’s nearly the same > thing since it’s your ISP (or your own one) and you are routing out to > the internet in much the same way. The problem comes when you’re using > OpenDNS or GoogleDNS. While they both have many servers that are > globally distributed (using anycast to do that despite using a single > IP address) these servers aren’t as close to you as your ISP’s and > will have a funneling effect. > > There’s a modification to the standard in progress for the requesting > DNS server to pass along the IP address of the querying client and > that will make a lot of this go away. AFAIK, GoogleDNS does this and > Google servers can take advantage of it (though it’s a proposed > standard and so open). > ===== > > On Fri, Dec 31, 2010 at 1:27 PM, Mike Veltman <[email protected]> wrote: > > Thats a bit odd, because its based on the clients ip, not the dns ip. > > > > Otherwise I would also have problems with Microsoft downloads because > > they are also akamai based. > > > > So this can not be the whole explanation.. > > > > On 31 December 2010 12:57:57 Soh Kam Yung wrote: > >> [ > >> http://apple.slashdot.org/story/10/12/31/0110226/Beware-of-Using-Google- > >> Or -Open-DNS-For-iTunes ] > >> [ http://joemaller.com/2577/itunes-slowdowns-with-google-dns/ ] > >> > >> Anybody else using Google or Open DNS and encountered a similar issue > >> with location based servers? > >> > >> ===== > >> Beware of Using Google Or Open DNS For iTunes on Thursday December 30, > >> @11:20PM Posted by timothy on Thursday December 30, @11:20PM > >> from the speak-friend-and-enter-slowly dept. > >> > >> Relayman writes "Joe Mailer wanted to download an iTunes movie > >> recently and his Apple TV told him it would take two hours. When he > >> switched his DNS resolver settings, the download time dropped to less > >> than 20 seconds. Apparently, iTunes content is served by Akamai which > >> uses geolocation based on the IP address of the DNS request to > >> determine which server should provide his content. When you use Google > >> or Open DNS to resolve the Apple domain name, all the requests to > >> Akamai appear to be coming from the same location and they're all > >> directed to the same server pool, overloading that pool and causing > >> the slow downloads. The solution: Be wary of using Google or Open DNS > >> when downloading iTunes files or similar large files. Use your own > >> ISPs DNS servers instead or run your own resolving DNS server." > >> ===== > > > > -- > > With regards, > > Mike Veltman -- With regards, Mike Veltman A world with only one operating system, is a world without choice. _______________________________________________ LUGS Mailing list - [email protected] List FAQ: http://wiki.lugs.org.sg/LugsMailingListFaq Info page: http://www.lugs.org.sg/mailman/listinfo/slugnet To unsubscribe send an empty email to: [email protected]
