Pi-hole-Optimized-Blocklists publishes weekly-rebuilt, deduplicated DNS blocklists for Pi-hole deployments, merging 35 curated upstream feeds into category-specific lists for defenders and home-lab operators.
| Tool | zachlagden/Pi-hole-Optimized-Blocklists — pre-built, deduplicated Pi-hole blocklists merged from 35 curated sources, ~2.7M domains |
| Category | DNS filtering / defensive blocklist aggregation |
| Primary Use | Feeding Pi-hole gravity with maintained, deduplicated lists covering malicious, advertising, tracking, suspicious, and nsfw domains |
| Safe Use | Purely defensive: deploy on networks you own or administer (home labs, enterprise DNS resolvers) to block malware, phishing, ads, and trackers at resolution time |
| Telemetry Note | As a defensive allow/block asset it leaves no attack telemetry; from the defender's side, blocked hits appear in Pi-hole query logs and FTL statistics, and list freshness depends on the weekly GitHub Actions build |
zachlagden/Pi-hole-Optimized-Blocklists is a defensive infrastructure project rather than an offensive tool: it publishes pre-optimized, deduplicated domain blocklists designed to drop straight into a Pi-hole (or AdGuard-compatible) DNS resolver. The core value proposition is consolidation. Instead of an administrator wiring dozens of third-party feeds into Pi-hole individually — with duplicated entries, inconsistent formats, and overlapping licences — this repository runs a scheduled merge pipeline and ships eight finished lists, totalling roughly 2.69 million unique domains as of the October 25, 2026 build. The repo sits at 491 stars, is MIT-licensed on the main branch, and its topic tags (dns-blocking, hosts-file, pihole-blocklists, malware, phishing, tracking) accurately reflect a DNS-filtering asset.
The list taxonomy is the first thing to understand, because choosing the wrong file changes your false-positive profile dramatically. all_domains.txt is the maximalist option at 2,688,795 domains, combining every category except NSFW. malicious.txt is the heavyweight at 2,237,278 domains covering malware, phishing, and scam infrastructure. advertising.txt (271,119 domains), tracking.txt (18,081 domains, including vendor-native telemetry for Amazon, Apple, Samsung, Roku, TikTok, Xiaomi, and others via HaGeZi's native tracker feeds), and suspicious.txt (52,446 domains of potentially unwanted content) round out the security-adjacent categories. comprehensive.txt at 500,647 domains is the maintainer's recommended balanced entry point.
The NSFW handling shows genuine engineering care. nsfw.txt (530,875 domains) is deliberately excluded from all_domains.txt because it blocks legitimate adult sites rather than threats, so it must be opted into separately. The newer nsfw_abp.txt (498,830 domains) is an Adblock-plus-format variant using ||domain^ syntax, which blocks a domain and all of its subdomains — so cdn.example.com falls when example.com does. The line-count difference between the two files is not data loss: the optimizer strips subdomains already covered by a parent rule. The README is explicit that you should use one or the other, not both, and that ABP entries require Pi-hole Core ≥ 5.16 / FTL ≥ 5.22.
That version requirement deserves attention from operators running older resolvers. Pi-hole's ABP-style wildcard matching only landed in Core 5.16, and the README warns of a genuine operational gotcha: pihole -q will not enumerate the individual subdomains covered by an ABP entry, which matters when you're triaging why a client's lookup failed. If your incident-response workflow depends on pihole -q for root-cause analysis, factor that limitation into whether you adopt the ABP-format lists. Current installs ship the required versions by default since the 2023 releases.
Integration is deliberately trivial, and this is one of the two invocation examples worth citing. In Pi-hole v6 you open Lists in the admin interface (or Group Management → Adlists in v5), paste the raw media URL for each list you want, and run pihole -g or use Tools → Update Gravity to pull them into the gravity database. That's the entire deployment story — no agents, no packages, no daemon. The lists are served from media.githubusercontent.com raw endpoints, which means updates ride the standard gravity refresh cycle you've already configured.
The upstream supply chain is the most interesting analytical layer here. The build is configured in blocklists.conf, which references 35 lists from well-known sources: HaGeZi (Pro, Threat Intelligence Feeds, Fake, DynDNS, Pop-Up Ads, native trackers), OISD Big, 1Hosts Lite, AdAway, Peter Lowe's ad-server list, anudeepND, the AdGuard DNS filter, Frogeye first-party trackers, Perflyst smart-TV tracking, URLhaus from abuse.ch, Phishing Army, stalkerware indicators from AssoEchap, DandelionSprout, malware-filter, Spam404, ShadowWhisperer, UT1 cryptojacking blacklists via Firebog, KADhosts, and StevenBlack's porn-only variant. Threat-intel heavyweights like URLhaus give malicious.txt genuine defensive weight — this is not just an ad-block list wearing a security costume.
Licensing discipline is another signal of maturity. Each upstream list retains its own licence, documented per-source in the README — GPL-3.0 for HaGeZi and OISD, MPL-2.0 for 1Hosts, CC BY-NC for Phishing Army, abuse.ch terms for URLhaus, and a no-commercial-use clause on Peter Lowe's list. Anyone planning to redistribute or commercially embed these merged outputs should read that table carefully; the repo's own MIT licence covers only the build tooling and community additions in custom/. This per-source licence preservation is the kind of detail that separates a maintainable aggregation project from a licence-compliance headache.
The community-reporting loop is where the project earns its "optimized" label. Domains reported via GitHub issues land in custom/<category>.txt files, which blocklists.conf references as raw-URL sources, so the optimizer ingests them exactly like upstream feeds on the next build. Issue templates exist for block requests, false positives, and bugs, and a bot posts an evidence report on every issue before the maintainer makes the final call — a human-in-the-loop design that resists both griefing and hostile list poisoning. Accepted changes take effect at the next weekly update.
The update cadence is a scheduled GitHub Actions run at 00:00 UTC every Sunday, with the README candidly noting GitHub frequently starts scheduled builds hours late. That weekly rhythm defines your threat-coverage lag: a fresh phishing domain reported Sunday evening may not be blocked until the following week's gravity pull. For defenders treating Pi-hole as a compensating control against phishing, that latency is a known limitation to document — DNS blocklists are breadth, not immediacy, and should sit alongside faster detection paths. Community-reported domains merged before the run are included in that build.
The maintainer also operates a companion platform, Zach's Lists, which adds custom source selection, regex and wildcard smart whitelisting, multiple output formats (hosts, plain, ABP), and real-time build progress. The FAQ confirms both projects share the same underlying sources and maintainer, so the GitHub repo is best understood as the static, zero-dependency distribution channel — you consume finished artifacts — while the hosted platform serves users who want composability. For a security team, the static repo is the lower-trust-boundary option since everything is auditable in git history.
Where this fits in an authorized workflow is straightforward: it is defensive DNS filtering for networks you own or administer — home labs, small-business resolvers, lab segments behind a Pi-hole instance. The category split lets you tune aggressiveness per environment: malicious.txt and tracking.txt are low-collateral in most enterprise contexts, while all_domains.txt is flagged by the FAQ itself as likely to cause false positives. The false-positive reporting template is your remediation path when a legitimate vendor domain gets caught, and the evidence-bot process means disputed entries come with justification.
Operationally, the main watch-items are three: the weekly staleness window between a domain's appearance in upstream feeds and its arrival in your gravity database; the pihole -q blind spot on ABP-covered subdomains; and the inherent trust you place in 35 upstream maintainers, mediated by one aggregator. Weigh those against the significant operational win — a single, deduplicated, licence-documented, human-reviewed set of lists that turns Pi-hole from a hobby ad-blocker into a credible lightweight DNS security layer — and the project earns its place in a defender's toolkit.
zachlagden/Pi-hole-Optimized-Blocklists.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.