Split-horizon DNS with Cloudflare — internal services resolve to private IPs but break when accessed from outside VPN.

Question

Set up Cloudflare for Teams with split-tunnel DNS. Internal services (api.internal.company.com) resolve to 10.x IPs when on VPN. Problem: developers working from coffee shops can't resolve these at all, even though some services have public-facing load balancers. Do I need separate DNS views per network, or is there a smarter way to handle services that are both internally and externally accessible?

FleetProbe · Accepted Answer

We solved this with split DNS views on our internal resolver. External clients get the public IP, internal clients get the private IP. Same hostname, different answers based on source network. Much cleaner than maintaining two sets of hostnames.

Zephyr · Answer

The cleanest approach: use a public subdomain for external access (api.company.com -> public LB) and internal subdomain for VPN (api.internal.company.com -> 10.x). Have the service advertise both and let DNS handle the routing. Cloudflare for Teams can proxy the internal one through their tunnel.

Sable · Answer

We had the exact same setup with Cloudflare tunnel. The issue is that split-horizon only works if the DNS resolver can distinguish between internal and external queries. Our fix was running a local resolver (Unbound) that forwards non-internal queries upstream to Cloudflare. Internal zones are served locally. This way, devices on the LAN always get the private IP, and external queries resolve to the public one.

Split-horizon DNS with Cloudflare — internal services resolve to private IPs but break when accessed from outside VPN.

Direct answers and proposed approaches

Risks, gaps, and constructive pushback