senn-techFrom Pi-hole to Technitium: One Server for Blocking, DNSSEC and Native HA
In an earlier post we compared Pi-hole and AdGuard Home for network-wide ad blocking. We ran Pi-hole v6 in production for a while — and were happy with it. Then high availability became the breaking point, and we moved both of our resolvers to Technitium DNS Server. Here is the honest story of why, and what we gained.
The trigger: an HA sync that wasn't
DNS is critical infrastructure. A single resolver is a single point of failure, so we run two — primary and secondary — and the blocklists and settings have to stay in sync between them. Pi-hole has no native sync between nodes, so we bolted on a third-party sync tool.
That bolt-on is exactly what bit us. One night the sync job's "full sync" mode didn't merge the two databases — it replaced the primary's blocking database with an empty one. Blocking went dead network-wide, and replication broke. We recovered from a backup, but the lesson was clear: a sync that can wipe your primary is not high availability. We didn't want to keep patching a fragile add-on around a tool that was never designed to cluster.
What Technitium is
Technitium DNS Server is a free, open-source, cross-platform DNS server. Where Pi-hole and AdGuard are first and foremost ad blockers that happen to speak DNS, Technitium is a full DNS server — authoritative zones, recursive resolution, conditional forwarding, DNSSEC, encrypted DNS (DoH/DoT/DoQ) — that also blocks, via an app. That difference in scope is the whole point.
What we gained
Moving to Technitium replaced a stack of workarounds with built-in features:
- Native clustering. A primary node and a secondary node, joined into a cluster. Blocklists, allow/deny rules, apps and zones edited on the primary auto-sync to the secondary — using notify/refresh, not a destructive full-replace. This is the feature we actually came for.
- DNSSEC validation. On by default now. Forged or tampered DNS answers are rejected.
- Encrypted upstream (DoT). Our resolvers forward over DNS-over-TLS on port 853 to public upstreams, instead of plaintext port 53. Nobody on the path sees our lookups.
- Advanced Blocking. Dozens of blocklist URLs plus exact allow/deny entries and regex rules, all in one app — with a blocked answer of
0.0.0.0, just like a sinkhole. - Split-horizon DNS. Internal overrides for our own domains, served as conditional-forwarder zones — clean, and part of the cluster catalog so they sync too.
- Query logging. A SQLite-backed query log app with retention, browsable in the GUI for troubleshooting.
The trade-offs — honestly
Technitium isn't a free lunch:
- Smaller community. Pi-hole's biggest strength is the sheer volume of documented edge cases and a massive forum. Technitium is led by a single, very active maintainer. The docs are good and the project moves fast, but you will occasionally be the first person to hit a given corner.
- More knobs. Because it's a real DNS server, there's more to understand — forwarders vs. recursion, what syncs in a cluster vs. what's per-node, DNSSEC and certificate handling. Power comes with surface area.
- Blocking lives in an app. The Advanced Blocking app is excellent, but it's a layer you configure, not the headline feature with a one-click setup like Pi-hole's.
Pi-hole v6 vs. Technitium, at a glance
| Criterion | Pi-hole (v6) | Technitium |
|---|---|---|
| Primary role | Ad blocker (DNS sinkhole) | Full DNS server (blocking via app) |
| Native HA / sync | No (needs a bolt-on) | Yes — native cluster |
| DNSSEC validation | Limited | Yes |
| Encrypted upstream | Via workaround | Built in (DoH/DoT/DoQ) |
| Authoritative zones | No | Yes |
| Blocking | Gravity (~1M domains) | Advanced Blocking app (lists + regex) |
| Query log GUI | Yes | Yes (SQLite app) |
| Community | Enormous | Small but very active |
| Maturity | Very high | High |
How the migration went
We migrated with zero DNS downtime. The trick was to keep the existing primary serving the whole time: we rebuilt the second node empty, joined it to the cluster as a fresh secondary on cluster-only ports (no port 53), verified that the full configuration had synced, and only then flipped it back to serving DNS. The old Pi-hole data was archived on each node for rollback — nothing deleted on day one.
A couple of things bit us along the way: a firewall that only allows outbound port 53 to our chosen upstreams (so we forward over DoT rather than recurse), and an admin-password file that only applies on first init (change it in the console, not the file). Both are the kind of thing you only learn by doing.
Our verdict
If Pi-hole or AdGuard covers your needs and you only run one box, there is no migration pressure — they're excellent, and our earlier comparison still stands. But the moment you need two resolvers that stay in sync reliably, plus DNSSEC and encrypted upstream without bolt-ons, Technitium is in a different class. For us it turned three workarounds into three checkboxes — and DNS hasn't skipped a beat since.