Split DNS with VPNs: What It Means

Imagine typing the address of your office file server into a browser while you are at home. Without a VPN, nothing happens, because the name exists only inside the company network. With the VPN connected, the page opens. Behind that small miracle there is a decision: which DNS resolver should answer the question "what is the address of files.corp.example?" If the answer is wrong, the page fails, even though the VPN shows as connected.

Split DNS is the name for the arrangement that gets that decision right. This article explains what it means, how it differs from the better-known split tunneling, how operating systems implement it, and how to test and troubleshoot it. It assumes you know that DNS turns names into addresses; if not, how DNS works is the place to start.

One name, two answers: the idea behind split DNS

The global DNS knows about public names. Organisations also run private names that are meaningless outside their walls: an intranet site, a build server, a printer queue, a database host. They keep these on their own resolver, and sometimes the same name has a different answer inside than outside. A website might point to a public web server for the world and to an internal copy for staff. This arrangement is often called split-horizon DNS, and it is a normal, long-standing way to run a network.

Problems start when a remote device needs both worlds at once. The laptop must still reach public sites, and it must also find the company's private names. A single resolver cannot do both well:

• If the laptop asks only the company resolver for everything, public browsing flows through the company, adds load and may be filtered by company policy.
• If the laptop asks only the home or café resolver, the private names do not exist and fail with "server not found".

Split DNS solves this by keeping a short rule list: names ending in these domains go to that resolver, everything else goes to this one. The decision is made per lookup, on the device, before any traffic is sent.

Split DNS and split tunneling are different things

The two terms sound similar, and they are often combined in a setup, but they answer different questions.

Question	Split tunneling	Split DNS
What is being divided?	Network traffic	Name lookups
Decided by	App, destination IP range, or route	Domain name suffix
Goal	Send only some traffic through the VPN	Ask the right resolver about each name
What goes wrong if misconfigured	Traffic leaves the tunnel unexpectedly or cannot reach a target	Names fail to resolve, or private names are asked of a public resolver
Typical user	Anyone with a VPN app that offers it	Company or self-hosted VPN setups

You can have split tunneling without split DNS: the VPN carries traffic for one office network, but all lookups still use the café resolver, so private names fail. You can also have split DNS with full tunneling, where all traffic uses the tunnel but different domains are answered by different resolvers inside it. Our article on what split tunneling is covers the traffic side in depth; this article covers only names.

How operating systems implement it

The idea is the same everywhere, but each system keeps its list in a different place. Knowing the names helps when you troubleshoot.

Windows. The Name Resolution Policy Table, or NRPT, maps a domain suffix to a DNS server. A VPN client or a company policy can add entries such as "anything ending in .corp.example goes to this resolver". When no rule matches, the adapter's normal DNS servers are used.

macOS. The system keeps multiple resolver configurations, and a domain-specific one can be attached to a VPN interface. Files placed under the resolver directory are another mechanism that technical users use to send one domain to one server.

Linux. With systemd-resolved, each network link carries a list of DNS servers and a list of "routing domains". Queries for those domains go to that link's servers. A domain written as "~corp.example" means "route this domain here, but do not use it for short-name expansion".

Android and iOS. Mobile operating systems expose less for hand-tuning. A VPN app or a device-management profile can request domain-specific resolvers, and the system applies them as part of the VPN configuration.

If you only use a consumer VPN app, you will rarely touch any of this. These mechanisms matter when a company, school or self-hosted setup is involved.

Following two lookups through a split setup

Here is a worked example. Maya is a consultant working from home. Her company VPN has one rule: names ending in .corp.example go to the resolver at 10.20.0.2 inside the tunnel. Everything else uses her home router.

1. She opens a browser and types wiki.corp.example. The system checks the rule list, finds the suffix match and sends the question through the tunnel to 10.20.0.2. The company resolver replies with a private address such as 10.20.5.14, and the page loads.
2. She opens a second tab with a public news site. No rule matches, so the question goes to her home router's resolver, which asks the public DNS and replies. The VPN is not involved in the lookup.
3. She types the short name wiki without a suffix. The system adds the search suffix .corp.example from the VPN configuration and tries wiki.corp.example. If the suffix list were missing, the short name would fail.
4. Her laptop tries to find a printer by the name office-printer.local. This name uses multicast discovery on the local network and never goes to a resolver at all, so the VPN rules do not touch it.

The details of step 3 explain a common complaint: full names work, short names do not. The VPN gave the device the resolver, but not the search domain.

Where split DNS shows up in real life

• Remote employees. The most common case. Staff reach internal sites and tools by name, while personal browsing uses the home resolver.
• Students and researchers. A university may expose library and lab services by name only on its own network. A VPN with split DNS lets a student reach them while the rest of the connection stays local.
• Home labs. Someone running a NAS, a media server and a home-automation hub often gives them private names. A self-hosted VPN with split DNS resolves those names when the owner is away, without sending all web lookups home.
• Small offices. A shop with a local file server and a cloud accounting tool wants the server name to work from a staff member's laptop at home.
• Multi-site organisations. Each office has its own private names, and VPN links between them use per-domain rules to send each lookup to the right office.

If a business gives you VPN credentials, ask whether private names should work. If so, a split DNS rule list is part of the setup. See also business VPN vs personal VPN for how these environments differ from consumer use.

How to check what is configured

You do not need to guess. Each system can print its resolver table.

1. macOS: open Terminal and run scutil --dns. Look for resolver entries that list a domain and a nameserver. A resolver with "domain : corp.example" is a split rule.
2. Linux with systemd-resolved: run resolvectl status. Each link shows its DNS servers and its DNS Domain list. Domains starting with ~ are routing-only.
3. Windows: in PowerShell, run Get-DnsClientNrptPolicy to see rules, and ipconfig /all to see the DNS servers per adapter and the DNS suffix search list.
4. Test a name against a specific resolver: nslookup wiki.corp.example 10.20.0.2 asks that resolver directly. If it answers there but not through the normal path, the rule list is wrong or missing.
5. Test the leak side: from the same device, look up an internal name while disconnected from the VPN and note what is asked and where. A private name sent to a public resolver reveals its existence, which is information some organisations treat as sensitive.

Keep the output of these commands when you ask an IT team for help. It tells them in a minute what would take an hour of back-and-forth.

What can go wrong

• The rule list is incomplete. A new internal domain was added to the network but not to the VPN profile, so it fails while the old ones work.
• Overlapping domains. A public name and a private name share a suffix, for example both under corp.example, and lookups for the public one go to a resolver that cannot answer.
• Resolver reachable only in the tunnel. The private resolver address, usually a private range under RFC 1918, is unreachable when the VPN drops, so lookups time out and apps appear to hang.
• A network that rewrites queries. Some hotel or captive-portal networks intercept DNS and break split rules. If names resolve on mobile data but not on hotel Wi-Fi, suspect the network.
• Competing DNS settings. Android's Private DNS or a browser's built-in encrypted DNS can bypass the system rules and ask a public resolver about private names. The result is "server not found" for internal sites.
• Stale cache. The system or browser remembers a failed lookup. Flush the DNS cache or restart the app after fixing the rule.
• Search domain missing. Full names resolve, short names do not, as in the example above.

Privacy and security angle

Split DNS is a convenience for reaching private resources, not a privacy feature in itself. Two things are worth noting.

First, the resolver you ask sees the name you ask about. With a correct split, the company resolver sees only company names, and your home or public resolver sees the rest. This is sometimes better for privacy than sending everything to the company, and sometimes worse than sending everything through a trusted tunnel. Neither is a universal rule.

Second, a rule error can disclose names. If an internal host name is asked of a public resolver, that resolver learns the name exists, and so might anyone watching the local network, because plain DNS is not encrypted. Names like "payroll-db" or a project code name are informative even when the host is not reachable. This is a form of the issue described in what a DNS leak is: lookups that go where you did not intend.

For remote access in general, NIST's telework guidance, SP 800-46, stresses secure configuration of remote access and the endpoint, which includes checking that DNS behaves as designed rather than assuming it does.

Do you need split DNS with a consumer VPN?

Probably not. A consumer VPN app is normally designed to send all traffic and all lookups through its tunnel to one resolver. There are no private names to reach, so there is nothing to split. The thing you would want to check there is the opposite one: that no lookups are escaping the tunnel.

Split DNS becomes relevant if you run your own server, join a company or school VPN, or manage a router with local names. If you use the free VPNclient app with a prepaid pass from the pricing page, the app's default behaviour is what applies, and you do not need to configure domain rules.

Summary

Split DNS lets a device choose a resolver by domain name: private names go to the private resolver through the VPN, everything else goes to the normal one. It is not the same as split tunneling, although the two often appear together. Operating systems implement it through rule tables such as NRPT on Windows and routing domains on Linux. When something fails, print the resolver configuration, query the private resolver directly, and look for missing suffixes, overlapping domains and competing encrypted DNS settings.