Split DNS intentionally gives different answers to different networks or clients. An internal user may receive a private server address while a public visitor receives a public endpoint. Diagnose which resolver and DNS view supplied each answer before treating every difference as propagation.
IN THIS ARTICLE
Gather the details you will need
Record the affected device, network, VPN state, resolver address and query time. Identify whether the organisation deliberately operates private DNS zones. Keep internal addresses and topology out of public support posts.
01 Diagnose different internal and public DNS answers for one hostname
- Query the hostname using the device's configured resolver, then compare with an approved public resolver and the authoritative public nameservers.
- Check whether a VPN, encrypted-DNS setting, browser secure-DNS feature or local hosts file causes the application to use a different resolution path from your command-line test.
- Ask the internal DNS administrator whether a private zone shadows the public domain. A locally hosted example.com zone may need records for public services that internal users still access.
- Correct the record in the intended view. Do not publish a private service publicly just to make an external DNS checker show the internal answer.
- After the change, refresh only the relevant local cache where supported and allow upstream cached answers to expire. Verify that the VPN or device actually uses the intended resolver.
02 Example: compare internal and public DNS views
From the affected network, query the same name and type against its approved internal resolver and an appropriate public resolver. Replace the resolver names with actual addresses or hostnames. Do not publish an internal-only service name to an outside resolver if it is confidential.
dig @resolver.internal.example portal.example.com A +noall +answer
dig @resolver.public.example portal.example.com A +noall +answerRead the result: Different answers may be intentional split DNS, such as a private address on the company network and a public entry outside it. Compare the result with the application's intended network path and certificate hostname. The difference alone does not prove either DNS view is wrong.
Check VPN-assigned resolvers, DNS suffixes and local hosts entries on the affected device. Coordinate corrections with the internal DNS administrator and the public DNS operator. Replacing a domain-joined server's internal resolvers with public ones can break directory and other private service discovery.
Confirm the expected result
Test from both an internal and external connection. Confirm each reaches its intended service, with valid certificates and the expected access restrictions. Include important mail and authentication names that share the shadowed zone.
If the problem continues
A successful public DNS check does not prove the internal view works. If only one browser differs, inspect its resolution and proxy configuration. If the entire office differs, investigate the network resolver and private-zone policy.
A common question
Should a private DNS answer be copied into public DNS so everyone sees the same result?
Only if the service is intended to be public and the address is publicly reachable. Deliberately different views can be correct. The goal is appropriate resolution for each audience, with access control at the service and network layers.