found the issue - this command worked: sh -c "$(curl -sL https://nextdns.io/install)"
this one didn't: sh -c 'sh -c "$(curl -sL https://nextdns.io/install)"'
I guess the install commands changed recently on github - everything seems ok now.
It's been a busy four days for me since I found out about that trick. And now Diversion is the first router based ad-blocker that has a fully automated working solution to block YouTube video ads.@Olivier Poitrey Would this be something you guys could do on NextDNS as well?
https://discourse.pi-hole.net/t/youtube-script-seems-to-be-working-very-well/31316
See post 6000 and up in the Diversion topic on this forum where @thelonelycoder is doing an awesome job of implementing this in his ad-blocking tool.
@Olivier Poitrey Would this be something you guys could do on NextDNS as well?
https://discourse.pi-hole.net/t/youtube-script-seems-to-be-working-very-well/31316
See post 6000 and up in the Diversion topic on this forum where @thelonelycoder is doing an awesome job of implementing this in his ad-blocking tool.
It's been a busy four days for me since I found out about that trick. And now Diversion is the first router based ad-blocker that has a fully automated working solution to block YouTube video ads.
Not even Pi-Hole has that automated setup.
Ha!
Thank you for your analysis.
I’ll keep an eye on the Diversion forum to see which experiences people post there.
The people in the Pi-hole forum thread and Reddit post are reporting excellent results.
The script does not block IPs or hostnames.
(I wrote the original script based on a hunch I had after analyzing too many network dumps.)
By replacing the IP of those hostnames by the one of another, it creates 400 errors. So IT IS equivalent to blocking.
You can do the test yourself. In chrome, take one of those video request in the network tab, right click and copy the curl command. You can execute it and see that you get the video data. Now add the —resolve <hostname of the URL>:443:<fix IP> argument. You will get either a 400 error. This is exactly what this script is doing.
Do a tcpdump of the network traffic, you will see the video data still flows when this runs. Now I'm not sure how Google is doing their distribution (likely some Anycast funkiness and tracking to ensure the video flows from whatever IP, it's a black box really and that's a guess) When I first tested this, the query would go out but when the forced IP was returned, the packets kept coming.
Did you actually test the thing out?
Yes I tested it, and performed some comparison tests too and tried many different approaches.
By replacing the IP of those hostnames by the one of another, it creates 400 errors. So IT IS equivalent to blocking.
You can do the test yourself. In chrome, take one of those video request in the network tab, right click and copy the curl command. You can execute it and see that you get the video data. Now add the —resolve <hostname of the URL>:443:<fix IP> argument. You will get either a 400 error. This is exactly what this script is doing.
Did you have fewer ads?
As far as I can see/test this script is not replacing the hostnames IP nor blocking it. That's exactly why a nslookup on one of the GoogleVideo subdomains is a prerequisite for the setup. What this script is doing it simply gives out the fixed local YouTube CDN IP whenever there is a Googlevideo subdomains DNS query thus avoiding the second pre adroll IP DNS lookup.
I can see this breaks YouTube in only one case when the local YouTube CDN edge node changes the IP thus invalidating our forced IP setup.
Note: I haven't tested this thoroughly so my assumption can be wrong, in any case, we'll see how it goes in the next few weeks.
As you can see, such solution would block twice as more content than ads.
The script is creating a hosts file with all the googlevideo.com hostname found in the logs from you past history, and force them to resolve to a single arbitrary IP got from one of them. So, yes it is replacing the IP of those hostnames by the a fixed IP.
The way those servers are programmed, such manipulation of the IP will make those requests fail, which is equivalent to a blocking. And if it was not blocking, I don't see how it could have any effect on ads, as ads and contents are stored indifferently on those servers.
Well in my case the Arbitrary IP is from the local YouTube Egde node in my ISP and I haven't seen any fail video playbacks so far, the way CDNs work, they are connected to all other nodes over the network and if they don't have the requested video in the cache, they'll fetch it over the network so I still don't see how it'll fail to work even if we're using a single CDN IP.
As far as I can tell, the way this works is YouTube always do a DNS query before the ad roll and that gives a different IP then the original answer we get in the start and this method basically just blocks YouTube from that pre ad roll lookup and forced it to keep playing on the actual content.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!