Homelab DNS Guide: Local Names, Ad Blocking, and Reliability

When names fail, test the configured resolvers directly before changing Wi-Fi or routing. This design keeps private records consistent across two resolvers and checks how real clients behave when either resolver is unavailable.

A good DNS design gives you human-friendly names, ad and tracker filtering, split-horizon records, VPN usability, and a clean way to find services without memorizing IP addresses. The standards matter here: RFC 8375 reserves home.arpa for home networks, while RFC 6762 defines multicast DNS and explains why .local is not a casual private-domain choice.

Design principle: Treat DNS like core infrastructure. Run at least two resolvers, document your local domain, and make sure VPN clients get the same private naming view as LAN clients.

The Short Version

Use home.arpa for private home names, run two resolvers that return the same local answers, and advertise both through the one DHCP service that actually controls client settings. Keep local records local, choose upstream recursion separately, and test each resolver by IP before changing a whole network. A second resolver is useful only if it lives outside the same host, storage, update, and power failure as the first.

The clean baseline is simple: clients ask Pi-hole, AdGuard Home, or Technitium; that filtering layer answers local zones itself and sends other names to either an upstream provider or a recursive resolver such as Unbound. VPN clients receive a route to the resolver plus the correct search or split-DNS domain. Public resolvers should not be handed out as a third option because clients may use them during normal operation and bypass local names and policy.

Pick A Local Naming Plan

Use home.arpa for internal home names unless you have a real domain and a clear split-horizon plan. Examples might be nas.home.arpa, proxmox.home.arpa, dns01.home.arpa, printer01.home.arpa, and controller.home.arpa.

Name Type	Example	Use It For
Infrastructure	gateway.home.arpa, switch-core.home.arpa	Routers, switches, AP controllers, DNS, monitoring.
Services	photos.home.arpa, docs.home.arpa	Human-friendly names for apps.
Hosts	nas01.home.arpa, pve01.home.arpa	Actual machines and hypervisors.
Public split	photos.example.com	A name that may resolve public outside and private inside.

Primary And Secondary Resolvers

Two DNS servers do not always behave like active/passive failover. Client selection and retry behavior vary, so either resolver may receive normal queries. That means both resolvers need to know the same local records, block lists, upstream behavior, and conditional forwarding rules.

1. Run DNS on two separate hosts if possible, such as a mini PC and a NAS VM, or two small Linux hosts.
2. Keep both resolvers on stable power.
3. Use DHCP to hand out both DNS server addresses.
4. Synchronize local records and block-list policy through configuration management or documented manual change process.
5. Test each resolver directly before trusting client behavior.

Place the resolvers where every intended client can reach them, but do not make their admin interfaces broadly reachable. An IoT VLAN may need DNS service on UDP and TCP port 53 without needing access to the DNS dashboard, SSH, or the rest of the management network. Allow the service flow narrowly and keep management on a trusted admin segment or VPN.

Pi-hole, AdGuard Home, Technitium, Or Unbound?

Tool	Best Fit	Notes
Pi-hole	Simple ad blocking and local DNS	Well-known, strong community, and documented Docker deployment.
AdGuard Home	Polished DNS filtering with an approachable UI	Good fit for families and clean dashboards.
Technitium	Advanced local DNS features	Useful when you want a richer authoritative DNS experience.
Unbound	Local recursive resolver	Unbound is a validating, recursive, caching DNS resolver. Often paired behind Pi-hole or AdGuard Home.

DNS Policy And Bypass Control

If you care about DNS filtering, clients should use your resolvers. That means DHCP should advertise your internal DNS servers, firewall rules should block or redirect outbound port 53 where appropriate, and you should understand which devices use DNS over HTTPS or hardcoded resolvers.

DoH reality: DNS over HTTPS can be useful for privacy, but it can also bypass household filtering. Cloudflare documents DoH behavior for 1.1.1.1; decide whether your network policy allows, blocks, or explicitly routes it.

VPN DNS

Your WireGuard peers should receive the same internal DNS view as local trusted clients. Otherwise the VPN connects successfully, but users still cannot find nas.home.arpa, docs.home.arpa, or controller.home.arpa. DNS is part of the remote-access design, not an afterthought.

Roll Out DNS Without Taking Down The House

1. Export the current router, DHCP, and resolver configuration. Record the current DNS addresses and lease time.
2. Build the new secondary resolver first. Add the same local zone, records, upstream policy, and block-list exceptions as the existing resolver.
3. Query both resolvers directly from an admin workstation. Do not change DHCP yet.
4. Add the secondary address to DHCP, renew one test client's lease, and confirm the client received exactly the intended pair.
5. Move one client or VLAN at a time if replacing the primary resolver. Watch query logs, timeouts, and application behavior through at least one normal usage period.
6. Only after both paths work should you shorten or remove the old resolver address.

Rollback is a DHCP and routing action, not a reinstall. Restore the previous DNS addresses, renew affected leases, and keep the old resolver available until caches and leases have aged out. If the new resolver is authoritative for local records, export those records before removal. A snapshot helps recover the server, but it does not repair clients that were handed an unreachable DNS address.

Verification Commands And What They Mean

# Replace these example resolver addresses and names.
for resolver in 10.20.0.53 10.20.0.54; do
  dig @"$resolver" nas01.home.arpa A
  dig @"$resolver" nas01.home.arpa A +tcp
  dig @"$resolver" example.com A
  dig @"$resolver" blocked-test-domain.example A
done

# On a Linux client using systemd-resolved:
resolvectl status

# Separately, on EACH resolver host, inspect local UDP/TCP listeners:
sudo ss -lntup '( sport = :53 )'

Compare each response status, expected address and answering server; a successful dig exit does not mean the answer is correct. Test local queries over UDP and TCP. A public answer may come from cache and does not by itself prove upstream reachability. For filtering, place a controlled test name on a temporary list and correlate the result with each resolver's policy log; NXDOMAIN for blocked-test-domain.example alone proves nothing because that example is not a normally resolving public name. resolvectl status reports systemd-resolved settings where that service is used. Run ss on each resolver, not just the client; a listener does not prove remote reachability. Finally test the actual browser/application DNS path.

Read The Failure Signal

Result	Likely Meaning	Next Check
Timeout	The resolver is unreachable, not listening, overloaded, or blocked by a firewall.	Ping only as a reachability hint, then test UDP/TCP 53, service status, and firewall logs.
NXDOMAIN	The resolver says the name does not exist.	Check the exact local zone, spelling, search suffix, and whether both resolvers contain the record.
SERVFAIL	The resolver could not complete the lookup.	Inspect resolver logs, DNSSEC validation, upstream reachability, and system time.
Public answer for a private name	The client bypassed local DNS or the split rule did not match.	Inspect DHCP/VPN DNS settings, browser secure-DNS settings, and the queried server shown by the tool.
Works by IP, fails by name	Routing may be fine while DNS is wrong.	Query both resolvers directly and inspect the returned address and time to live.

Validation Checklist

• Each resolver answers local home.arpa records consistently.
• Each resolver can still resolve internet names if the other resolver is offline.
• A client receives both DNS servers from DHCP.
• VPN clients resolve internal names over the tunnel.
• Blocked domains are blocked by both resolvers.
• Internal-only names do not resolve publicly.

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
Small DNS host	Raspberry Pi, mini PC, or always-on Linux VM	DNS is light, but it needs stable uptime.	Search Amazon: Raspberry Pi kit
Low-power server	N100/N150 mini PC	A good option if DNS also runs monitoring or small services.	Search Amazon: N100 mini PC
External SSD	Samsung T7 Shield	Check host interface support, power, endurance requirements and backups; this article supplies no comparative durability test.	Amazon: Samsung T7 Shield 2TB
UPS	CyberPower or APC UPS	DNS should survive short power blips alongside gateway and switch.	Amazon: CyberPower CP1500PFCLCD Amazon: APC BR1500MS2

Common Mistakes

• Using .local for normal DNS records and then fighting mDNS behavior.
• Running one resolver and calling it a day.
• Forgetting to update the secondary resolver when adding local records.
• Letting VPN peers use random public DNS and then wondering why private names fail.
• Assuming "secondary DNS" means clients will only use it during failure.

What This Does Not Prove

This design is documentation-backed, not a TechGeeks outage-lab result. Two configured resolvers do not establish client failover, IPv6/browser policy or cold-cache local naming during WAN loss. In an approved window with independent administration, test one resolver failure at a time, restore it before the next test, and separately test WAN loss. Record the server queried and retain the prior DHCP configuration for recovery; do not interrupt household-critical services without an agreed fallback.

References

• RFC 8375: Special-Use Domain home.arpa
• RFC 6762: Multicast DNS
• Pi-hole Docker Documentation
• Unbound Project
• Cloudflare DNS over HTTPS
• APNIC: DNS resilience and resolver failure behavior

Related TechGeeks Reading

• Fix DNS Once: Router vs PC vs Browser
• How Do You Make DNS Keep Working When the Internet Is Down?
• Homelab VLAN Design: Simple Network Segmentation That Works
• WireGuard Home VPN: Secure Remote Access for Your Homelab

Final Thought

Retain a current local-record inventory and verify both resolvers after every policy change. The acceptance point is consistent answers and demonstrated client recovery, not merely two addresses in DHCP.