Quick brain-snap: you connect to a VPN, type intranet.company.local, and — boom — your DNS query goes out to the public internet instead of your internal DNS. Oops. That’s a DNS leak in action. It happens more often than teams admit.

This piece is a different take: less textbook, more toolbox. You’ll get conceptual clarity, deployable patterns, a troubleshooting matrix, and a short “war story” so this sticks. No fluff. Just the parts you’ll actually use.

Image Credit: Unsplash under Creative Commons

What this guide gives you (fast)

• Clear definition: what split DNS is and why it matters for VPNs.

• Four deployment patterns with pros/cons.

• Config notes for clients, appliances, and cloud.

• A troubleshooting matrix — copy/paste ready.

• A short real-world scenario and checklist.

• 3–4 FAQs and a final CTA.

If you want code snippets or platform-specific commands, I’ll add them — say which OS or VPN product and I’ll tailor it.

Split DNS, in one sentence

Split DNS means resolving internal domain names (example: corp.internal) using your internal DNS servers while letting public names (example: google.com) resolve via public DNS — all while connected through the VPN.

Simple? Yes. Tricky? Also yes. Because endpoints, VPN clients, OS resolvers, and cloud networks all behave differently.

Why split DNS matters for VPNs (and why you should care)

• Security: Leaking internal DNS queries can reveal what resources your users try to reach. Attackers can use that intel.

• Functionality: Internal hosts often depend on internal DNS zones for service discovery (SVC, LDAP, Kerberos). If DNS fails, apps fail—often silently.

• Compliance: Some regulated systems must keep name resolution within certain jurisdictions. Public DNS could violate that.

• Performance: Local DNS is sometimes faster for internal names than forcing everything through a tunnel.

And one more—human cost: users calling IT at 2 AM because the intranet site “doesn’t work” while email works fine. Not ideal.

Four practical split-DNS patterns (pick one based on reality)

Below are patterns I use in the field. Choose by constraints: client control, scale, cloud vs on-prem, and platform diversity.

Pattern A — VPN pushes internal DNS to client (Classic)

How: VPN server sends DNS server(s) and search domain(s) to the client during connection (DHCP option, push "dhcp-option DNS x.x.x.x" in OpenVPN).
Good when: You control client configs and have a manageable user base.
Pros: Simple, reliable for most internal lookups.
Cons: Can conflict with OS-level resolvers (Windows split-brain) and modern resolver managers like systemd-resolved.

Pattern B — Conditional forwarding at network DNS (Resolver-level split)

How: Public DNS (e.g., cloud or ISP) forwards a specific internal zone to your internal DNS server or a VPN gateway.
Good when: You don’t control all clients (BYOD) or you prefer central control.
Pros: Minimal client config. Works well with cloud VPCs.
Cons: Requires DNS server changes and can expose forwarding targets if misconfigured.

Pattern C — DNS proxy on the VPN gateway (Intercept-and-forward)

How: VPN gateway runs a DNS proxy that inspects the query and forwards internal zones to internal DNS servers and others to public resolvers.
Good when: You need tight control and can route DNS through the gateway.
Pros: Centralized, easier to monitor.
Cons: Single point of failure; adds latency if poorly sized.

Pattern D — Client-side resolver configuration + split tunneling rules

How: Managed endpoints get a resolver configuration that routes only internal domain queries through the VPN tunnel (policy-based routing or DNS-over-TLS to internal resolver). Public names use local ISP.
Good when: Advanced endpoint management, granular control required.
Pros: Least bandwidth usage over VPN; reduces gateway load.
Cons: Harder to scale; relies on endpoint compliance.

Quick decision primer: which pattern to pick?

• You control endpoints, need simplicity → Pattern A.

• BYOD or non-managed devices, want central control → Pattern B or C.

• Want minimal tunnel load, and endpoints are trustworthy → Pattern D.

The resolver reality: OS quirks you must know

• Windows: Uses DNS suffixes and a per-interface resolver. Push DNS from VPN can work, but Windows may prefer the first interface DNS or cache stale entries. Use DNS suffix search and consider netsh interface ip set dns automation for managed clients.

• macOS: scutil and networksetup control resolvers. Order matters.

• Linux: systemd-resolved, resolv.conf, and NetworkManager interact. On modern distros prefer systemd-resolved config via resolvectl or NetworkManager’s DNS toggle.

• Mobile (iOS/Android): Behavior varies. iOS supports per-VPN DNS via NEVPN; Android support depends on the client and OS version.

Test each major client family you support. Don’t assume parity.

Config snippets & patterns (conceptual, copyable)

OpenVPN server push (classic):

WireGuard + systemd-resolved (client-side):
Set DNS = 10.10.0.10 in the WireGuard config and add Domains = corp.internal in systemd-resolved drop-in.

Bind9 conditional forwarder (server-side):

Adjust syntax per resolver (Unbound, PowerDNS, etc.).

Troubleshooting matrix (copy this into your runbook)

Mini scenario (real-world, brief)

A company moved developer VMs to a cloud VPC and used VPN Pattern A (push DNS). Devs on macOS sometimes couldn’t reach internal package registries. Investigation: systemd-resolved on Linux and macOS resolver priorities differed; macOS kept local resolver first. The fix: switch to Pattern B — conditional forwarding at a cloud resolver paired with a lightweight DNS proxy on the gateway. Result: fewer client changes, and internal package registry access stabilized.

Lesson: sometimes central resolver-level fixes beat client-side patching.

Security considerations & gotchas

• DNS over VPN but not tunneled: If you push an internal DNS server but don’t route DNS packets through the tunnel, queries can leak. Ensure DNS packets follow the tunnel path.

• IPv6: Many setups forget IPv6. Ensure internal zones are not resolvable via an IPv6 path that bypasses the tunnel. Consider disabling IPv6 on VPN interfaces or ensure internal resolvers handle v6 properly.

• Split tunneling & data exfil: Split DNS plus split tunneling creates complexity. Make sure sensitive apps and services don’t fall back to public networks.

• Logging and privacy: Centralized DNS proxies improve logging and detection but increase data you must secure. Balance visibility with privacy regulations.

Short rollout playbook (copy-paste checklist)

1. Inventory internal zones and services.

2. Choose a split-DNS pattern (A/B/C/D).

3. Pilot with 5–10 users on different OS families.

4. Validate: dig, nslookup, resolvectl, ipconfig /flushdns.

5. Test failure modes: VPN drop, gateway reboot, client reconnect.

6. Monitor logs for DNS queries to public resolvers that should be internal.

7. Gradual roll-out: department by department.

8. After 30 days, deprecate old DNS configs and document the architecture.

LSI keywords (naturally relevant for SEO)

split-horizon DNS, conditional forwarding, DNS leak protection, VPN DNS push, internal DNS resolution, systemd-resolved split DNS, wireguard DNS, OpenVPN push dhcp-option, DNS proxy gateway, IPv6 DNS leak

FAQ

Q1: Will pushing DNS from the VPN always fix leaks?
Not always. OS resolver behavior and IPv6 can still cause leaks. Pushing DNS is a strong fix for managed clients but validate across platforms.

Q2: Should I use DNS-over-HTTPS/TLS for internal DNS?
You can, but it adds complexity. Encrypted DNS can be tunneled through the VPN or terminated at a gateway. For internal names, prefer direct, authenticated internal resolvers unless you have a clear need.

Q3: How do I test DNS leakage?
Connect VPN, run dig example.corp.internal @<internal-dns>, then dig example.corp.internal @8.8.8.8. Also intentionally kill the VPN client to see whether queries leak to the ISP.

Q4: Is split DNS compatible with Zero Trust architectures?
Yes. Zero Trust emphasizes identity and least privilege; split DNS is about resolving names correctly. They complement each other—use split DNS to ensure identity-bound services remain discoverable.

Final thought (and a tiny dare)

Split DNS is boring until it breaks. Then it is urgent, embarrassing, and noisy.

Here’s a tiny dare: pick one internal name that often breaks (a mail server, a package registry). Implement a quick test that runs daily and alerts you if that name resolves publicly. You’ll sleep better. You’ll reduce tickets. And you’ll feel smugly prepared.

Want me to generate a platform-specific roll-out (Windows + macOS + Linux + iOS/Android) with exact commands and monitoring checks? Tell me your VPN product (OpenVPN, WireGuard, commercial provider), and I’ll draft it now.