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

DNS is the part of the homelab everyone forgets until the whole house says the internet is down. The network may be fine. The fiber may be fine. The Wi-Fi may be fine. But if the only resolver is offline, every device in the house is suddenly confused.

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. Many clients will use either resolver whenever they feel like it. 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 the example addresses and names with your own.
dig @10.20.0.53 nas01.home.arpa A
dig @10.20.0.54 nas01.home.arpa A
dig @10.20.0.53 example.com A
dig @10.20.0.54 example.com A
dig @10.20.0.53 blocked-test-domain.example A

# Confirm which DNS servers NetworkManager gave this Linux client.
resolvectl status

# Confirm the local service is listening on both UDP and TCP 53.
sudo ss -lntup '( sport = :53 )'

The first two queries prove that both servers hold the same local answer. The next two exercise upstream resolution independently. The blocked-domain query must use a domain you intentionally placed on a temporary test list; a random advertising domain can change and is poor evidence. resolvectl status shows client configuration, while ss shows whether the server is listening. None of these commands proves that every browser or application uses system DNS, so test one real client workflow as well.

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	Better durability and speed than relying on fragile removable storage for small hosts.	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 report of a TechGeeks outage lab. Two configured resolvers do not prove that every client fails over promptly, that IPv6 or a browser is not bypassing policy, or that local names survive a cold-cache WAN outage. Prove those properties on the real client path by flushing caches, stopping each resolver in turn, disconnecting the WAN, checking the resolver actually queried, and restoring the saved DHCP configuration if the result is not acceptable.

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

Good homelab DNS feels invisible. Names resolve, filtering works, VPN users can find internal services, and the house does not melt down when one small box reboots. That is the goal: boring reliability for the naming layer everything else quietly depends on.

This foundation entry treats DNS as an operating dependency, not merely an ad-blocking feature. Establish the local namespace, DHCP-advertised resolvers, filtering policy, VPN behavior, bypass controls, and recovery order before other services rely on those names; then verify answers and failure behavior from the actual client networks.