1Hosts: one blocklist, ten file formats, and a false-positive decision

Two lists, and the one that will cost you a Sunday

1Hosts ships two variants and the difference between them is not depth of blocking, it is who is willing to debug DNS.

Lite is described as the balanced version, set and forget, prioritising a smooth experience and ideal for general users. The README positions it for beginners, families and casual browsing where stability matters, and claims low false positives.

Xtra is the aggressive version, maximum blocking against emerging privacy threats, marked Beta, with an explicit warning that it may occasionally disrupt legitimate sites or services. The wording on that warning is worth reading closely, because it is unusually candid: the higher false-positive rate is called an inherent trade-off of the aggressive nature, users are invited to report issues for removals, and the section ends with "Not for everyone!"

So the choice is not a coverage slider. It is between a list you install and forget, and a list that will occasionally break something and require you to notice, identify and report it. Projects that ship both usually describe the second as opt-in for power users, which is what happens here, and the practical question for an evaluator is not which blocks more but who is going to be on call when a support ticket arrives because a login page stopped resolving.

The Lite-only default is also consistent with the rest of the project. When the README suggests a starting configuration, it suggests Lite, and it suggests applying it as a local hosts file before anything else.

Ten formats from one list, and why the format matters

The most useful thing in this repository is a table mapping eleven client families to eleven files. It looks bureaucratic and it is the opposite: it is the difference between blocking and not blocking.

hosts.txt
domains.txt
domains.wildcards
adblock.txt
wildcards.txt
dnsmasq.conf
rpz.txt
unbound.conf
hosts.win
snitch.rules

The mapping runs from AdAway, which wants `hosts.txt`, through Pi-hole and OpenSnitch wanting `domains.txt`, dnscrypt-proxy, personalDNSfilter and InviZible Pro wanting `domains.wildcards`, uBlock Origin and AdGuardHome wanting `adblock.txt`, DNSCloak wanting `wildcards.txt`, dnsmasq wanting a config file, Knot, Bind9 and PowerDNS wanting `rpz.txt`, Unbound wanting `unbound.conf`, Windows wanting `hosts.win`, and Little Snitch wanting `snitch.rules`.

Four of those filenames look interchangeable and are not. `hosts.txt` and `hosts.win` are OS hosts files, which match names exactly and do nothing for a subdomain unless it is listed. `domains.txt` is for resolvers that take an explicit domain list. `domains.wildcards` and `wildcards.txt` express the same intent with wildcard semantics, which is how you cover every subdomain of a blocked domain without enumerating them. `rpz.txt` is a response policy zone, a completely different mechanism that returns a synthesised answer rather than refusing to resolve. Feeding a Pi-hole a hosts file, or feeding Bind9 a domain list, produces a configuration that loads cleanly and blocks far less than you expect, which is the quietest possible failure mode in this whole project.

If you read one table from this README, read that one. It is the difference between a working setup and a setup you will not notice is broken.

Three mirrors, and no update mechanism at all

Every file is published on three mirrors, and for a blocklist that redundancy is functional rather than decorative.

The three are the project's own GitHub Pages site under the badmojr.github.io path, the raw.githubusercontent.com URL for the repository, and a jsDelivr CDN path. Any of them will serve the same generated file.

The reason to care is that a blocklist is a subscription, and a subscription has to keep updating. The hosted resolvers listed later in the README state their own refresh intervals, so if you go that route the update problem is handled for you. If you apply a hosts file directly, nothing updates it for you, and a hosts file that quietly stopped updating is indistinguishable from a hosts file that is working.

That is why the mirror choice matters more here than it would for a code package. GitHub Pages is generated by a pipeline, so it lags when that pipeline is busy. Raw GitHub content endpoints rate limit anonymous traffic, which matters on a busy shared network. A CDN caches aggressively and will keep serving a stale file for a while after a regeneration, which is a different failure from the first two. Three mirrors with different failure modes means you notice, rather than assuming a stale list is a working list.

The Xtra variant is distributed differently from Lite. Lite files are reachable from the tables on the project page, while Xtra is described as available in all formats through the releases section. That is a practical difference in how you script an update, not a difference in content policy.

Layered blocking: hosts file first, resolver second

The README offers one configuration recommendation, and it is the most interesting technical idea in the project.

The suggestion is to use Lite as the foundation, applied directly through a hosts file on the device. Two things follow from that. Blocked queries never reach a DNS resolver, so your resolver's logs stay uncluttered. And, more usefully, anything that does appear in the resolver log is by definition not covered by Lite, which gives you a clean signal when you are chasing a false positive. The README makes exactly this point: because the Lite list is reliable, a query that got past it is the thing to look at.

The layering then goes further. The example given is Lite on the device plus Xtra at a resolver such as nextDNS, which means the local hosts file handles the high-confidence bulk and the resolver handles the aggressive remainder. That ordering matters because the failure modes are separated. If something breaks, the hosts file is unchanged and easy to bisect, and the resolver log tells you exactly what the aggressive layer added.

This is also where the project sits against running your own aggregator. Pi-hole and AdGuard Home are listed as consumers of the generated files, but a `-data/` directory in the repository suggests 1Hosts is itself doing aggregation from upstream sources and publishing the result. Doing that yourself with your own source list gives you full visibility into which upstream blocked what, and you own the update schedule. What you take on is the same triage work this project does for you, plus the maintenance, and the point at which that trade flips is whether you care about knowing the provenance of a block.

Four hosted resolvers, four different refresh rates and two query caps

If you would rather not run anything locally, the README lists four hosted resolver options, and the differences between them are not cosmetic.

ControlD is described as updating every 30 minutes, supporting subdomain and wildcard plus CNAME blocking, with unlimited queries. The endpoint details for Lite are given in full: two IPv4 addresses, two IPv6 addresses, a DNS-over-HTTPS path and a DNS-over-TLS hostname. nextDNS also updates every 30 minutes and is customizable, with the same wildcard and CNAME support, but it is capped at 300,000 queries per month on the free tier and requires signing up. AdGuard DNS updates hourly, is customizable with the same blocking features, and offers a 30-day unlimited trial before the same 300,000-per-month cap. rethinkDNS updates infrequently, supports the same blocking features, is unlimited, and is the one listed as open source.

Two things fall out of that table. First, CNAME blocking is supported by all four, which matters because CNAME records are how a lot of tracking and abuse domains hide behind a clean-looking name; a list format that cannot express a CNAME rule is limited no matter how good its domain list is. Second, the only meaningful differences between the four are the refresh interval and the query cap, so the choice is about how fast you want updates and how much you browse, not about blocking quality.

The hosted route also changes your privacy posture in a way worth thinking about. A resolver sees every query your devices make, and using a hosted one with a curated blocklist is a way to reduce what reaches it, not a way to keep queries away from it. That is why the layered hosts-file approach above exists.

What is actually in the repository: -data/ and submit_here/

There is no program in this repository, and the file list explains the whole architecture. The top level holds `-data/`, `Lite/`, `Xtra/`, `submit_here/`, `index.html`, `404.html`, `LICENSE`, `README.md` and `.github/`.

Read that as four things. `-data/` holds the upstream sources being aggregated. `Lite/` and `Xtra/` hold generated output, one set of files per variant per format. `index.html` and `404.html` are the GitHub Pages site that serves as the project's front page and the mirror, which is why the recorded primary language for the repository is HTML rather than a scripting language. And `submit_here/` is the correction queue.

That last one is the design decision worth noting. The false-positive workflow is a directory in a repository, not a form, not a web service and not an account system. A user who is blocked from something legitimate submits an entry, and the correction becomes a reviewable change in the same place the list is generated from. For a project with no server and no accounts that is the right amount of machinery, and it means the audit trail of every removal is public.

The cost is a hard dependency on the generator. Nothing regenerates the files except the pipeline in `.github/`, and the entire output of the project is the product of that job running on schedule. A data project has no unit tests to fail loudly, so freshness is the only health signal, which is why the mirrors in the earlier section matter and why pinning a commit is the only way to be sure what you have is what you expect.

MPL-2.0, one rolling tag, and no version to pin

The licence is MPL-2.0, recorded in LICENSE at the top level. For a repository of generated text files that people remix and redistribute, file-level copyleft is a sensible choice: modifications to the files themselves stay open, while the fact that they came from here is recorded. Read the file for the terms; this review does not interpret them.

The release history is the other thing to plan around. There is exactly one release, a tag named `latest` with the title Lists, dated 2026-09-03, which is the same day as the last push. That is not an oversight, it is a snapshot of the generated files, and it moves.

So there is no semver to pin, no changelog to diff and no way to say "give me the list as it was when it worked". If you deploy 1Hosts into a fleet, or build CI around it, or reference it from a runbook, the only reproducible unit is a commit hash. Two consequences follow. An outage investigation cannot use "we upgraded the blocklist" as a variable, because you will not have a version to roll back to. And a false positive reported today may already be fixed, or may still be open, with nothing in the release metadata to tell you which.

Given that, the sensible deployment pattern is the one the README implicitly recommends: pin Lite to a known commit, watch for problems on your own network, and treat the moving tag as the thing you upgrade to deliberately rather than the thing that pulls itself forward under your feet.

Editorial conclusion

Use 1Hosts Lite as a hosts file on the device if you want a set-and-forget default with a low false-positive rate, and layer Xtra on a resolver only once Lite proves stable on your network. Pick your file from the client table rather than guessing, since the format determines whether subdomains and CNAMEs are actually blocked. Pin a commit rather than the rolling tag, because the project publishes a single moving release called Lists with no semver, and read LICENSE before you redistribute the files, since MPL-2.0 is file-level copyleft and the remix case is exactly what it governs.

Frequently asked questions

Official sources

1. badmojr/1Hosts on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases