google dns giving bad results

[Sir Moon]

For the domain cp9950.edgefcs.net, Google gives 60.254.184.138, which
times out. ISP gives 128.241.217.164, which works. This causes
TheDailyShow.com's full episodes to fail when using Google's DNS.
Naturally this makes Google DNS unuseable for me = )

[Paul S. R. Chisholm]

Sorry to hear that. When you say "times out," you mean you can't load
a web page or video?

Based on a public IP geolocation service I tried, it looks like
60.254.184.138 is in San Diego, California, and 128.241.217.164 is in
Englewood, Colorado. (I haven't verified these locations!)

Where are you? I would expect either address to work, but if you're in
Colorado, the Englewood address would probably be faster than the San
Diego address.

This is the "content distribution network" issue that's been discussed
elsewhere in this group. As Prem Ramaswami said, "We are continuing to
work with other companies and individuals on possible solutions."

Hope this helps. --PSRC

[Alex Smith]

FYI that 60.254.184.138 looks like it's in Japan (or somewhere in that region) from the routing that I'm seeing here in the UK.

I'd guess it's more likely that the cluster that serves 60.254.184.138 is having issues (it's Akamai) rather than a fault at Google. The reason why you'll get two IP's has been explained elsewhere :)

--
========================================================
You received this message because you are subscribed to the Google
Groups "public-dns-discuss" group.
To post to this group, send email to public-dn...@googlegroups.com
To unsubscribe from this group, send email to
public-dns-disc...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/public-dns-discuss?hl=en
For more information on Google Public DNS, please visit
http://code.google.com/speed/public-dns
========================================================

[ectom]

As a workaround you could edit your HOSTS file and add this line at
the bottom:

128.241.217.164 cp9950.edgefcs.net

This will override the GDNS server response and lead you directly to
the nearest akamai server.
I did the same with static.ak.fbcdn.net.
You could then keep using Google servers :-)

[kammann]

Akamai doesn't have any "issues". There is simply no point in
operating a content distribution network with edges close to the user
if due to some break in the DNS architecture a user from US is polling
an edge node in Japan.
Unlike Google, Akamai appears to have no transit network, i.e. each
node has only local peerings with neighboring networks.
Asuming a correctly configured DNS, the users of these neighboring
networks will directly connect to the closest node of the content
distribution network.
In case of a faulty DNS, both the user's provider and Akamai would
have to pay for the traffic on (possibly) expensive transit links.

It nice to hear that Google "continues to work with other companies on
possible solutions". But what if another big player would suddenly
introduces an own public DNS that would shuffle Google's CDN? Since
Google has an own transit network (i.e. if a user from US querys a
Google host in Asia the load is on Google's network), it would hurt.

On Dec 9, 4:35 pm, "Paul S. R. Chisholm" <psrchish...@gmail.com>
wrote:

> Sorry to hear that. When you say "times out," you mean you can't load
> a web page or video?
>
> Based on a public IP geolocation service I tried, it looks like
> 60.254.184.138 is in San Diego, California, and 128.241.217.164 is in
> Englewood, Colorado. (I haven't verified these locations!)
>
> Where are you? I would expect either address to work, but if you're in
> Colorado, the Englewood address would probably be faster than the San
> Diego address.
>
> This is the "content distribution network" issue that's been discussed
> elsewhere in this group. As Prem Ramaswami said, "We are continuing to
> work with other companies and individuals on possible solutions."
>
> Hope this helps.  --PSRC
>