Network & Infrastructure / DNS, DNSSEC & Service Discovery
Split-view DNS and answers from the wrong resolver context
An internal service name resolves to a public address for some VPN users. Their query source or resolver selection may place them in a different DNS view.
Environment and inputs: Authoritative and recursive DNS infrastructure; BIND examples are conceptual and require release-matched configuration. Diagnostic/design example; not tested on production equipment.
Collect the evidence
Record client resolver configuration, effective query source, matched view and authoritative answer for each access path. Include VPN routing and any forwarding resolver that changes source identity.
Explain the result
Views select answers using configured context, not the user's intended location. A forwarded query can arrive from a resolver address that matches a different policy than the original client.
Plan the fix
Align resolver distribution, conditional forwarding and view matching with the supported access design. Avoid duplicating conflicting records across views without documenting ownership and update behavior.
Check the result and rollback
Test office, VPN and public clients, including expected nonvisibility of internal records. Restore prior view rules if private data becomes externally visible or valid internal paths receive public-only answers.