Who Resolves Your Subdomain When One DNS Node Dies? Technitium Clustering vs Pi-hole HA, Compared Honestly

A story has been going around that both big self-hostable DNS projects shipped native clustering in the same week in July 2026. It is wrong in an interesting way, and the interesting part is exactly what a self-hosted PaaS operator needs to know before trusting either one with wildcard resolution.

Here is what actually happened that week. On July 5, 2026, Technitium shipped DNS Server v15.3, a hardening release on top of a clustering stack that had already been in the wild for eight months. On July 6, Pi-hole shipped FTL v6.7, Web v6.6, and Core v6.4.3 — a security release closing six vulnerabilities, with no clustering in it at all.

And on that same July 6, an independent community project called pihole-ha cut its first public release, v3.0.0, bringing DHCP failover, a floating virtual IP, and config sync to Pi-hole from the outside. One week, three releases, but only one of them was new HA software — and it did not come from Pi-hole itself.

That asymmetry is the whole story. Technitium answers "who resolves my domain when a node dies" with clustering built into the server. Pi-hole answers it with a thriving unofficial add-on that Pi-hole's own maintainers consider out of scope for the core project. Both answers work. They work differently, they fail differently, and they suit different halves of a platform's DNS path. This post compares them concretely so you can pick the right one instead of the most recently hyped one.

The comparison, up front​

The verdict for a PaaS wildcard path: if the question is literally "who resolves <name>.onbex.co on the public internet when one node dies," Technitium clustering is the closer fit, because it is the only one of the two that serves authoritative zones at all. If the question is "who keeps the office, lab, or cluster LAN resolving and leasing DHCP when the Pi-hole box dies," pihole-ha is the purpose-built answer — and it does DHCP failover, which Technitium clustering still cannot do. Most self-hosted platforms eventually need both answers for different networks, so the rest of this post gives you the mechanics to run either one well.

Technitium: clustering built into the server​

Technitium's clustering arrived in v14.0 in November 2025, and as the announcement post explains, the design follows the mental model DNS operators already have from zones: one primary node, one or more secondary nodes, and config changes that can only be made while the primary is online. Secondaries learn about updates through a push notification mechanism backed by a periodic Config Refresh Interval, and if the primary is offline and unrecoverable, an operator promotes a secondary to take its place. Day to day, you log into any node's admin console and manage the whole cluster from there, with a node-selector dropdown for the views that stay per-node (cache, logs, node-specific settings) and an aggregate "Cluster" dashboard for fleet-wide stats.

Zones ride on the same idea through a special cluster catalog zone: member zones added to it sync across every node, and a DNSSEC-signed primary zone added to the catalog gets its private keys synced too, so every node can serve and sign. The Allowed, Blocked, and Apps sections sync completely with no per-node switch at all, including DNS apps and their config. For a PaaS serving a public wildcard plus per-tenant custom domains, this is the shape you want: add the zone once, and every node answers authoritatively for it.

The costs are real and specific. First, the cluster protocol has had breaking changes in v14.1, v14.2, and v15.0, each time with the same instruction: upgrade every node together or the cluster stops working. That is a lockstep-upgrade coupling you must put in your runbook — a rolling upgrade that leaves one node behind is not a degraded cluster, it is a broken one. Second, the DHCP server's scopes are still not clustered. The v14 announcement said scope sync was planned for a later major release alongside DHCPv6, and the changelog through v15.5.1 shows DHCP improvements (persistent records for reserved leases, overwrite options, new DHCP options) but no scope sync. If your nodes also hand out DHCP leases, each node is still on its own.

What the v15 line did bring is everything around the cluster getting more serious. v15.0 (April 2026) added SSO with OpenID Connect, moved to the .NET 10 runtime, and switched the installers to a hardened non-root service. Then the July releases — v15.3 on July 5 and v15.4 on July 11 — added a health-check API that does not spam the query log, zone search and bulk delete, Unix-socket support, and a round of RFC-compliance and DNSSEC-validation fixes. None of that is clustering per se, but a health-check endpoint and saner zone management are exactly what you lean on when your authoritative DNS is a self-managed cluster rather than a cloud API.

pihole-ha: HA as a sidecar to Pi-hole​

pihole-ha comes from the opposite direction: Pi-hole core deliberately does not do HA — a February 2026 forum thread has the feature judged well beyond Pi-hole's scope — so the community built it as an add-on that talks to Pi-hole only through supported interfaces (pihole-FTL --config, the admin page) over plain HTTP, with no SSH keys, no rsync, and no shared filesystem. It is the successor to a long line of sync tools (Gravity Sync, Nebula Sync) that a December 2025 write-up already argued Technitium's built-in clustering made obsolete — an argument pihole-ha now answers point for point. It runs on bare metal under systemd or as a Docker sidecar, and its README states plainly that it is unofficial, unaffiliated with Pi-hole LLC, and maintained separately. That disclosure matters because it sets the support contract: you are adopting a fast-moving community project, currently past v3.18 after starting at v3.0.0 in July, not a vendor feature.

The mechanics are pragmatic. Config sync is an HTTP pull model: the sync publisher rebuilds a bundle (gravity database, adlists, DHCP static leases, custom DNS, FTL settings) only when something actually changes, and standbys fetch and apply it only when it differs — FTL restarts only on real changes. Any node can be promoted to publisher, with auto-promotion if the configured primary is down, and bootstrap protection stops a freshly rebuilt primary from clobbering good standby config. The installer auto-detects whether Pi-hole is the network's DHCP server and picks one of two modes: DHCP-HA with full failover, or DNS-only, which never touches DHCP and just keeps blocklists, custom DNS, and FTL settings in sync while floating the VIP to whichever node answers DNS.

DHCP failover is the headline feature Technitium cannot match: if the primary dies, a secondary takes over DHCP within about 40 to 80 seconds and yields back when the primary recovers, with an optional floating VIP advertised as both DNS server and DHCP server-id so renewals always reach the right node. There is a manual master override, a cluster-wide kill-switch that disables failover everywhere at once, and optional Pushover alerts on failover events. The web UI lives inside Pi-hole's admin interface at Tools > HA Cluster, which is why some coverage described it as "baked into the stock UI" — it looks native, but it is injected by the add-on's installer, and a Pi-hole upgrade that changes the admin page or API can break the integration until the sidecar catches up.

That catch-up risk is the real cost, and the changelog reads like a project that knows it: dozens of releases between July and September 2026 hardening exactly the seams — auth handling against password-protected peers, API session leaks, version-drift behavior, split-brain protection, VIP edge cases. Rapid iteration is reassuring and tiring at the same time. Budget for tracking pihole-ha releases alongside Pi-hole's, and test the pair before upgrading either in production.

So who resolves <name>.onbex.co?​

Time to answer the title's question directly, with the scoping honesty this topic demands. Public-authoritative DNS and LAN resolving are different jobs, and the two projects cover different halves:

For the public wildcard — the NS records at your registrar pointing at your own authoritative servers — Technitium clustering is the self-hosted answer. Sketch it as two or three Technitium nodes on separate machines (separate failure domains if you can), the onbex.co zone in the cluster catalog with DNSSEC signing, each node's IP registered as an NS record, and a monitor on the health-check API driving your alerting. When one node dies, resolvers retry the surviving NS IPs; nothing floats, nothing fails over, because DNS-level redundancy was already the design. The cluster's job is making sure every surviving node serves the identical zone, and the catalog plus key sync does that without a hand-rolled zone-transfer script.

For the LAN side — the network where your nodes, office, or lab live, where Pi-hole already filters and often serves DHCP — pihole-ha is the answer. Sketch it as two Pi-hole nodes with the add-on in DHCP-HA mode, the VIP as the network's DNS and DHCP server-id, config sync keeping blocklists and leases identical. When the primary dies, the secondary holds the VIP and takes DHCP within about a minute; clients pointed at one stable IP never notice. This is the setup the keepalived-plus-Gravity-Sync era required three tools to build, now available as one installer.

Two things neither project removes. First, registrar-level redundancy is still on you: two NS IPs on the same hypervisor is theater, and no clustering software fixes a single upstream network path. Second, "one DNS pod dying" in a Kubernetes-managed fleet is often better solved one layer up — a StatefulSet or Deployment with pod anti-affinity, multiple replicas behind a headless service, and zone transfers between them — before you adopt either project's clustering. These tools shine when the DNS servers are pets with state (long-lived nodes, DHCP leases, hand-tuned zones), not cattle that the orchestrator replaces in seconds.

What it costs to run either​

Put side by side as ongoing operational cost rather than features, the trade is lockstep versus tracking. Technitium's cost is the lockstep upgrade: every breaking protocol change is a maintenance window where all nodes move together, and your runbook needs the promote-a-secondary procedure rehearsed for the day the primary is the thing that died. In exchange you get one vendor, one console, one support surface, and a security track record you can read in the changelog — including a steady stream of externally reported and credited vulnerability fixes through 2026, which is what serious DNS software maintenance looks like.

pihole-ha's cost is tracking two moving targets: Pi-hole's API and admin surface on one side, the add-on's rapid releases on the other. In exchange you get DHCP failover and a VIP without touching keepalived, VRRP, or dnsmasq internals, plus genuinely thoughtful failure handling (split-brain protection, bootstrap protection, a kill-switch) that most hand-rolled Pi-hole HA setups never had. The failure mode to respect is version skew in either direction — a Pi-hole upgrade the sidecar has not adapted to yet, or a sidecar upgrade with a regression in the failover loop — so pin versions, read the changelog, and keep the kill-switch location written down somewhere other than the cluster itself.

Either way, stop treating DNS as a problem solved once at launch. The reason both of these projects exist is that a single DNS server is a single point of failure wearing a static IP, and the fix is no longer a weekend of keepalived configuration. It is a supported clustering model on one side and a one-command installer on the other. Revisit the layer, pick the half you actually need first, and give your subdomains a second node to lean on.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Self-hosted DNS with real failover is part of the same story: infrastructure you can reason about because you run it. Star the repo on GitHub or deploy your first app today.