All I said, if you read back, was that in attempting a dig on youtube at 8.8.8.8, as proposed to use by L1HD, it gave the same result as the TCL dns.

I said this suggested to me that port 53 traffic was is being bounced at the TCL DNS array rather than being allowed to travel directly.

This isn't some stupid TFH conspiracy, it's just a bit of really common sense logic.

We already know that every packet is inspected somewhere to pick out the traffic that's local .nz to route in the right direction.

We know that port 80 traffic that's international (which most people know is about 80 to 95% of traffic) is redirected though the international caches where it's inspected to see if it's an HTTP request for something already held locally.

We know that some providers use DPI to manage torrent traffic in their networks.

We know that some providers use DNS management to provide a clean feed solution for customers.

It's not stupid TFH theory, it's just simply observation of normal every day networking stuff that goes on in the internet all over the world.

I went on to say that if port 53 management is being used then systems like OpenDNS won't work. Nothing TFH there, just simple fact that it might not work depending on what is or isn't being done.

Fact is that L1HD told me I should use 8.8.8.8 NS to help prove out this annoying issue with YouTube. Why exactly I did not understand at all after I did a dig and found it resolves the same IP addresses.

End of the day, TFH or a good bout of paranoid delusion for which one should take a strong dose of the right medication, I don't really care.

I would kinda like to understand why L1HD said use to googles DNS when we rant on and on and on here about using TCL's DNS.

I would like to know why Googles DNS resolves the same IP range, and yes, I hadn't considered that Google might be seeing the request coming from this IP range and just giving back the cache farm addresses, in which case why bother when the addresses are already in the TCL NS servers?!

End of the day all I really really really care about is the stupid YouTube system just working to a level that it doesn't 'buffer' when my wife is trying to get an education in specialist crafting techniques from training courses that she pays a great deal of money to access from the USA, and... doesn't bother me that her internet connection isn't working when we use a premium service that I pay a premium amount of money for it while at the same time not using Telecom (who frankly, and thanks Pete for your off line help) have been the most helpful so far in figuring out a work around!

A standard traceroute, a UDP port 53 traceroute, and a TCP traceroute on 53 and 25, to one of my servers, from my T/Clear cable are all identical.

Also tested against 8.8.8.8 with similar results (but it wasn't so happy about probing 25), it exits T/Clear network at i-0-4-0-1.tlot02.bi.telstraglobal.net and transitions straight into Google IP space at 72.14.197.53

There is no hijacking of DNS queries that I see.

As for why support told you to use 8.8.8.8, well, support monkeys are typically not the smartest cookies in the jar.

sleemanj: Also tested against 8.8.8.8 with similar results (but it wasn't so happy about probing 25), it exits T/Clear network at i-0-4-0-1.tlot02.bi.telstraglobal.net and transitions straight into Google IP space at 72.14.197.53

I'm not hitting 72.14.197.x which is what I would have expected to see, but perhaps I just didn't drive the dig command correctly?

;; ANSWER SECTION:www.youtube.com. 43199 IN CNAME youtube-ui.l.google.com.youtube-ui.l.google.com. 299 IN A 203.97.30.163youtube-ui.l.google.com. 299 IN A 203.97.30.152youtube-ui.l.google.com. 299 IN A 203.97.30.174youtube-ui.l.google.com. 299 IN A 203.97.30.144youtube-ui.l.google.com. 299 IN A 203.97.30.165youtube-ui.l.google.com. 299 IN A 203.97.30.181youtube-ui.l.google.com. 299 IN A 203.97.30.159youtube-ui.l.google.com. 299 IN A 203.97.30.177youtube-ui.l.google.com. 299 IN A 203.97.30.154youtube-ui.l.google.com. 299 IN A 203.97.30.185youtube-ui.l.google.com. 299 IN A 203.97.30.155youtube-ui.l.google.com. 299 IN A 203.97.30.148youtube-ui.l.google.com. 299 IN A 203.97.30.166youtube-ui.l.google.com. 299 IN A 203.97.30.170youtube-ui.l.google.com. 299 IN A 203.97.30.187youtube-ui.l.google.com. 299 IN A 203.97.30.176

DonGould: I'm not hitting 72.14.197.x which is what I would have expected to see, but perhaps I just didn't drive the dig command correctly?

One would assume that Google checks the IP of the requester (you) to see where the nearest appropriate cache servers to send them to are (T/Clear's in this case). That's pretty much how a content delivery network works.

sleemanj: One would assume that Google checks the IP of the requester (you) to see where the nearest appropriate cache servers to send them to are (T/Clear's in this case). That's pretty much how a content delivery network works.

Yes, exactly what I also commented on.

However it still doesn't explain why the HD said use 8.8.8.8 as, while it might (or not in this case) change the addresses for Google/YouTube, it would/could then break access to any other CDNs.

Aside, I have been told that someone has looked at the cache and should have made some improvement, which is good.

Pete from Telecom was very helpful, he just suggested using the Telecom cache as a work around to see if that's more stable and sent me a work around to gain access for the wifes machine, but his workaround might break if they change something at their end in the future.

Really the answer is that Google and Telstra ensure that what ever service they're delivering actually works properly.

It raises the question in my mind about Google/ISP relationships. And before someone jumps on me for the TFH theory... get off, I know I give better attention to others who work with me to build relationships, and everyone I know is just the same.

It will be interesting to see if others are still having problems.

Given the number of comments here, it can't be that many at all because we haven't really been indated with others saying 'me too'.

Just tried watching a Muppets video with the kids - took about 15 minutes to watch a 4 minute long video in 480p resolution. I can't be bothered reading this whole thread - is TCL taking responsibility for it, or are they once again ignoring it? I'm on a Warpspeed connection, with an ethernet cable, with the correct DNS servers, etc...

Just tried watching a Muppets video with the kids - took about 15 minutes to watch a 4 minute long video in 480p resolution. I can't be bothered reading this whole thread - is TCL taking responsibility for it, or are they once again ignoring it? I'm on a Warpspeed connection, with an ethernet cable, with the correct DNS servers, etc...

Link: http://www.youtube.com/watch?v=IlxozJh2JN

The shame of it all is that this works fine for me. But I understand your frustration. It should just work, without complication, randomness or intermittent performance.

amanzi: Just tried watching a Muppets video with the kids - took about 15 minutes to watch a 4 minute long video in 480p resolution. I can't be bothered reading this whole thread - is TCL taking responsibility for it, or are they once again ignoring it? I'm on a Warpspeed connection, with an ethernet cable, with the correct DNS servers, etc...

Link: http://www.youtube.com/watch?v=IlxozJh2JNo

It wouldnt be so bad if it just downloaded slowly but steadily as you could come back to it after it had completed and watch without interruption but with me it just stops and you have to move the slider back and forth for the video to resume. Unfortunately once you move the slider it takes 20secs or so to resume and its not at the point where you left off so I find myself watching the same thing again or missing sections.

Really frustrating especially for my thai wife who likes to watch thai tv programs on youtube and I cop it in the ear as she just gets so annoyed and keeps mutteering about internet in her rural hometown in thailand being faster then ours in Auckland city (oh and cheap and Unlimited !!! )

amanzi: Just tried watching a Muppets video with the kids - took about 15 minutes to watch a 4 minute long video in 480p resolution. I can't be bothered reading this whole thread - is TCL taking responsibility for it, or are they once again ignoring it? I'm on a Warpspeed connection, with an ethernet cable, with the correct DNS servers, etc...

Link: http://www.youtube.com/watch?v=IlxozJh2JNo

It wouldnt be so bad if it just downloaded slowly but steadily as you could come back to it after it had completed and watch without interruption but with me it just stops and you have to move the slider back and forth for the video to resume. Unfortunately once you move the slider it takes 20secs or so to resume and its not at the point where you left off so I find myself watching the same thing again or missing sections.

Really frustrating especially for my thai wife who likes to watch thai tv programs on youtube and I cop it in the ear as she just gets so annoyed and keeps mutteering about internet in her rural hometown in thailand being faster then ours in Auckland city (oh and cheap and Unlimited !!! )

Anyway I hope too for some resolution :)

You Tube here (Wellington central) is working as it should, ever since Telstra Clear said they had logged the problem with You Tube.