Case study: a six-device household
One deployment, written up with the numbers we actually measured and the two things that went wrong.
Last updated · Thirty days to 15 August 2026
The setup
A Raspberry Pi 4 with 2 GB of memory, running the resolver, on a domestic fibre connection behind an OpenWrt router. Six devices: two laptops, two phones, a television and a games console. The gambling and affiliate lists enabled, lottery and crypto lists off.
DHCP option 6 set to the Pi's address, so every device is told to use it directly rather than through the router. That is the configuration described in router setup.
What we measured
Read from the resolver's own counters and systemd-cgtop over thirty days.
| Measure | Value |
|---|---|
| Queries per day, mean | 41,300 |
| Cache hit rate | 78% |
| Median response, cached | < 1 ms |
| Median response, uncached | 24 ms |
| Resident memory | 84 MB |
| Blocked share of queries | 0.9% |
| Unplanned downtime | 6 minutes |
The blocked share is low because nobody in this household is trying to reach gambling sites. It is a measure of ambient advertising and tracking rather than of intent, and it should not be read as a general figure. A household with an active problem would look completely different, and we have no data on what that looks like because we do not log queries.
The two things that went wrong
Six minutes of downtime when the Pi's SD card remounted read-only during a log rotation. Every device lost DNS. Because a public secondary was configured, most recovered within seconds onto unfiltered DNS, which is exactly the trade-off described in troubleshooting: the filter fails open, not closed. We moved the resolver to a USB SSD.
A television stopped updating. Its update endpoint sat on a CDN hostname that shared a parent domain with an entry on the affiliate list. The suffix rule caught it. We narrowed the rule, published the correction in the changelog, and it is the reason the coverage checker now shows which rule matched rather than just a yes or no.
What we would tell someone else
Set a secondary resolver and decide deliberately whether it should be a public one. Put the resolver on storage that does not wear out. Expect one false positive in the first month and know where to report it.
And do not expect the numbers above to be yours. One household is one data point. If you deploy this and are willing to have your figures published, we would like to hear from you.