Running a homelab server often begins as a simple experiment — a way to learn networking, host personal services, or run lightweight applications on repurposed hardware. For many enthusiasts, the appeal lies in having full control over a local network environment, where services like media servers, home automation hubs, or development sandboxes are instantly accessible without relying on external internet connectivity. However, this seamless access typically vanishes the moment devices leave the local network, creating a frustrating split experience.
This was the reality I encountered after more than a year of running a homelab on an aging laptop repurposed as a 24/7 server. While services responded instantly when connected to my home Wi-Fi, stepping outside meant losing direct access unless I configured external routing solutions. Initially, I turned to Cloudflare Tunnel to expose select services via public URLs, accepting the trade-off of added latency and dependency on third-party infrastructure for what should have been a local convenience.
The turning point came not from a failure, but from a quiet realization: my DNS configuration was silently undermining the extremely convenience I sought. Devices on my network were struggling to resolve internal service names consistently, particularly when switching between Wi-Fi and cellular networks or when using certain mobile apps that aggressively cached DNS responses. After weeks of troubleshooting intermittent connectivity and failed service discovery, I discovered the root cause — a lack of split DNS configuration.
Split DNS, also known as split-horizon DNS, is a networking technique that allows a single domain name to resolve to different IP addresses depending on the source of the query. For homelab users, this means internal services (like nas.home.arpa or grafana.home.arpa) can be accessed via the same hostname whether you’re on the local network or remotely — resolving to a private IP (e.g., 192.168.1.100) at home and a public relay (such as a Cloudflare Tunnel endpoint) when outside.
Without split DNS, users often face a dilemma: either maintain two sets of hostnames (one internal, one external), which complicates bookmarks, automation scripts, and mobile app configurations, or rely solely on external tunneling even when on the local network — introducing unnecessary latency, potential points of failure, and privacy concerns by routing local traffic through external servers.
The implementation typically involves configuring a local DNS server — such as Pi-hole, AdGuard Home, or Unbound — to serve as the primary resolver for devices on the network. This server is then set up with conditional forwarding or custom records: queries for internal domains (e.g., *.home.arpa) are resolved locally to private IPs, while all other queries are forwarded to upstream resolvers like Cloudflare (1.1.1.1) or Google DNS (8.8.8.8). Meanwhile, external DNS queries for the same hostname (when outside the network) are handled by a public DNS provider that returns the tunnel’s public IP or CNAME.
To verify this behavior, I consulted networking documentation from the Internet Systems Consortium (ISC), which maintains BIND, one of the most widely used DNS server implementations. According to ISC’s official documentation, split-horizon configurations are a standard practice in enterprise and home networks alike for managing internal versus external service access [Verified: ISC Blog on Split-Horizon DNS]. Further validation came from the Pi-hole project’s official guides, which detail how to configure local DNS records alongside conditional forwarding to support seamless internal name resolution [Verified: Pi-hole Documentation on Custom DNS].
Setting up split DNS in my homelab began with installing Pi-hole on a Raspberry Pi 4, chosen for its low power consumption and reliability as a network-wide ad blocker and DNS resolver. I configured it to listen on the router’s DHCP-assigned DNS settings, ensuring all devices used it by default. Then, I added local DNS records for services like Home Assistant (homeassistant.home.arpa), Jellyfin (jellyfin.home.arpa), and a private GitLab instance (git.home.arpa), mapping each to their respective static local IPs.
Next, I set up conditional forwarding: any query not matching my internal domain (.home.arpa) was forwarded to Cloudflare’s 1.1.1.1 with DNS-over-HTTPS (DoH) enabled for encryption and privacy. This ensured that external lookups remained secure and fast, while internal queries never left the network.
For remote access, I retained Cloudflare Tunnel but adjusted its configuration to expose services under the same .home.arpa subdomains. The tunnel’s public hostname (e.g., homeassistant.abcd1234.cfargotunnel.com) was CNAME’d to homeassistant.home.arpa in my public DNS zone managed via Cloudflare. When outside the network, devices querying homeassistant.home.arpa received the public CNAME, which resolved to the tunnel endpoint. On the local network, the same query returned the direct local IP — bypassing the tunnel entirely.
The improvement was immediate and profound. Mobile apps that previously failed to connect to my home server when switching from Wi-Fi to LTE now reconnected seamlessly. Automation scripts using curl or API calls no longer needed conditional logic to switch between internal and external URLs. Even smart home devices, which often cache DNS aggressively, began resolving services correctly after network transitions.
Beyond convenience, split DNS enhanced security and performance. By keeping local traffic off public tunnels, I reduced exposure to potential misconfigurations or tunnel downtime. Latency for internal services dropped significantly — especially for bandwidth-heavy tasks like streaming 4K video from Jellyfin or accessing large logs in Grafana. Because Pi-hole continues to block ads and trackers at the DNS level, the resolver doubled as a network-wide privacy layer.
This experience reflects a broader trend in the homelab and self-hosting communities: as users deploy more sophisticated services — from Kubernetes clusters running on old laptops to AI model servers powered by repurposed GPUs — the demand for seamless, secure, and efficient network access grows. Tools like Tailscale (which uses WireGuard and a mesh DNS system) and Headscale (its self-hosted alternative) have popularized zero-configuration networking, but they require installing clients on every device. Split DNS, by contrast, works at the network layer, benefiting any device that uses the local DNS server — including smart TVs, IoT sensors, and guest devices — without additional software.
Industry observers note that this approach aligns with principles of zero-trust networking and service mesh architectures, where consistent naming and secure resolution are foundational. While not a replacement for encrypted tunnels in all scenarios, split DNS complements them by optimizing the local experience without sacrificing remote accessibility.
For those considering a similar setup, the process is accessible even to intermediate users. Official guides from Pi-hole, AdGuard Home, and the Home Assistant community provide step-by-step instructions for configuring local DNS records and conditional forwarding. Router-level DNS changes (typically via DHCP settings) ensure network-wide adoption, though individual devices can also be configured manually for testing.
As homelabs evolve from hobbyist experiments into critical personal infrastructure — hosting everything from password managers to health data dashboards — attention to foundational networking practices like split DNS becomes not just a convenience, but a necessity. It transforms a fragmented experience into a cohesive one, where the boundary between local and remote access feels less like a barrier and more like a seamless extension of the same network.
If you’ve ever found yourself frustrated by inconsistent access to your homelab services, or maintained duplicate bookmarks for “home” and “away” modes, split DNS may be the quiet fix you didn’t know you needed. It’s a reminder that sometimes, the most impactful improvements aren’t in the services we run, but in how we connect to them.
To stay updated on best practices for homelab networking, DNS security, and self-hosted infrastructure, follow official blogs from projects like Pi-hole [Pi-hole Blog], AdGuard Home [AdGuard Home], and Cloudflare Tunnel [Cloudflare Tunnel Documentation]. These sources regularly publish updates on recent features, security advisories, and configuration guides.
Have you implemented split DNS in your homelab? What challenges did you face, and how did it change your experience? Share your setup, tips, or questions in the comments below — and if this article helped you solve a hidden networking issue, consider sharing it with others in the self-hosting community.
Worth a look