Public DNS Working Does Not Mean Active Directory Can Be Found

The VPN connects, the browser opens a public site, and the laptop still cannot sign in to the domain. The usual conclusion is that DNS is fine because names resolve. It is not fine, and the reason is that a browser test exercises one lookup out of a chain that a domain-joined client needs. Domain discovery asks for service records first, then for the addresses of the controllers those records name, then for a route to the ports those controllers listen on. A public answer satisfies none of those steps.

The myth: names resolve, so DNS is finished

A public site resolving tells you that some resolver answered one A or AAAA query for a name in a public zone. Active Directory uses the same protocol for a different question: where are the domain's services, and which controller should this client use. The question is expressed as SRV records under a zone named after the domain, and a recursive public resolver has no reason to hold them.

When the record is missing, the resolver returns a negative answer, which is a valid DNS response rather than an outage. The client then falls back to cached controller information if it has any, which is exactly why a desktop can look fine for hours and fail after a reboot or a password change.

What a domain client actually asks, in order

For a domain such as corp.example, the generic locator query is _ldap._tcp.dc._msdcs.corp.example. The SRV answers name candidate controllers and their ports, and the client then needs address records for those hostnames before it can open a connection. Site-aware discovery adds queries under the site subdomain, and the responses determine which controllers are preferred rather than which one is mandatory.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Follow the chain in that order, from the network where the problem happens. A hostname that resolves to an unreachable address is a routing failure, not a DNS failure. A reachable controller whose locator records are missing is a DNS failure, not a routing failure. The two produce similar user complaints and completely different repairs.

Why a public resolver answers and still breaks sign-in

If the adapter hands the client a public resolver, public names work and the internal namespace does not. Adding a second public resolver does not help, because neither one holds the zone. Nor does the common "internal first, public second" list behave like a per-domain rule: a negative answer from the first server is a legitimate response, and the client does not retry the second server simply because the answer was empty.

Both internal resolvers, if you run two, must hold the AD namespace and be reachable from the client's current network. That is the part split-tunnel designs break: the VPN may carry the tunnel subnet while the internal resolver sits on a prefix the tunnel does not route, so the query goes out to a resolver that cannot answer it.

Windows also applies a name resolution policy that can direct specific namespaces to specific servers, and the adapter's displayed DNS addresses are not the whole story. Changing the adapter list without changing that policy can leave the effective configuration untouched, which is why a fix that looks applied has no effect.

Keep the tunnel's DNS and its routes in agreement

A VPN profile that pushes a resolver but not the prefix containing it creates a resolver the client cannot reach; one that pushes the prefix but no resolver leaves the client asking the local one. Treat the pair as one configuration item and check both after every profile change, because a reordered push or a new split-tunnel policy can separate them.

Also check what the client does with the pushed setting. Some clients apply the DNS server only to the tunnel interface and leave the physical adapter's resolver in place, so which one wins depends on the interface metric and the name being queried. If the internal answer only arrives when the physical adapter is disabled, that is the mechanism to fix, not the domain records.

Accept with a discovery call and one live operation

A useful acceptance test runs the locator query and then performs one real authenticated operation, such as opening a directory-backed share or requesting a ticket. Do it before the VPN transition and again after, on the same machine, without a reboot in between. Cached credentials and already-open sessions will happily make a broken path look healthy, so a successful desktop login is not the test.

Microsoft's DNS client recommendations draw the same line between resolving the internal namespace and forwarding public queries upstream, which is the arrangement to preserve when a VPN is introduced.

If the failure is only slow rather than failed, keep the delay separate from the diagnosis. A timeout during discovery can come from an unreachable controller, a blocked port, or a resolver that answers late, and none of them are proven by the wait alone. Capture the actual query, its answer, and the connection attempt before you change a resolver setting.