Split-DNS capture: say where each observation was taken

Two people troubleshoot the same split-DNS problem and produce different resolver addresses. One used a lookup tool, one captured packets on the adapter, and a third read the client's own diagnostics. None of them is lying, and none of them is describing the same stage. Naming the observation point turns a contradiction into a map.

One lookup, several observation points

For a single internal name, there are at least five places to look: the application and the resolver API it calls, the effective domain policy on the client, an adapter or filter capture, a controlled gateway boundary, and the resolver that actually receives the query.

Each one answers a different question, and none of them alone proves where the query went.

An adapter capture shows packets, not intent. It does not tell you which resolver the client selected, and an empty capture can mean a cached answer or a different resolver API rather than a dropped packet. Treat each observation as evidence about one stage. Then assemble the stages into a path.

The client's filter sits between app and wire

A VPN client with split DNS applies domain matching before the packet leaves the machine. Names in the tunneled suffix go to the internal resolver; everything else goes to the local one. The filter is policy, and policy can differ by platform and client version.

Cisco's Secure Client split-DNS guidance covers domain matching and the Windows filter, and it separates what an app sees when it uses the native resolver API from what a tool like nslookup sees. Those distinctions are the point.

Begin from the effective profile and one ordinary application lookup. Any test that names an explicit server is a deliberate detour; use the client's own diagnostics to explain it, and do not let it become the acceptance criterion.

nslookup takes a different path than the app

nslookup builds its own DNS query and can bypass the operating system's resolver policy. That makes it a useful tool for asking a specific server a specific question, and a misleading tool for testing what an application will experience.

On Windows, the name resolution policy table decides which suffix uses which server. Reading it shows the policy the application will follow, which is often the missing piece.

Read the policy and then ask the same question through the normal resolver:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Encrypted resolvers hide the query, not the connection

A browser with its own DNS-over-HTTPS resolver is another case entirely. The query leaves inside TLS, so a packet capture shows a connection to a resolver address but not the name being asked for.

Work out the browser's managed policy first, then compare it with an operating-system lookup. A browser allowed to pick its own resolver may never see the split-DNS policy at all.

The same caution applies to any client that ships its own resolver. A capture that identifies the remote connection is not evidence about the query name. If you need the name, get it from the resolver's own logs or from the application's diagnostics, with the privacy rules that apply.

Compare with a labeled test

Choose an approved internal name for testing, plus a public name that carries no sensitive meaning. For each, log the time, the record type, the answer, and the policy you expected.

Where permitted, compare the resolver's receipt with one narrow client or gateway observation:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Never send private names to unrelated public resolvers just to create a comparison, and redact anything you share. Finally, separate a correct DNS answer from the service connection that follows: the resolved private address still needs a route and application authorization.