Cox → [ALL] Youtube streaming fixed by switching to non-Cox DNS server

I've been having major problems with Youtube videos loading lately. I'd have to pause them and let them load for lengthy periods of time. Someone mentioned that he fixed that problem by using openDNS servers, so I tried it, even though it made no sense to me. It seems to have done the trick. Why is it working better, and what is the problem with Cox's DNS?

I run my own DNS servers at my home and still have issues with Youtube Videos loading. It may be that openDNS is resolving to a different server farm than you were before which would be in line with what we've been saying.

Yeah, and I was thinking that it was on my end.

If you want "Clean DNS servers" alternative to cox's, use 4.2.2.1 / 4.2.2.2 for no redirects!

As a followup, I also was having issues with youtube buffering all the time. However after changing the DNS to something else (opendns) the buffering ceased. Why would this change have this effect?
I am paying for the 15mb package, I should not have had any buffering in the 1st place.

I would imagine that YouTube is more than a single PC running out of somebody's basement That being said, by using a different DNS service the may resolve you to a different server in YouTube's server farm that is not affected by this performance issue. That being said, I don't believe this is a DNS issue but changing DNS providers gives you a random shot of reaching a YouTube server that is not having issues.

So what the heck can we do to ACTUALLY get a solution to this problem? Is there some way we can trick youtube's servers into routing us to different ones? I am tired of this crap. We can't exactly "contact youtube" about it. How would an issue like this even get raised? Maybe our friends at Cox could help us?

A sidenote, yeah it's not Cox's problem.. but if 100,000 of your customers start complaining it becomes your problem and is in your best interest to try and resolve it. Certainly isn't getting any quieter around here. :P

We've already attempted to contact YouTube and Google about this.

actually, cox is doing what they should...peer with the provider at the closest point possible for transit networking.

rather than understand what is working and why, people would rather just complain. while this could have been alleviated by some of the cox techs on here doing a quick name resolution using nslookup or dig (where were you bbeesley ?), i have decided to take this on to alleviate all of the whining!

now, this was done on one of my machines sitting behind my cox preferred connection in mesa arizona. i have no issues streaming any content whatsoever, and i'm not obsessed with the youtube so i never go there.

at any rate, here are my results:

With personal DNS server/4.2.2.2
--------------------------------
C:\Documents and Settings\tubbynet>nslookup
Default Server:  esx2k3-ad01.local.tubbynetworx.net
Address:  192.168.189.42

> www.youtube.com
Server:  esx2k3-ad01.local.tubbynetworx.net
Address:  192.168.189.42

Non-authoritative answer:
Name:    youtube.l.google.com
Address:  208.65.153.253
Aliases:  www.youtube.com

C:\Documents and Settings\tubbynet>nslookup
Default Server:  vnsc-bak.sys.gtei.net
Address:  4.2.2.2

> www.youtube.com
Server:  vnsc-bak.sys.gtei.net
Address:  4.2.2.2

Non-authoritative answer:
Name:    youtube.l.google.com
Address:  208.65.153.253
Aliases:  www.youtube.com

==========================================

With OpenDNS
-----------------------
C:\Documents and Settings\tubbynet>nslookup
Default Server:  resolver1.opendns.com
Address:  208.67.222.222

> www.youtube.com
Server:  resolver1.opendns.com
Address:  208.67.222.222

Non-authoritative answer:
Name:    www.youtube.com
Address:  208.67.216.132

============================================

With COX DNS
-----------------------
C:\Documents and Settings\tubbynet>nslookup
Default Server:  ns2.ph.cox.net
Address:  68.2.16.25

> www.youtube.com
Server:  ns2.ph.cox.net
Address:  68.2.16.25

Non-authoritative answer:
Name:    youtube.l.google.com
Address:  208.117.236.70
Aliases:  www.youtube.com

i have my own dns servers in my house. i have msdns running for my active directory domain and then i have a ubuntu server running the latest version of bind slaved to that. i have my forward and reverse lookup zones to local.tubbynetworx.net and everything outside of my domain is either directed towards root servers or stored in cache.

the top results are done when using my personal dns caching or using the level(3) any-casted 4.2.2.2
you can see they resolve to the same address (as they should since the any-cast and root servers try and narrow down your locality/as and direct traffic to the closest peering point [i know thats not *entirely* correct, but it serves to illustrate a point]).

now, you can see that if i use the opendns servers, i receive a different result than the anycast results. again, if i change to the cox servers, my result changes again.

now, this is what is being told you everyone complaining. it is not a cox problem, it is a cache/peer issue between cox and google, and if you resolve out to a different ip address, you will more than likely leave the cox transit network and hit the youtube cache engine that is peered with the isp of wherever the dns server is located.

lets do some research before we start kvetching people!

q.

I've been using alternate DNS servers (4.2.2.1 and 4.2.2.2) for months and I still have the problem.

If its some kind of peering problem, could Cox change the routes and offload to another partner as a "test" to see if the issue clears up?

it sounds logical, but more often than not it won't happen. i can't see any other provider with a peering location looking to take on the added stress of several million additional subs hitting their core infrastructure. i'm sure that cox *could* pay a transit provider (cogent, l(3), etc.) but it would add up and its more expensive than waiting on google to fix it.

i also should have been more clear in my explanation, just because you are getting a different ip address resolution for youtube, doesn't mean it will work. in my case, the 4.2.2.2 server and my local dns probably hop off the cox network at the same point, giving the same ip address for youtube.com. however, depending on where that ip address gets peered back to with cox will determine your path through the interwebs and to the youtube servers.

i'd have to spend a little more time looking at the routes and such and use my linux machines (since they provide udp pings rather than icmp, which is often deprioritized/blocked at most routers), but since i'm at work, it will have to wait until i get home and have some down time.

bill, at the risk of sounding repetitive, i would just say change your dns to opendns if you really need your youtube fix. redirects are annoying, but i believe if you sign up you can opt out (or just not fat-finger a url to begin with ).

q.

Well, I appreciate it. Thanks for trying at least Surely someone here can come up with some sort of workaround...... hmmmmm.....

HOSTS file?

lol.

That would actually work quite well if you knew the IP of a YouTube server that isn't experiencing issues.

I'm not that big of a YouTube junky, but when I want to view a 2 minute video I don't really want to wait 20 minutes for it to buffer. This has been ongoing for months, I just want to know what the problem is here. If its Google, then fine maybe its time to find an alternative.

It's Google who bought the youtube out and own it, If it is very busy of network traffic at time then it is Google issue. I researched that whois command that says Google owns youtube.com web site. If you still having issues with youtube then take your complains up with google.

Doubtful this slow youtube issue[yes ive had it too] is a dns issue. once dns gets the ip, that is it for the dns servers. there is congestion somewhere along the way.

thats really old news. google bought youtube what...two years ago...this is an issue that needs to be sorted between cox and youtube. but thanks as always for providing no useful information whatsoever. thanks for playing.

q.

Cox between and Google's youtube cannot be done to turn be help if issues of network traffic really exist of clogging within youtube web site of Google's stuff.

I'll take a look at this......

Based on the symptoms, I assumed YouTube would answer DNS queries with different ip addresses based on the location of the request. That would explain why changing DNS servers would make a difference. What I see instead is that all DNS queries get the same set of responses, no matter where they come from. Instead, YouTube announces those ip blocks from different locations. So a traceroute to 208.65.153.253 leads to a west coast data center for west coast customers, and it leads to an east coast data center (looks like Miami, FL) for east coast customers.

deafcon22, can you confirm by posting up nslookup and tracert information from your PC? First, change your DNS server back to Cox. Then go to Start -> Run, type in "cmd", and hit enter. When the DOS window appears, type these commands:

nslookup www.youtube.com

nslookup www.youtube.com 208.67.222.222

The output will look like what tubbynet pasted, e.g.

Non-authoritative answer:
Name: www.youtube.com
Address: 208.67.216.132

After you have the replies, please trace the route to each like so:

tracert -d ip address

E.g.

tracert -d 208.67.216.132

It looks like this from Atlanta:

Tracing route to youtube.l.google.com [208.117.236.74]
over a maximum of 30 hops:

...
6 2 ms 2 ms 2 ms 68.1.0.4
7 2 ms 2 ms 2 ms 68.1.0.29
8 3 ms 3 ms 3 ms 154.54.5.113
9 211 ms 58 ms 265 ms 154.54.5.38
10 117 ms 17 ms 206 ms 154.54.7.145
11 17 ms 17 ms 18 ms 154.54.24.234
12 31 ms 31 ms 31 ms 38.104.94.18
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 79 ms 79 ms 79 ms 208.117.236.74

68.1.0.29 is the last Cox router in the trace. We hand off to Cogent at 154.54.5.113, and that link looks great. Latency increases once the packets get into the Cogent network.

Its been slow for me on both Cox and opendns DNs servers. It seems to come and go. Fast one hour slow the next.

You folks are so focused on one thing... dns to www.youtube.com. If you bothered to look at the entire user session, you would notice that viewing a video doesn't come from www.youtube.com, it fetches from specific hosts not mentioned in this thread at all.... for me the place the actual bulk file (video stream) comes from is:

»v18.cache.googlevideo.com

I've also seen it say things like "nyc-v105.nyc.youtube.com"... and 5 other subdomains... and hundreds of other host-names.

How about you dig into your session and post some useful data about where your buffering bad stream is coming from? use tools like wget, curl, tcpdump... look for actual thruput... tcp retransmits... ping the hosts for packetloss... etc... find some common denominators... east coast, west coast only a certain range of hosts/ip's (on the google/youtube end) etc...

Dwelling on the TTL time of DNS for the first packet of the complicated session is misguided effort.

As an aside, I've noticed a huge icmp ttl range for possible video sources implying many many locations (colo's, cities, countries, etc)... but all the ip's that resolve from www.youtube.com are the same icmp ttl... implying one location where the web front end lives.

,Some Guy

Blazing speeds again as usual. Hey, I think I even edged out 128kbps ISDN! Time to find a new video site I guess.

Actually I think it is a Cox issue. The second I switched from DSL to Cox my problems with streaming video began... at Youtube and other sites.

It's so bad that even the ads fail a lot... (Very unusual-- normally the ads stream fine and the video you WANT to watch stalls so you have to reload and watch the ads again--- infuriating...) at least with Cox even the ads die.

Explain how that makes it not Cox's problem, however.

Cox Engineers and Google Engineers are in contact. We're working this......

That's very good news, thanks charterengr

Been getting worst the past 2 weeks here in the New England Market, havent saw it relaly before, just the past 2 weeks. Hopefully it is resolved soon, been having multiple ppl complain about it in RI and CT.