ESP32-C3 Adblock

TL;DR

Before you orderOffer from Amazon

Get the latest gadgets delivered free with Prime

• Fast, free delivery on millions of items
• Prime Video, Amazon Music and more included
• Member-only deals all year

Start your free Prime trial →Free trial for eligible customers · Cancel anytime

As an affiliate, we earn on qualifying purchases.Hide

An open-source project turns an ESP32-C3 board into a Pi-hole-style DNS ad blocker, storing more than 140,000 domain hashes in flash rather than loading a full string-based list into RAM. The project says the setup uses about 50 KB of RAM and takes roughly 10 milliseconds per lookup, but those figures are developer-reported and real-world performance may vary.

An open-source ESP32-C3 Ad Blocker project uses a low-cost microcontroller to run a Pi-hole-style DNS sinkhole, with its developer saying more than 140,000 blocked domains fit in flash without requiring PSRAM. The approach may make network-wide DNS filtering possible on a smaller, less expensive board, although the performance and capacity figures come from the project documentation rather than independent testing.

The project’s main design choice is to store each blocked domain as a fixed five-byte, 40-bit hash in flash memory instead of keeping domain-name strings in RAM. When a device sends a DNS query, the firmware extracts the domain, hashes it and checks the sorted table with a binary search. A match returns 0.0.0.0; a miss is forwarded to an upstream DNS resolver, and the reply is relayed to the device.

The README says a list of about 141,000 domains uses 0.67 MB of flash and the device uses roughly 50 KB of RAM. It estimates around 18 flash reads and about 10 milliseconds for a lookup, including Wi-Fi round-trip time. These are figures supplied by the project; the documentation does not describe a controlled independent benchmark or specify a full range of network conditions for that timing.

The stated hardware target is an ESP32-C3 board with 4 MB of flash and no PSRAM; the developer says the project was tested on a C3 SuperMini. A classic ESP32 build is also described as compile-tested, but the C3 is the tested target. The project documentation includes instructions for building firmware and a blocklist, connecting through a setup portal, and updating firmware or lists over Wi-Fi.

DNS Filtering on Smaller Boards

Many network-wide ad blockers run on a separate computer or a device with enough memory to hold a large list of domain names. This project offers another design: a small board can check DNS requests locally while storing compact hashes in flash. If the reported memory use and lookup speed hold in ordinary home networks, it could reduce the cost and hardware footprint of a basic DNS sinkhole.

The method also matters beyond the specific C3 board. Hashing trades readable domain strings for fixed-size entries, allowing more entries to fit in a given amount of storage. But a DNS blocklist is not the same as a full browser ad blocker: it acts on domain lookups, so it cannot apply cosmetic page rules or distinguish every ad from other content served by the same domain. The project’s own format notes say rules such as wildcards, regular expressions and cosmetic filters are skipped.

For readers considering the device, the project provides a low-cost route to experiment with DNS filtering, but setup and maintenance still require building or sourcing lists, configuring Wi-Fi and securing the device’s dashboard. Its value depends on the list and network environment, not only on the board’s price.

How Flash Hashing Works

The project compares its approach with ESP32 sinkholes that load domain strings into RAM. Its documentation estimates that strings for 141,000 domains would need about 2.5 MB of RAM, while the corresponding five-byte hashes take about 0.67 MB of flash. It presents the hash width as a compromise: 32-bit hashes use less storage but carry a greater collision risk, while 64-bit hashes consume more space.

Hash collisions are a limitation because two different domains can produce the same stored value, potentially blocking a domain that was not on the list. The README estimates no collisions at 141,000 domains and about one at 537,000, based on the birthday-bound calculation. Those are estimates, not a guarantee that a particular custom list will have no collisions. The project says its default build combines the StevenBlack base list with Hagezi Light, with roughly 100,000 entries.

The repository describes automatic blocklist publishing through GitHub Actions, with a fresh default list rebuilt each Monday, and supports manual or scheduled updates. Its setup instructions say to flash the firmware and filesystem over USB initially; later updates can be sent through the web dashboard. The developer also warns that current PlatformIO software is needed to build the project.

“140,000+ domains fit in ~0.7 MB of flash and are matched in ~10 ms, using ~50 KB of RAM.”

— ESP32-C3 Ad Blocker project README

Performance and Collision Limits

The documentation does not provide independent measurements of throughput, reliability or power use, nor does it establish how performance changes across different routers, Wi-Fi conditions or blocklist sizes. The stated roughly 10-millisecond lookup time includes Wi-Fi round-trip time, but the README does not give a detailed test method or results across multiple devices.

Hash collisions remain a theoretical and practical limitation, especially as lists grow or users supply custom sources. The README gives estimated collision counts at particular list sizes, but does not describe a per-device check that identifies a colliding pair of domains. It is also not clear from the supplied material how the project compares with established DNS filtering products under the same test conditions.

The project’s documentation warns that dashboard actions and over-the-air updates need passwords, and says these controls were added after state-changing endpoints had previously been open to anyone on the local network. Users still need to set credentials and trust the firmware and blocklist sources they install. The project’s listed features and security claims should not be treated as an independent security audit.

Build, Configure, and Test

The next step for users is to build the firmware and blocklist from the repository, flash the board by USB, and configure its network connection. If Wi-Fi credentials are not supplied during setup, the device documentation says it opens a captive setup portal for joining a home network. Users can then open the local dashboard to upload a list or configure a remote update source.

The project says its default list is rebuilt weekly and can be fetched from a stable release URL. Users who want to assess the claims should test DNS resolution, blocked and permitted domains, update behavior and reliability on their own network, while checking that the dashboard and OTA passwords are set. No independent test results or formal evaluation schedule are given in the source material.

Key Questions

What does the ESP32-C3 Ad Blocker do?

It acts as a local DNS sinkhole. The device checks requested domain names against a blocklist and, according to the project, returns 0.0.0.0 for a match or forwards an unmatched request to an upstream resolver.

Does it need PSRAM?

The project says its tested ESP32-C3 setup needs no PSRAM. It stores compact hashes in flash instead of loading full domain strings into working memory.

How many domains can it block?

The README reports more than 140,000 domains in about 0.7 MB of flash, and estimates about 141,000 entries use 0.67 MB. Actual capacity depends on the available flash space and the list being built.

Does it block every kind of online ad?

No. It filters at the DNS-domain level, not within web pages. The project documentation says cosmetic rules, wildcards, regular expressions and some other rule types are not supported by its hash list.

Are the speed and memory figures independently verified?

The supplied figures—about 50 KB of RAM and roughly 10 milliseconds per lookup—are reported by the project. The documentation provided does not include independent benchmark results or a detailed controlled test protocol.

Source: hn