Split DNS Deployment Guide for Local and Remote Self-Hosted Apps

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Split DNS Deployment Guide for Local and Remote Self-Hosted Apps - Zima Store Online

The safe approach is to treat a staged split-DNS deployment with deterministic resolver scope, matched TLS identity, transition tests, and rollback as a sequence of observable gates, not a single command.

On a self-hosted apps behind local and remote reverse-proxy paths, the practical risk is the same app hostname must resolve to intentional local, VPN, and public endpoints without certificate or routing surprises. Record the current identity and recovery point, start with the least invasive discriminator, interpret pass and fail results before changing another variable, and stop when storage becomes unstable or the only recoverable copy would be exposed. The workflow below ends only after the original workload succeeds or the evidence reaches an escalation boundary.

Define names, views, and trust boundaries

Choose one fully qualified hostname per application and document the answer expected for trusted LAN, VPN, guest, and public clients. Keep the application identity and TLS name constant while the returned address changes; using unrelated internal names often breaks redirects, callbacks, bookmarks, and mobile clients.

A practical home-lab pattern is to return a private proxy address internally and a public proxy or tunnel endpoint externally. The one-name split-DNS design shows this one-name, two-answer design and highlights that DNS challenge validation can issue a certificate without making an internal service publicly reachable.

Decide which networks must never receive private records. Guest and IoT clients may need the public path or no answer at all, and the public zone must not expose private addresses or internal-only hostnames.

Deploy the local view without changing the public path

Lower relevant TTLs before migration, add the internal override on the chosen resolver, and query that resolver explicitly from a canary client. Verify A and AAAA records separately, because a correct IPv4 answer can be bypassed by a stale or public IPv6 answer.

Advertise the internal resolver through DHCP and the VPN configuration, then inspect the effective resolver on each operating system. Browser secure DNS, mobile private DNS, cached answers, and a manually configured resolver can bypass the intended view even when the local zone is correct.

Use the existing ZimaSpace split-horizon DNS configuration as the configuration boundary, while this workflow concentrates on deployment order and acceptance. Do not change public DNS, local proxy routing, and client resolver policy in one step; each layer needs a distinct pass or rollback result.

Align DNS answers with proxy and certificate identity

Open the hostname from the LAN canary and record the resolved address, route, TLS certificate name, response host, redirects, WebSocket behavior, and application-generated URL. Reaching a web page is insufficient if the request lands on the wrong virtual host or redirects to an IP address.

Repeat from cellular or another external network with Wi-Fi disabled. The address may change, but the hostname, certificate identity, login, and application data must remain consistent. If internal and external paths intentionally use different proxies, both must route the same host correctly.

Test VPN access from outside the home. If the VPN should receive the private answer but receives the public one, correct DNS assignment or split routing before adding another application override.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

Validate transitions and retain a rollback record

Move the canary between LAN, cellular, and VPN while recording query results after the TTL expires. Test a fresh browser session and an existing logged-in session so DNS success does not hide cookie, callback, or session behavior tied to a different host.

Restart the resolver and proxy once, renew the client lease, and repeat the path matrix. Confirm that unrelated public records and internal services retain their previous answers; a split zone that shadows missing public records is an incomplete deployment.

Deploy to other clients only after every view is deterministic. Roll back the internal override if clients cannot be kept on the intended resolver, the certificate identity diverges, or a private address leaks publicly; preserve query output and timestamps for the next attempt.