Different DNS answers can be intentional
Split DNS returns different records for the same name depending on the query's context. Internal clients might receive a private application address, while public clients receive an internet-facing endpoint. The arrangement is useful only when the intended clients reliably reach the intended resolver and view.
BIND views match configured criteria, including client and destination addresses, and the first matching view determines the available zone data. A recursive resolver querying an authoritative server also has its own source identity. The address of the end user's laptop may never be visible at that later boundary.
Setup: map the resolution chain
Document the client, operating-system resolver configuration, local stub, VPN or office resolver, forwarding rules and authoritative service. Include browser-specific encrypted DNS where it is permitted, because it can bypass the operating system's expected resolution path.
Record which answer is intended for internal, VPN and public clients, including A and AAAA records. Private and public zone copies need owners and change procedures. A change to one copy does not automatically update the other, and cached previous answers can coexist with new authoritative data.
Follow one name from the affected client
- Inspect the resolver actually configured on the client. Query the application name through that default path and record the full answer, response code, resolver address and timestamp.
- Compare a direct query to the expected internal resolver with a query through the default path. Use explicit examples such as
dig @192.0.2.53 app.example A, substituting an authorized resolver; documentation addresses do not identify a real service. - At the BIND boundary, inspect view order,
match-clients, destination matching and forwarding behavior. A broad earlier view can capture queries before a narrower later view is considered. - Compare authoritative answers and cached answers separately. Check A and AAAA consistently, since a working private IPv4 answer can coexist with an unintended public IPv6 destination.
Illustrative incident: VPN users use a public resolver
In this illustrative scenario, office computers resolve an application privately, but VPN users receive its public address. The administrator edits the private zone repeatedly because the same hostname appears in every report. The affected clients are actually using a resolver outside the split-DNS path.
The team verifies the client configuration, corrects the approved VPN DNS policy and tests both address families from a connected client. It also confirms that public users retain their intended answer. This example demonstrates path selection, not a measured service outage or a real client environment.
Diagnostic table
| Observation | Inspect | Boundary |
|---|---|---|
| Direct internal query works | Client's default resolver chain | Client configuration or forwarding |
| Wrong view serves an answer | Source seen by BIND and view order | View selection |
| Only some clients remain wrong | Cache age and resolver choice | Cached or alternate resolution |
| Browser differs from command line | Browser DNS and proxy settings | Alternate application path |
Correct and validate both populations
Repair the evidenced client policy, forwarder, view ordering or zone data. Validate BIND configuration and zone syntax using the installed tools before activation. Preserve the previous configuration and avoid exposing recursive service publicly while changing match criteria.
Re-test from internal, VPN and external networks with the same query set. Resolve the name and then perform a representative application connection; DNS correctness alone does not establish routing, TLS or authorization. Record cached-answer expectations instead of promising that every resolver changes instantly.
Operating SOP
Maintain an ownership map for zone copies, forwarding rules and client DNS policies. Monitor private and public answers from representative locations. The SOP should include view-matching evidence and application acceptance checks so future migrations do not rely only on a successful query issued from the DNS server itself.
See Clouvenix network architecture for implementation and operational handover.
Technical reference
Official reference 1. Documentation checked 19 October 2026; confirm behavior for your deployed edition and version.