Blocky is a fast, lightweight DNS proxy and ad-blocker written in Go that runs on a local network, blocking ad, malware and other unwanted domains for every device that sends its DNS queries to it.

What it is

Blocky is a self-hosted DNS proxy and filtering resolver distributed as a single Go binary, a multi-arch Docker image and a community-supported Helm chart. It sits between the devices on a network and the upstream resolvers those devices would otherwise query directly, inspecting each DNS request and response and deciding whether to answer it, block it or forward it. Configuration lives in one or several YAML files, which keeps the deployment stateless: there is no database and no temporary state to back up or migrate.

The concrete problem it solves is unwanted traffic reaching the network at the resolution layer, before a connection is ever opened. Rather than adding an extension to each browser or client, Blocky blocks by domain against external ad-block and malware lists, and it goes further than simple request matching by inspecting response CNAMEs and response IP addresses against IP lists. It fills the role commonly occupied by Pi-hole in self-hosted networks, and it adds conditional forwarding, per-client-group upstream resolvers and custom DNS resolution for specific domain names on top of that baseline.

Key capabilities

• Blocking of DNS queries against external ad-block and malware lists, with allowlisting and regex support, reloaded periodically from the configured sources.
• Per-client-group allow and deny lists, so separate policies can be defined for groups such as Kids or Smart home devices.
• Deep inspection beyond the requested domain: blocking on response CNAME chains and on response IP addresses checked against IP lists.
• Support for DNS over UDP, TCP, DoH, DoT, DoQ (RFC 9250) and DoH3 (RFC 9114), plus a DoH endpoint that Blocky itself provides.
• Performance features including customizable caching of DNS answers, prefetching of frequently used queries and the use of multiple external resolvers simultaneously, with a low memory footprint.
• Security and privacy controls including DNSSEC validation of upstream resolvers, eDNS support, and random selection of upstream resolvers from the configuration to spread DNS traffic across providers. Blocky does not collect user data, telemetry or statistics.
• Integration surface covering Prometheus metrics, prepared Grafana dashboards, REST API endpoints and a CLI tool.
• Query logging per day and per client in CSV format or to MySQL, MariaDB, PostgreSQL or Timescale, for later analysis.

Who uses it and how

• Home and homelab operators running it on a Raspberry Pi or an OpenWrt router, since the binary supports x86-64, ARM and MIPS architectures.
• Households that need differentiated filtering, using client groups to apply a stricter policy to children's devices and a looser one to smart home hardware.
• Kubernetes operators deploying it through the community-supported Helm chart alongside an existing cluster networking stack.
• Teams that want DNS query visibility, logging per client per day into MySQL, MariaDB, PostgreSQL or Timescale and charting it with the prepared Grafana dashboards.
• Operators who monitor DNS health through Prometheus metrics and drive changes or queries through the REST API or the CLI tool instead of editing YAML by hand.

Getting started

Run the multi-arch Docker image spx01/blocky, or download the single binary, then point clients at the host as their DNS server and supply the YAML configuration; the Helm chart is the route for Kubernetes. Documentation lives at the project homepage, https://0xERR0R.github.io/blocky/.

How it compares

Within this registry, Blocky is tagged alongside Pi-hole, the other widely known self-hosted DNS filter, and it is the closest comparable tool named in the facts here. Its documented differences are the breadth of the transports it speaks, including DoQ and DoH3, the ability to define upstream resolvers per client group, and a stateless design with no database and no temporary files. It is licensed Apache-2.0, so it can be self-hosted, modified and redistributed freely.

When to use it — and when not to

Choose Blocky when the goal is network-wide DNS filtering with modern transports and detailed query logs, and when the operator is comfortable with YAML configuration and running supporting services. Be aware that persistent logging depends on an external MySQL, MariaDB, PostgreSQL or Timescale instance, so retention is something you operate rather than something the binary provides, and that the Helm chart for Kubernetes is community-supported rather than an official artifact. It is also a project developed in the maintainer's spare time, and the README excerpt available in this registry is truncated mid-sentence, so anyone needing commercial support or an appliance-style bundled UI should look elsewhere.