youTube_ads_4_pi-hole: A DNS Blocklist for YouTube Ads on Pi-hole, AdGuard Home and pfBlockerNG

The problem: YouTube ads survive ordinary DNS blocklists

Most Pi-hole users start with the default StevenBlack hosts list, then notice that YouTube still plays pre-roll ads. The README names the reason directly: the default blocklist blocks s.youtube.com, which breaks video playback, so people allow it again and lose whatever ad blocking that domain provided. The two goals conflict, and the default list resolves the conflict in favour of playback.

This project takes the opposite position. It maintains a separate list of YouTube ad-serving hostnames, excludes the ones that break playback through an ignore.list, and publishes the result as a single URL. The README states the list holds 15,901 domains as of Sept 21st 2026 and works with Pi-hole v5 and v6, AdGuard Home, pfBlockerNG, Technitium and other DNS blockers that accept a hosts-style domain list.

The audience is narrow and specific: people who already run a network-level DNS blocker and want YouTube ad hostnames blocked for every device on the network without installing anything per device. Smart TVs, consoles and phones are the cases the README calls out, because those are the devices where browser extensions and client-side blockers do not reach.

How the list and the script work together

There are two artefacts and one optional script. youtubelist.txt is the published list: plain hostnames, one per line, already filtered so that everything matching ignore.list is removed. black.list is the unfiltered source list in the repository. ignore.list holds the never-block entries, and the README says you can add your own entries to a local ignore.list next to the script, one per line, either a full hostname or just a fragment such as n4v7sne7. Those local entries are merged with the repository copy on every run.

Option 1 uses none of the script. You paste the raw.githubusercontent.com URL into the Pi-hole interface and Pi-hole downloads the list itself on every gravity update, weekly by default. Option 2 runs youtube.sh, which downloads black.list, drops everything matching ignore.list, adds only the domains your Pi-hole does not already have, and reloads Pi-hole's lists. The README notes the first run takes a few minutes and later runs finish in seconds, because the script diffs against what is already present.

There is a third data path worth knowing about. The script prints a line about sharing googlevideo.com hostnames from your query log, and there is a --no-share flag to disable it. The README's privacy section is referenced from the options table but not reproduced in the visible portion, so the exact contents of what is shared and where it goes are not documented in the repository files listed here. That is a gap, not a hidden feature.

Installing the list in Pi-hole and running a first gravity update

The recommended route needs no installation at all. In the Pi-hole web interface, open Lists on v6 or Group Management then Adlists on v5, paste the address below into the Address field, and click Add. The README gives exactly this URL.

https://raw.githubusercontent.com/kboghdady/youTube_ads_4_pi-hole/refs/heads/master/youtubelist.txt

After adding it, update gravity so the list takes effect. From the terminal that is one command, and the README notes Pi-hole re-downloads the list on every gravity update, weekly by default.

pihole -g

If you already run Pi-hole's default blocklist, the README warns that it blocks s.youtube.com and breaks playback. Allow that hostname once, using the command for your version.

pihole allow s.youtube.com      # Pi-hole v6
pihole -w s.youtube.com         # Pi-hole v5

For the script route, clone the repository and run youtube.sh with sudo. The README says the script re-runs itself with sudo if you forget, and that it needs nothing beyond what Pi-hole already installs.

git clone https://github.com/kboghdady/youTube_ads_4_pi-hole.git
cd youTube_ads_4_pi-hole
sudo ./youtube.sh

The README shows the expected output: a download line, a count of domains in the list, a count skipped because of ignore.list, a progress line, an added count, a reload line, and a final line reporting how many domains Pi-hole is now blocking. If you want to see what would change before touching anything, the --dry-run option shows the diff without modifying Pi-hole. To keep the script running hourly, add it to root's crontab.

0 * * * * /home/pi/youTube_ads_4_pi-hole/youtube.sh > /dev/null 2>&1

The README points to crontab.guru for schedule syntax if hourly is not what you want.

What DNS blocking cannot do to a YouTube ad

The README's own section is titled What it does and doesn't do, and the honest reading is that the does column is about DNS lookups, not about ads. Blocking a hostname stops the device from resolving it. If the ad is served from the same hostname as the video stream, DNS blocking cannot separate them, and this is the structural ceiling of the approach rather than a defect in this particular list.

The README claims it stops many pre-roll and mid-roll video ads from loading, and the word many is doing real work there. Anyone who expects a clean YouTube experience on a smart TV should calibrate against that. The list also changes: hostnames get added, removed and rotated, which is why the README recommends a weekly gravity update and offers hourly cron as an alternative. A stale list degrades quietly, with no error message, just ads returning.

The second failure mode is playback breakage. The ignore.list exists precisely because some YouTube hostnames must resolve for videos to play, and the README repeats the warning across the Pi-hole section and the other-blockers table: keep s.youtube.com and the ignore.list hostnames allowed. If you block aggressively and add your own ignore entries carelessly, you get the classic symptom of a video that buffers forever. The README's troubleshooting section is listed in the table of contents but its contents are not visible in the README text available here.

AdGuard Home, pfBlockerNG, Technitium, Blocky and OPNsense Unbound

The list is not Pi-hole-specific. youtubelist.txt is plain hostnames, one per line, and the README says it works with any DNS-level ad blocker that can subscribe to a domain list. The same raw.githubusercontent.com URL is used everywhere, which means one list to keep current across a mixed network.

The README gives the location for each: AdGuard Home under Filters, then DNS blocklists, then Add blocklist, then Add a custom list. pfBlockerNG on pfSense under Firewall, then pfBlockerNG, then DNSBL, then DNSBL Groups, adding a feed with the URL and format Auto. Technitium under Settings, then Blocking, then Block List URLs. Blocky under blocking.denylists in config.yml. OPNsense Unbound under Services, then Unbound DNS, then Blocklist, as a custom blocklist URL.

Two things are worth flagging. First, format Auto in pfBlockerNG matters, because a wrong format selection is a common way to end up with an empty group and no obvious error. Second, the ignore.list warning applies to every one of these platforms. If you subscribe to the list but do not allow s.youtube.com and the ignore entries, you will break playback on AdGuard Home exactly as you would on Pi-hole. The README states this once in the Pi-hole section and once in the other-blockers section, which is appropriate given how easy it is to miss.

Alternatives: client-side blockers and the crowd list

The obvious alternative for desktop browsers is uBlock Origin or a similar extension. The difference in approach is architectural: a browser extension sees the page and can remove ad elements after the request is made, while this project prevents the DNS lookup entirely. That gives the list reach across devices a browser extension cannot touch, and costs it precision, because it cannot distinguish an ad request from a video request on the same hostname. If your problem is a laptop browser, the extension is the better tool. If your problem is a smart TV, the extension does not exist and the DNS list is the only option of the two.

Within the project there is a second choice. The README describes an optional crowd list, enabled with the --crowd flag, which blocks an unfiltered set of domains contributed by users. The distinction that matters: the default list is filtered through ignore.list so playback keeps working, while the crowd list is described as unfiltered. Running --crowd trades some playback safety for broader blocking. The README does not state what review, if any, crowd submissions receive, so treat the flag as a deliberate loosening of the safety margin rather than a strict improvement.

Maintenance, licence and what to check before relying on it

The repository is not archived, and the last push was on 2026-09-21, which is recent. The README states the list is updated daily and the badge text reports Sept 21st 2026 with 15,901 domains. The update.ps1 script mentioned in an HTML comment inside the README rewrites the date automatically, which suggests the badge is generated rather than edited by hand.

On cost: if you use Option 1, your only maintenance is the gravity schedule Pi-hole already runs, plus an occasional pihole -g when you want the latest list sooner. If you use Option 2, you own a cron entry and a cloned directory, and the README notes later runs finish in seconds because the script only adds what is missing. Neither path requires a daemon or a service file. The heavier cost is diagnostic: when something breaks, you need to determine whether a newly blocked hostname is responsible, and the README's troubleshooting section is the place that would answer it.

The licence field is not specified in the repository metadata, so there is no licence identifier to quote here. The README asks for support through PayPal and Buy Me A Coffee rather than stating terms. If you plan to redistribute the list or bundle it into a product, the absence of a stated licence is something to resolve with the maintainer directly; this is not legal advice, just a note that the terms are not published in the repository files listed here.

Before committing, verify three things: that your blocker accepts a hosts-style domain list, that s.youtube.com is allowed on every blocker you run, and that the raw.githubusercontent.com URL is reachable from the machine that fetches it. A DNS blocker with no outbound access to that host will silently subscribe to nothing.

Editorial conclusion

Adopt it if you already run Pi-hole, AdGuard Home, pfBlockerNG, Technitium, Blocky or OPNsense Unbound and want one URL to subscribe to; the README reports 15,901 domains as of Sept 21st 2026 and the last push was on 2026-09-21. Do not adopt it if you expect DNS filtering to remove every ad, or if you cannot allow s.youtube.com and the ignore.list hostnames. Verify first that your blocker accepts a hosts-style domain list, that s.youtube.com is allowed, and that the raw.githubusercontent.com URL resolves from the machine running gravity.

Frequently asked questions

Official sources

1. Issues
2. kboghdady/youTube_ads_4_pi-hole on GitHub
3. Project website
4. README