It Is Always DNS: Pi-hole, AdGuard Home, Technitium, and the SPOF Problem

Domain Name System (DNS) filtering feels invisible until it breaks. When it does, every app, update, smart device, package manager, and browser suddenly looks broken. In a homelab, DNS is not a side service. It is control-plane infrastructure.

Pi-hole, AdGuard Home, and Technitium DNS can all be good choices. The bigger design question is whether losing one resolver takes the whole house with it.

Design principle: Run DNS like infrastructure: static Internet Protocol (IP) addresses, two resolvers, documented fallback, monitored health, and tested failure behavior.

The Short Version

Use two internal DNS resolvers, advertise both through Dynamic Host Configuration Protocol (DHCP), and keep their local records and filtering policy consistent. Put them on different physical hosts when possible. A second container on the same hypervisor protects against a process failure, but it does not protect against a host reboot, failed switch, tripped breaker, or storage outage.

Do not advertise a public resolver as the second address if you depend on local names, parental policy, or blocklists. Clients do not all treat the first DNS address as a strict primary and the second as cold standby. Some rotate, race, or move to another server after a timeout. Both advertised resolvers therefore need to return compatible answers.

Pi-hole and AdGuard Home are the simpler filtering-first choices. Technitium is the better fit when you also need authoritative local zones, secondary zones, conditional forwarding, or deeper DNS control. The product choice matters less than eliminating shared failure domains and proving client behavior during an outage.

The Decision

Tool	Best Fit	Watch Out For
Pi-hole	Focused DNS sinkholing, visibility, simple blocklists.	High availability and local authoritative zones need deliberate design.
AdGuard Home	Integrated filtering user interface (UI), rewrites, client controls.	It still needs redundancy and backups.
Technitium	Recursive + authoritative DNS features for lab zones.	More DNS power means more configuration responsibility.
Router DNS only	Small networks with minimal needs.	It is often weak for observability, filtering, and backups.

Design the Failure Domains First

Start by drawing the dependency path: client, wireless access point or switch, router/DHCP server, internal resolver, and upstream DNS. Two resolver processes do not create useful redundancy if every path still crosses one failed host or one power strip. A practical small-network design is one resolver on the main server or NAS and another on a low-power physical system connected to the same core network. Better still, protect the router, switch, and both resolver hosts with appropriate power and keep one resolver independent of the main virtualization cluster.

Give each resolver a fixed address and reserve that address outside the dynamic pool. Advertise both addresses in DHCP option 6 for IPv4. If the network uses IPv6, also inspect Router Advertisement Recursive DNS Server (RDNSS) information and DHCPv6 DNS options. A client can appear correct over IPv4 while quietly sending queries to a router or ISP resolver learned over IPv6.

Keep the answer path symmetrical. Both resolvers should know the same home.arpa records, conditional forwarding rules, allowlists, denylists, and upstream policy. RFC 8375 reserves home.arpa. for residential local naming and says those queries should stay inside the home network. Do not invent a fake public suffix, and do not let private names forward to public DNS.

Choose Replication or a Runbook

Redundancy is easy for ordinary recursive lookups because each server can contact its own upstream. Local data is harder. Pi-hole and AdGuard Home deployments commonly use two separately managed instances, so changes must be repeated or synchronized with a tool you understand. Technitium can use primary and secondary authoritative zones, and newer Technitium releases also document clustering, but clustering does not remove the need for configuration backups or failure testing.

• Small and stable: Make the same change on each resolver, export both configurations, and keep a short change log.
• Frequently changing local records: Put authoritative local DNS on one primary and transfer the zone to a secondary, or automate synchronization with reviewable configuration.
• DHCP-integrated names: Decide which service owns DHCP and dynamic records. Never enable two active DHCP servers for the same scope unless they are deliberately configured for failover.
• Encrypted upstreams: Give each resolver working bootstrap DNS and time synchronization. A resolver that needs DNS to resolve its own DNS-over-HTTPS hostname can create a circular dependency.

RFC 2182 discusses secondary authoritative servers rather than home filtering resolvers, but its operational lesson still applies: place redundant servers so one likely failure does not remove all of them. In a homelab, that means thinking about host, storage, switch, link, and power failures rather than merely counting containers.

Single-Point-of-Failure Patterns

• A single DNS virtual machine (VM) on the Proxmox node that also needs DNS to recover.
• Router DHCP advertising only one resolver.
• A public secondary resolver that silently bypasses local names and filtering.
• Docker containers depending on the DNS service they are trying to start.
• No static IP plan for DNS servers.

Validation Commands

Test each resolver directly, then test from a client using normal DHCP settings. Those are different tests, and both matter.

dig @10.10.20.10 techgeeks.org A
dig @10.10.20.11 techgeeks.org A
dig @10.10.20.10 nas.home.arpa A
dig @10.10.20.11 nas.home.arpa A
dig +tcp @10.10.20.10 techgeeks.org A
dig +tcp @10.10.20.11 techgeeks.org A
nslookup router.home.arpa 10.10.20.11

The first pair checks ordinary recursive resolution through each server. The second pair confirms that both servers return the intended local record. The +tcp checks matter because DNS uses both User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) port 53; a firewall that permits only UDP can fail on large responses, retries, or zone transfers. Compare response codes and answers, not just whether dig printed something.

Run a Controlled Failover Test

1. Record the two DNS addresses shown on one wired client and one wireless client. On Linux use resolvectl status; on Windows use ipconfig /all; on macOS use scutil --dns.
2. Query an external name and a known local home.arpa name through the client's normal resolver settings.
3. Stop DNS on the first resolver without shutting down the router or client.
4. Repeat the queries for several minutes. Record the first-query delay as well as eventual success because client timeout behavior varies.
5. Renew DHCP on a test client and confirm it still receives both intended DNS addresses.
6. Restore the first resolver, then repeat the test with the second resolver stopped.
7. Test an expected denylist entry through each server and confirm that no browser, VPN client, or encrypted-DNS setting bypasses the policy.

This editorial revision is documentation-backed; it does not report measured failover times from a TechGeeks lab. Your acceptance result should include the client operating system, lease data, query timestamps, and resolver logs. A successful direct query to each server does not prove normal client failover.

Security and Privacy Boundaries

• Restrict resolver administration pages to a management network or private VPN. DNS service on port 53 may serve clients; the admin interface should not be equally reachable.
• DNS query logs can reveal household routines, apps, devices, and interests. Retain only what you use, restrict access, and include logs in the backup and deletion policy.
• Filtering DNS blocks names, not every malicious connection. It does not inspect traffic addressed directly by IP, replace endpoint patching, or authorize access between VLANs.
• Browsers, operating systems, VPN clients, and mobile Private DNS can use DNS-over-HTTPS or DNS-over-TLS outside the DHCP-provided path. Decide whether to permit, manage, or block that bypass; do not assume the resolver dashboard sees every query.
• Do not expose a recursive resolver to the public internet. Limit recursion to intended local and VPN networks to avoid abuse as an open resolver.

Operational Baseline

• Give DNS servers static IP addresses outside normal DHCP pools.
• Back up blocklists, rewrites, custom records, and upstream settings.
• Monitor Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) port 53.
• Use short DHCP lease times before DNS migrations.
• Document emergency resolver settings for one laptop.

Monitor more than an open port. A process can listen on port 53 while upstream resolution, local zones, or blocklist loading is broken. Use one external query and one local query per resolver, and alert on wrong answers or excessive response time. Keep the check outside the resolver host so it also exercises the network path.

Rollback and Emergency Access

Before a DNS migration, export both resolver configurations and the router's DHCP settings. Lower the DHCP lease time at least one existing lease period before the change. If the new design fails, restore the previous DHCP DNS addresses, renew a test client, and verify both public and local names. Keep one laptop with documented temporary manual DNS settings so you can reach documentation and management interfaces without depending on the broken service.

Do not leave the emergency public resolver configured after recovery. It can mask a still-broken local service and produce inconsistent filtering. Restore the intended two-resolver design, then repeat the controlled failover test.

Useful Gear and Buyer Notes

Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.

Need	Good Choice	Why It Fits	Affiliate Link
DNS host	Two low-power mini computers or single-board computers (SBCs)	Separate resolvers reduce blast radius.	Amazon: Intel N100/N305 mini computers
Network power	Uninterruptible power supply (UPS) for router, switch, and resolver hosts	DNS redundancy provides little protection if both resolvers lose power instantly.	Amazon: CyberPower CP1500PFCLCD Amazon: APC BR1500MS2
Storage	Small solid-state drives (SSDs)	Avoid fragile Secure Digital (SD)-card-only designs for always-on DNS.	Amazon: solid-state drives
Switching	Managed or reliable unmanaged switch	DNS reliability depends on the network core.	Amazon: TP-Link TL-SG2008P PoE switch Amazon: UniFi PoE switch
Labels	Cable and device labels	DNS outages are faster to fix when the boxes are obvious.	Amazon: network cable labels

Common Mistakes

• Using a public DNS server as a secondary resolver and wondering why filtering is inconsistent.
• Hosting both resolvers on the same physical node.
• Pointing the router at Pi-hole before proving Pi-hole itself is stable.
• Forgetting that DNS uses TCP 53 too.
• Not backing up custom DNS records.

References

• Pi-hole Documentation
• Pi-hole FTL Configuration
• AdGuard Home Configuration
• Technitium DNS Help
• RFC 2182: Selection and Operation of Secondary DNS Servers
• RFC 8375: Special-Use Domain home.arpa

Related TechGeeks Resources

• Homelab DNS Guide: Local Names, Ad Blocking, and Reliability
• Remote Access Without Opening Router Ports
• Make DNS Work When the Internet Is Down

Final Thought

DNS is a small service with a large blast radius. Make it redundant, boring, and documented; much of your future homelab troubleshooting will get easier.

This roadmap entry answers a narrow reliability question: how to keep Pi-hole, AdGuard Home, or Technitium from becoming the single DNS dependency. Its recommendations come from resolver documentation and operating patterns, not a measured TechGeeks failover test.