Private DNS for Homelabs Without Leaking Internal Services

Private Domain Name System (DNS) design is not just inventing server.lan and calling it a day. It is deciding which names exist only inside your local area network (LAN), which names can be public, and how Virtual Private Network (VPN) or mobile clients should resolve them without exposing your service map.

Request for Comments (RFC) 8375 reserves home.arpa for home networks. RFC 6762 explains why .local is already used by Multicast DNS (mDNS). Those two facts alone can avoid a lot of naming pain.

Design principle: Names are part of your security model. Public DNS should not publish a map of private services unless you intend it to.

The Decision

Name Pattern	Use When	Caution
nas.home.arpa	Purely local home service names.	Keep it inside your home DNS.
app.lab.example.com	Owned domain with split-horizon DNS.	Keep public zones from exposing private Internet Protocol (IP) addresses accidentally.
Tailscale MagicDNS name	Private overlay device and service access.	Depends on tailnet DNS behavior.
public app.example.com	Intentionally published service.	Needs Transport Layer Security (TLS), authentication, updates, and monitoring.

Naming Strategy

For most homes, use home.arpa internally. For services that need public certificates or a friendlier household hostname, use a subdomain you own and split the answers: internal resolvers return private IPs, while public DNS returns only public services or nothing.

What You Are Building

The safe baseline has one authoritative source for private records and one documented path by which clients reach it. Your router's DHCP service tells LAN clients which resolver to use. A VPN profile gives remote clients that same resolver, or applies a split-DNS rule only for the private zone. Public recursive resolvers never need a copy of the private zone.

1. Private zone: create home.arpa on a local resolver such as Unbound, Technitium, Pi-hole, AdGuard Home, or a router that supports local records.
2. Stable records: reserve addresses in DHCP or use another stable addressing method before assigning names. A DNS record that follows a changing address will fail unpredictably.
3. Client distribution: advertise the resolver's IP through DHCP for every relevant VLAN. Do not rely on entering DNS settings manually on every client.
4. Remote resolution: send the private zone to the local resolver through WireGuard, Tailscale, or another authenticated VPN. Limit routes and firewall access to what remote users actually need.
5. Resilience: run a second resolver only if its zone data and filtering policy stay synchronized. Two advertised resolvers with different answers create intermittent failures, not redundancy.

Keep infrastructure records boring and specific: nas.home.arpa, ha.home.arpa, and dns1.home.arpa are easier to operate than clever aliases. A short time to live (TTL), such as 300 seconds, is useful while migrating; increase it after addresses and records are stable. Do not point a name at a service unless firewall policy permits the intended clients to reach that address and port.

Owned Domain or home.arpa?

Requirement	Use	Operational Tradeoff
Names work only at home or through VPN	home.arpa	No registrar dependency or public record, but public certificate authorities do not issue certificates for these private names.
Publicly trusted certificates on private addresses	A subdomain of a domain you control	Use split DNS and DNS-01 validation; protect the registrar and DNS API account.
Service is intentionally public	A public record under an owned domain	Requires explicit exposure controls, authentication, patching, logs, and an incident response path.
Device discovery on one local link	mDNS .local	Useful for discovery, but not a substitute for a routed private DNS namespace.

Do not invent .lan, .internal, or another unregistered suffix. A future naming collision or search-domain behavior can send queries somewhere you did not intend. RFC 8375 gives home networks a purpose-built namespace, while RFC 6762 reserves .local for mDNS link-local use.

Certificate Strategy

DNS-01 challenges can validate certificate requests without exposing a private address record. That is useful for internal Hypertext Transfer Protocol Secure (HTTPS) on a subdomain you own. Public certificate authorities will not issue for home.arpa; use a private certificate authority whose root is deliberately installed on your clients, or use an owned domain. Remember that certificate transparency logs can still reveal certificate names, so a narrowly scoped wildcard certificate may reduce per-service name exposure but increases the impact if its private key is stolen.

Give the ACME client the smallest DNS permission your provider supports. Prefer a token restricted to the required zone or delegated _acme-challenge subzone rather than a registrar-wide credential. Store it as a secret, exclude it from source control and routine logs, and document how to revoke it. DNS-01 proves control of DNS; it does not authenticate the application, harden the reverse proxy, or make a private service safe to publish.

Verification From Every Network

Test both the answer and the path that produced it. Replace the example resolver and names below with your own. dig asks a specific resolver directly, while resolvectl status shows the DNS servers and per-link domains selected by systemd-resolved on many Linux systems.

dig @192.168.50.53 nas.home.arpa A +short
dig @192.168.50.53 nas.home.arpa AAAA +short
dig @1.1.1.1 nas.home.arpa A +short
dig @1.1.1.1 app.lab.example.com A +short
resolvectl status

• LAN client: the private resolver returns the expected address, the service port is reachable, and the certificate name matches.
• VPN client: the private name resolves while connected and stops resolving, or returns the intended public answer, after disconnecting.
• Off-LAN client: a public resolver returns no private service record. Also check both A and AAAA records so an old IPv6 entry does not bypass the intended design.
• Guest and IoT VLANs: DNS works, but firewall policy denies management interfaces that those zones should not reach.
• Failure test: stop one resolver during a maintenance window and confirm clients use a synchronized second resolver, or follow the documented break-glass path.

Browsers and operating systems can use encrypted DNS independently of DHCP. That may bypass local filtering or make split names fail. Decide whether to manage encrypted DNS, provide an approved encrypted resolver, or accept that unmanaged clients may not resolve private names. Blocking public DNS alone is incomplete because DNS over HTTPS uses normal HTTPS transport; any enforcement choice has privacy and support tradeoffs.

Failure Modes and Recovery

Before changing DHCP or a production zone, export the resolver configuration, zone data, DHCP settings, and VPN DNS policy. Record the resolver IPs somewhere that does not depend on DNS. Keep the old resolver available until one wired client, one wireless client, one VPN client, and each important VLAN pass the checks above.

• Clients retain an old resolver: renew the DHCP lease or reconnect the interface, then inspect the actual resolver list. Lowering DHCP lease time before migration can shorten this transition.
• Names resolve but apps fail: test the destination IP and port. DNS cannot repair a firewall rule, reverse-proxy route, certificate mismatch, or stopped application.
• Random success and failure: compare every advertised resolver. Remove stale servers or synchronize their zones and policies.
• VPN names fail: verify the private DNS route, allowed IP ranges, split-domain suffix, and firewall path from the VPN address pool to the resolver.
• Certificate renewal fails: inspect ACME logs and the public TXT response, then rotate a suspected API token. Do not expose an application port as an improvised workaround.

Rollback by restoring the previous DHCP DNS option and VPN policy, re-enabling the old resolver, and renewing one test client's lease. Do not delete the new zone until cached records have expired and the rollback is stable. If DNS is completely unavailable, connect by a documented management IP from a trusted network, restore resolver service, and avoid broad temporary firewall rules.

Leak Prevention Checklist

• Dynamic Host Configuration Protocol (DHCP) advertises only internal resolvers to LAN clients.
• VPN clients receive split DNS or the same internal resolver view.
• Public DNS does not publish private RFC 1918 addresses unless you have deliberately designed for that exposure.
• Firewall policy can restrict outbound DNS if you need stronger enforcement.
• Internal service names are tested from both LAN and off-LAN networks.

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	Low-power DNS server or mini personal computer (PC)	Private DNS should not disappear when a single app host goes down.	Amazon: Intel N100/N305 mini PCs
Domain security	Hardware security key	Protects registrar and DNS provider accounts.	Amazon: YubiKey hardware security key
Firewall	Router or firewall appliance	Useful for DNS enforcement, VPN DNS, and split routing.	Amazon: 2.5-gigabit Ethernet (2.5GbE) firewall appliance
Power	Uninterruptible Power Supply (UPS) for network core	DNS is useless if the router and switch are dark.	Amazon: CyberPower CP1500PFCLCD Amazon: APC BR1500MS2
Documentation	Label maker and network notebook	Private names are easier to maintain when the physical network is labeled.	Amazon: label maker network cable

Common Mistakes

• Using .local for normal DNS names.
• Putting private service records into public DNS by accident.
• Expecting phones on cellular to resolve private names without VPN DNS.
• Publishing wildcard DNS records without understanding the exposure.
• Forgetting to rotate DNS application programming interface (API) tokens used for certificates.

What This Does Not Prove

This documentation-backed design does not prove that a particular resolver, firewall, certificate workflow, or VPN configuration is secure or reliable in your environment. No packet capture, failover drill, certificate-renewal run, or device-compatibility test was performed for this article. Verify name resolution from every client network, inspect public DNS for accidental private records, test renewal before certificate expiry, and confirm that recovery still works when the primary resolver is unavailable.

References

• RFC 8375: home.arpa
• RFC 6762: Multicast DNS
• NIST SP 800-81 Rev. 3: Secure DNS Deployment Guide
• Tailscale DNS
• Tailscale MagicDNS
• Cloudflare Resolver Policies
• Unbound Configuration
• Let's Encrypt Challenge Types

Related TechGeeks Resources

• Homelab DNS: Local Names, Ad Blocking, and Resolver Design
• WireGuard VPN for Secure Homelab Remote Access
• Reverse Proxy Setup Without Security Mistakes

Final Thought

Private DNS is a small design task with a big usability payoff. Good names make the lab feel professional; careful split views keep the private map private.

This roadmap entry answers a narrow DNS question: how to resolve private hostnames through LAN and VPN resolvers without publishing internal addresses. Its recommendations are documentation-backed; verify the split view from every client network and retain a resolver-bypass path before treating the namespace as dependable.