Testing Split DNS Without Leaking Internal Names

Asking a public resolver for an internal name leaks the name and skips the rule you meant to test. The query reaches a server you do not control, the answer comes from a namespace that had no business seeing it, and the result says nothing about whether split DNS works. Testing split DNS means testing the resolver path an application actually uses. That path is chosen by the operating system, by the domain list on the VPN profile, and sometimes by the browser.

Pick two names and predict both answers first

Ask the network owner for one documented internal test name, and choose an ordinary public name that says nothing about the organisation. Write down what should happen for each before running anything: the internal name should reach the tunnel's resolver and return an internal address, while the public name should resolve through whatever resolver the system normally uses. Those two predictions are the test, because without them any answer can be rationalised afterwards. Keep the pair fixed across runs so a later comparison means something.

Check the effective rules rather than the intended ones. The domain list attached to the VPN connection decides which suffixes go to which resolver, and a typo in that list produces a plausible but wrong split. On a managed device, use the administrator's diagnostic path, since local overrides can be reset by policy at the next check.

Record the prediction next to the observed answer in the same ticket. A test without a prediction cannot fail, and a test that cannot fail teaches nothing.

Test the path the application uses, not one server you chose

A command that names a resolver explicitly tests that resolver and nothing else. It tells you whether the internal server answers, which is useful, and it does not tell you whether an application sends the name there. Test through the normal path first: resolve the internal name the way an application would, then resolve the public name the same way. Only after that, query specific servers to find where the behaviour diverges.

Browsers complicate the picture, because secure DNS settings can bypass the system resolver entirely. A browser configured with its own encrypted resolver never sees the split, and the failure looks like a broken VPN profile. Check that setting before changing the tunnel.

Repeat the lookup after reconnecting if restoration is the question. An answer cached from before the reconnect can make a correctly restored split look better or worse than it is.

Record the answer category, not just success or failure

Write down which of four things happened: an internal address, a public address, a negative answer, or a timeout. Each has a different meaning. An internal address for the internal name is the expected success; a public address for an internal name suggests the query left the tunnel; a negative answer from the authoritative server points at a missing record rather than a routing fault; and a timeout indicates reachability trouble or a resolver that never received the query. Success and failure are too coarse to act on.

Account for cache before interpreting a missing fresh query, because a negative answer held in cache looks identical to a name that does not exist. Capture the response before clearing anything through supported controls, since the first answer is the evidence.

Interpret the two branches without guessing

If the internal name resolves correctly and the application still fails, the resolver did its job and the next suspects are routes and permissions on the resource itself. If the private name reached a public resolver, the split rule is not being applied to that lookup, so review the domain list and any browser policy with the owner of the namespace. Those two branches have different owners, which is why recording which one you saw matters more than recording that something broke.

Redact shared output while keeping the structure: which namespace, which rule, which answer category. A resolver response can carry internal addresses and hostnames, and a ticket is a durable home for both.

Then hand the result to the namespace owner with the two categories you observed and the names removed. That is a five-minute conversation instead of a week of speculation.