RPiList/specials: Pi-hole Blocklists and Anti-Blocklists

The network filtering problem addressed by RPiList/specials

RPiList/specials targets networks that already use Pi-hole and need centralized DNS filtering for more than one connected device. Its README says the lists are intended to protect other users on the same network from suspicious online shops, advertising, tracking, and other attacks arriving over the internet. That framing places the project at the network boundary rather than in an individual browser. A policy imported into Pi-hole can therefore affect DNS clients throughout the local network, depending on how those clients use Pi-hole.

The intended audience is therefore the operator of a Raspberry Pi or other Pi-hole deployment, not an application developer looking for a Python library. The repository has no package index entry, CLI reference, or documented Python API in the README. Its primary language is Python, but its visible product is a collection of network-filtering resources rather than a documented software installation.

The project also maintains lists aimed at the opposite operation. An anti-blocklist permits selected domains that a shared blocklist would otherwise block. The README gives a concrete example involving a payment service used by suspected scammers and also by Austrian Post. Importing an anti-blocklist can preserve access to that payment service, while manually allowing its domain is presented as the alternative. This is a coarse DNS policy model: a shared domain can have legitimate and unwanted uses, and a domain-level exception cannot distinguish the two.

How Pi-hole consumes the repository's blocklists

The documented data flow is subscription based. A network administrator selects a URL from Blocklisten.md, adds that URL to Pi-hole, and allows Pi-hole to fetch and apply the referenced list. The README does not document an application programming interface, database migration, or Python entry point for this process. Pi-hole performs the filtering, while RPiList/specials supplies the list content.

The repository layout shows several destinations for that content. Blocklisten/ and Anti-Blocklisten/ correspond directly to the two filtering directions discussed in the README. Other directories, including DNSMASQ/, Mikrotik-Hosts/, SpamCatcher/, Bad-IP/, and Unbound.md, indicate resources or formats for other DNS and filtering configurations, although the README does not explain their update procedures. Converter/ contains converter-related material, while MegaList.py and MegaList-ABP.py are present at repository level. Their exact behavior cannot be confirmed from the README.

The current format warning matters to compatibility. The README states that Pi-hole FTL v5.22, Web v5.19, and Core v5.16.1 introduced support for a new ABP-style format. Some project lists were converted to that format. A Pi-hole version that predates the documented format support may stop applying affected subscriptions, so format support is a deployment requirement rather than a minor implementation detail.

Importing lists into an existing Pi-hole

The README assumes that Pi-hole is already installed and points administrators to Blocklisten.md for the repository's lists and a selection of third-party lists. It does not give installation commands for Pi-hole, operating systems, DNS ports, or individual list URLs. Because the exact subscription URLs are not included in the README, an operator should copy them from Blocklisten.md rather than reconstruct them.

Before using the lists, review the selected entry in that file. The README also says that users may contribute suspicious-shop URLs by emailing [email protected] or opening a GitHub issue. It does not document a moderation policy, review checklist, dispute process, or removal procedure, so list membership should not be treated as formally verified evidence of malicious activity.

If Pi-hole cannot use the ABP-style subscriptions, the README gives this update command:

pihole -up

The command updates Pi-hole. It does not explicitly update the host operating system or modify the selected blocklist, and the README only says it may be needed for Pi-hole versions that lack support for the new list format. Do not use the command as a substitute for reviewing the affected list.

Shared list maintenance and evidence limits

The repository is not archived, and its last push was on 2026-10-16. That supports describing the repository as recently pushed, but it does not establish how individual lists are reviewed or how quickly harmful entries are removed. The repository has no GitHub releases, so there is no documented release channel through which administrators can identify a reviewed version of every list.

This is the central adoption concern. A DNS subscription is executable configuration from the administrator's perspective: it can change the resolution behavior of many clients without a software deployment. The repository offers community contribution routes, but the README does not say who validates submissions, whether domains are rechecked after addition, or whether stale entries expire automatically. It also does not identify the cadence at which blocklist URLs are republished.

The README links to Copyright - Woher kommen unsere Listen.md and Bad-IP/, but it does not summarize their content. Those locations may help with provenance or additional address lists, yet an operator should inspect them directly. The documented repository layout supports a broad collection of resources, not a single coherent upstream feed with a common verification standard.

Anti-blocklists and the cost of false exceptions

Anti-blocklists address a practical weakness in domain-based blocking. If a suspicious shop and a legitimate postal service use the same third-party payment domain, blocking that domain affects both. The README calls this the reason for the existence of anti-blocklists. Importing the matching exception list or allowing the domain manually restores access without requiring every user to bypass Pi-hole locally.

That solution also shifts responsibility back to the network operator. The README does not explain how narrowly the Austrian Post exception is expressed, whether exceptions are grouped by service, or whether later exceptions use a different mechanism. An exception broad enough to restore one legitimate workflow can also restore traffic to the unwanted service because both parties share the same parent domain.

For a home network, the trade-off may be manageable when the administrator knows the affected service. For shared offices, schools, or managed environments, importing an unknown exception changes policy for every client. The README mentions allowing a domain by hand but does not give the command or interface steps for doing so.

Alternative approaches to shared DNS filtering

A real alternative is to keep DNS policy local rather than import this repository's shared lists. An administrator can use the individual URLs mentioned in the README as reported candidates, verify each one, and add only reviewed entries to an existing Pi-hole configuration. The documented alternative within this repository is also to allow a legitimate domain manually. Both approaches reduce reliance on an opaque shared subscription, at the cost of requiring ongoing administrator review.

Another alternative is manual DNS filtering through the Pi-hole interface, although the README does not describe that interface. The difference is operational. Repository subscriptions automate list updates and can cover advertising, tracking, suspicious shops, and other attack categories in one selection. Local entries are slower to distribute and maintain, but their scope and source can be documented by the network owner.

The repository also contains resources associated with other routing or DNS systems. Their existence does not prove compatibility, because the README does not explain whether every entry is current or independently maintained. Choosing one of those files requires checking its own format and destination rather than assuming that the Pi-hole instructions apply to all repository content.

Licensing, upgrades, and operational ownership

The repository is marked with a custom LICENSE.md that GitHub cannot classify. The README does not summarize the permissions, restrictions, redistribution conditions, or attribution duties. No legal interpretation should be inferred from the repository's file names. An organization considering shared or modified lists should read LICENSE.md and retain a local record of the list revision and source URL used in Pi-hole.

Upgrades also have two distinct parts. The `pihole -up` command addresses the documented compatibility problem with ABP-style list support. Updating the remote subscription addresses changes filtering content. The README does not document rollback, pinning a list to a commit, reviewing a diff before refresh, or disabling a newly added blocklist entry. Those omissions do not prove that Pi-hole lacks corresponding controls, but this repository does not explain them.

This makes RPiList/specials operationally lightweight only for administrators prepared to own list review. The network owner remains responsible for deciding which URLs are imported, whether an anti-blocklist is justified, and what happens after a bad subscription update. That responsibility matters because the repository's purpose is to apply shared policy across a network.

Editorial conclusion

RPiList/specials is appropriate for a Pi-hole administrator who accepts community-submitted URL lists and will inspect the referenced files before deployment. It is a poor fit for a network that requires documented list provenance, a formal release process, or a tested rollback procedure. Check Blocklisten.md first, confirm that every referenced URL is reachable, and review LICENSE.md before copying any list into a production network.

Frequently asked questions

Official sources

1. Issues
2. README
3. RPiList/specials on GitHub