An internal service should have a stable name even when its address changes.
Copying entries into /etc/hosts works for one laptop, but every additional
client becomes another place where the inventory can drift. Split DNS keeps the
mapping in the resolver instead.
Split DNS means that a name receives an internal answer from inside the lab and
may receive a different answer—or no answer—from outside. For example,
grafana.home.arpa can resolve to a private reverse proxy only for local
clients.
Use a domain intended for private networks #
home.arpa is reserved for residential home networks and avoids collisions
with public names. Do not invent a top-level domain such as .lan, and avoid
.local because multicast DNS uses it.
If the lab owns a public domain, a delegated subdomain such as
lab.example.net is another reasonable choice. It can support publicly trusted
certificates, but it also requires deliberate public DNS and certificate
management. The examples here use home.arpa.
Put records in one resolver #
The configuration syntax depends on whether the resolver is Unbound, dnsmasq, AdGuard Home, Pi-hole, or something else. A dnsmasq-style configuration might contain:
1host-record=pve-a.home.arpa,192.0.2.31
2host-record=backup.home.arpa,192.0.2.42
3host-record=grafana.home.arpa,192.0.2.80
Reload the resolver using its supported service command, then query it directly before changing DHCP:
1dig @192.0.2.53 grafana.home.arpa A
2dig @192.0.2.53 pve-a.home.arpa A
The answer should be authoritative for the local data or otherwise clearly come from the intended resolver. Test a nonexistent local name too; unexpected wildcard answers hide spelling mistakes.
Distribute the resolver through DHCP #
Configure each relevant network's DHCP service to advertise the internal resolver. Renew a disposable client's lease and inspect its effective DNS configuration. Modern clients may combine DHCP, VPN, and encrypted-DNS settings, so a correct DHCP offer does not guarantee that every query uses it.
Keep at least two resolvers if DNS is required for basic operation. They should serve the same local records and have independent enough failure paths that one maintenance reboot does not remove name resolution from the whole lab.
Prefer aliases at the proxy boundary #
Point human-facing application names at the reverse proxy, not directly at
every backend. wiki.home.arpa and grafana.home.arpa can share one proxy
address while the proxy routes by hostname. Backend names such as
grafana-app.home.arpa remain useful for monitoring and administration.
This separates the stable user entry point from workload placement. Moving the application between a VM and a container changes one backend record or proxy target rather than every bookmark.
Consider reverse records and cache lifetime #
Forward records answer “which address belongs to this name?” Reverse records answer “which name belongs to this address?” Reverse DNS is not required for ordinary web access, but it makes logs, monitoring, and command output easier to read. If the resolver manages the local reverse zone, add matching PTR records for stable infrastructure addresses.
DNS answers are cached according to their time to live. A long TTL reduces queries but keeps an old address visible longer after a move. A short TTL speeds planned changes but increases resolver traffic. Homelab traffic is usually small, so a moderate value and a documented wait before cutover are sufficient. Do not set every record to a few seconds to compensate for unplanned changes.
Troubleshoot the complete path #
When a client receives the wrong answer, query in layers. Ask the internal resolver directly, then use the client's normal resolver, then inspect which servers the client selected. Flush a cache only after identifying which cache held the stale value. Otherwise the immediate success does not explain the failure.
Also test from each VLAN and through the VPN. Firewall policy must allow DNS to the intended resolver, and guest networks should not silently fall back to an external resolver that cannot know private records. Log enough blocked traffic to identify that mistake without recording every successful query forever.
Document the source of truth and keep changes small. With one internal zone, repeatable queries, and DHCP pointing clients to it, DNS becomes a dependable inventory instead of another cache of old addresses.