DNS Could Block the Ad Request, Not the Ad
I tried to block YouTube ads for my whole network with a DNS list. Most of the plumbing worked. The ads kept playing, and the logs showed why.
I wanted YouTube ads gone for every device in the house without installing anything on any of them. My network already sends DNS through NextDNS, and there's a maintained community blocklist of about 15,900 hostnames that serve YouTube ads. Load the list, done. That was the plan, and about half of it held up.
The first obstacle was mechanical. NextDNS can't import a blocklist by URL, so the only way in is its API. A bulk replace of the denylist worked at 1,500 entries and failed with a server error at 1,750. Single adds weren't subject to that cap, only to a rate limit of 60 writes a minute, so I wrote a sync script that adds entries one at a time. At roughly 55 a minute, the full list takes about 4.5 hours. Slow, but boring, which is what I wanted.
It then died at 7,250 entries. One dropped connection killed the script because I'd only handled HTTP errors, not timeouts. The monitor I'd set up reported it correctly, but I read the notification late, so some time was lost. The fix was a 30-second retry on connection errors. Nothing was lost since the script skips entries that already exist, but it's the kind of failure that's obvious only after you've watched it happen.
Before trusting any of it, I checked whether the network was really using NextDNS. I assumed it was. My UniFi API key turned out to be valid but linked to no consoles, so I read the router settings in the browser instead. The WAN had manual DNS set to NextDNS addresses, and a blocked hostname resolved to 0.0.0.0 against both NextDNS and the gateway while youtube.com resolved normally. The assumption was right, but now it was a measurement.
Early results looked great. I watched six videos on my phone and saw no ads. The sample was too small to mean much, and the assistant said so at the time: some of those blocks came from a general ad list that was already on, and YouTube doesn't show an ad on every video anyway.
So I ran a better test on a TV running the stock YouTube app. I labeled each video as an ad or clean by hand and pulled the DNS logs for the same moments. Six ads, eight clean starts. In three of the six ads, a cluster of ad-request hosts (doubleclick, googlesyndication) was blocked in the same second. That cluster never appeared in a clean video. Blocking worked exactly as designed. The ads played anyway.
The logs explain why. When the app asks the ad servers for an ad and gets nothing back, it falls back to ads stitched into the video stream on Google's side. Those come from the same googlevideo.com hosts that serve the content itself, and the same server names showed up in both ads and clean videos. Block them and the video breaks too. Three of the six ads left no distinguishing trace in DNS at all. I briefly chased one odd-looking host pattern, found it in two of six ads, and dropped it.
I haven't deployed the Cloudflare Worker I wrote to keep the list fresh daily. After this result, it would keep a list current that can't do the whole job. The one real finding is narrower: DNS filtering removes the ad request, and nothing more.
What generalizes is how long I was willing to believe a good-looking number. Six ad-free videos felt like success. The labeled test, with ads and clean videos logged side by side, was the first time the data could have said no, and it did. If you can only observe a system when it's working, you haven't tested it yet.