wikipedia is to far with google public dns..

[Florin64x]

2 5 ms 5 ms 6 ms ro-buh01a-rd1-v276.astralnet.ro
[82.208.175.241]
3 37 ms 38 ms 41 ms de-fra03a-rd1-xe-3-1-0-1000.aorta.net
[213.46.160.13]
4 40 ms 63 ms 104 ms de-fra01a-ri2-xe-0-0-0.aorta.net
[213.46.179.54]
5 37 ms 41 ms 47 ms 213.46.179.62.aorta.net
[213.46.179.62]
6 37 ms 38 ms 39 ms ffm-bb1-link.telia.net [80.91.249.100]
7 51 ms 53 ms 54 ms prs-bb1-link.telia.net [80.91.254.205]
8 128 ms 129 ms 133 ms ash-bb1-link.telia.net [80.91.251.243]
9 143 ms 149 ms 158 ms atl-bb1-link.telia.net
[213.248.80.142]
10 165 ms 165 ms 166 ms mai-b1-link.telia.net [80.91.252.58]
11 160 ms 163 ms 166 ms hostway-115911-mai-b1.c.telia.net
[213.248.81.10]
12 169 ms 170 ms 171 ms 66.113.197.41
13 164 ms 166 ms 168 ms 66.113.197.94
14 168 ms 173 ms 180 ms rr.pmtpa.wikimedia.org [208.80.152.2]

[Mark]

Er....what does DNS have to do with distance, hop count etc?

All DNS does is translate 'www.wikipedia.org' into an IPv4 or IPv6
address. In this case '208.80.152.2'. After that it's whatever hops
from your location to wikipedia's servers.

[american.com...@gmail.com]

the name service translates an ip address into a domain name. Its the most requested service on the net. If that ip isn't in your local cache (ie; its not a web site you've visited before, you need to request the translation from another server. If the next server doesn't have the translation in its cache, it needs to request it from another server down the line. So proximity is a huge factor. But not only distance, but scope is a factor as well. A small podunk, little-used server won't be able to service a lot of requests using its cache, so it will have to go out and get serviced itself by other servers a lot. Google server are quite heavility used, so can rely on cached requests a lot more. So proximity AND scope are huge performance factors.

> --
>
> ========================================================
>
> 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
>
> ========================================================
>

[Alex Smith]

I think it's more the point that from this side of the world they should end up going to the Amsterdam cluster (91.198.174.2) for Wikipedia, not the US one.

Just another case of geolocation through DNS gone wrong :)

Indecently OpenDNS also sends traffic to the US from this side of the world, not a Google only issue.

- Alex

[Mark]

I agree with everything you're saying, but i interpreted the original
poster to say they thought the hop-count was too far as opposed to DNS
resolution time. I think the original poster was under the impression
that by using googleDNS it actually made the hop-count greater. DNS
does not increase hop-count (yes, there are some nuanced exceptions to
this but for 99.999% of the servers out there it will not increase
server response time).

Now it is completely conceivable that DNS resolution time was affected
(positively or negatively) based on the factors you mentioned.

On Dec 11, 3:49 pm, american.communist.pa...@gmail.com wrote:
> the name service translates an ip address into a domain name. Its the most  
> requested service on the net. If that ip isn't in your local cache (ie; its  
> not a web site you've visited before, you need to request the translation  
> from another server. If the next server doesn't have the translation in its  
> cache, it needs to request it from another server down the line. So  
> proximity is a huge factor. But not only distance, but scope is a factor as  
> well. A small podunk, little-used server won't be able to service a lot of  
> requests using its cache, so it will have to go out and get serviced itself  
> by other servers a lot. Google server are quite heavility used, so can rely  
> on cached requests a lot more. So proximity AND scope are huge performance  
> factors.
>

[Mark]

Ah yes...this is the "there are some nuanced exceptions to

this but for 99.999% of the servers out there it will not increase
server response time"

Geo location is a challenge...if not done properly. I was perhaps a
bit ambitious with 99.999%, perhaps more like 3 9's. ;-)

On Dec 11, 3:49 pm, Alex Smith <a...@alexsmith.me> wrote:
> I think it's more the point that from this side of the world they should end
> up going to the Amsterdam cluster (91.198.174.2) for Wikipedia, not the US
> one.
>
> Just another case of geolocation through DNS gone wrong :)
>
> Indecently OpenDNS also sends traffic to the US from this side of the world,
> not a Google only issue.
>
> - Alex
>

> > public-dns-disc...@googlegroups.com<public-dns-discuss%2Bunsu...@googlegroups.com>

[Florin64x]

why i should be redirected to us servers... when wikipedia have some
servers in germany...? opendns redirect me to germany

[m]

i still get directed to the us wikipedia servers. opendns sends me to the nl servers. i'm in germany.

looks like wikipedia has to do some work on their cdn..