Summary: Youtube Geolocation

Mon May 2 15:08:32 UTC 2011

A couple of weeks ago, I posted (http://tinyurl.com/3btmf55) the following
question to the list asking for assistance:

>We're experiencing very poor quality with You Tube, and it appears we're
>subject to a bad entry within a geolocation database somewhere.
>
>When we attempt to view videos, the contact comes back to us from IPs
>like:
>
>208.117.226.21 (traceroute's through Frankfurt)
>173.194.50.47
>74.125.100.29
>
>All of those IPs are >125ms away from us (67.217.144.0/20, and
>216.14.144.0/20).
>
>However, we've never experienced redirection problems with Google before
>(we always land at www.google.com), so I'm not sure where to take our
>trouble.
>
>The page at:
>
>http://www.google.com/support/websearch/bin/request.py?contact_type=ip
>
>isn't of much help as it assumes the problem is google.com redirection.
>
>Are there any contacts at Youtube who could provide some assistance?

And received the following comments on and off list:

Carl Rosevear confirmed that he had experienced the same issue, and had
been attempting to work through the problem for some time.

Mike Schoenfeld suggested verifying the information at:
http://www.quova.com/what/request-ip-update/

Harry Strongburg posted that he had experienced similar problem over IPv6,
and suggested increasing MTU values as a possible fix.

Aaron Hopkins, Blake Hudson, and a private response, pointed towards DNS
resolution as being a possible problem.

I received private contact from a Google engineer requesting more
information.

The following test was used to confirm that the issue was indeed due to a
DNS resolution problem:

dig +trace v1.lscache1.c.youtube.com.
ping <returned IP>
traceroute <returned IP>

While the problem was happening, v1.lscache1.c.youtube.com resolved to an
address that was 129ms and 12 hops away from our network.

With the assistance of irc://irc.freenode.net/#bind, we instituted the
following temporary work around within our local resolvers, which provided
instant relief for our end-users:

zone "youtube.com" {
         type forward;
         forwarders { x.x.x.x; };
};

Where x.x.x.x is a geographically-near nameserver of one of our upstream
providers.

As of this morning, we have noticed that the problem has been resolved, and
we've removed the temporary workaround within our local resolvers. It took
approximately 2 weeks to achieve a resolution on this issue, which is
within the time frame indicated here:

http://www.google.com/support/websearch/bin/answer.py?hl=en&answer=873

After this fix, v1.lscache1.c.youtube.com is now resolving to an address
that's about 8ms and 6 hops away from our network.

I'd like to publicly thank those responsible for correcting this problem,
and for all those offering sympathy and tips for trouble shooting.

-- 
Dan White