DNS in one everyday example
When you enter a name such as example.com, the app needs address records before it can connect. It sends a DNS question through the resolver setup available to that app and network. The answer might be an IPv4 address, an IPv6 address, another name to follow, or a response saying that no matching record exists.
This is why a DNS problem can look different from an internet outage. A direct connection to an already known address may still work while new names fail to resolve. It is also why a cached answer can keep working for a while after a resolver or authoritative service changes.
The four roles in a typical lookup
- Application or stub resolver
- Starts the question on the device, often through operating-system or application DNS behavior.
- Recursive resolver
- Finds or caches the requested answer on the client’s behalf. It may be operated by an ISP, public DNS provider, organization, or VPN.
- Authoritative server
- Publishes answers for a DNS zone; it is the source the recursive resolver ultimately consults when the answer is not cached.
- Cache
- Stores an answer for its allowed lifetime so later lookups can be answered without repeating the full process.
The simplified path is device → recursive resolver → authoritative DNS → resolver → device. In real deployments, a home router may forward requests, large resolvers use anycast and multiple sites, and an application or browser may use encrypted DNS independently of the system setting. A label in a result can therefore describe upstream infrastructure rather than the literal server address shown in Android.
Continue with How to check a VPN using IP and DNS, compare it with Learn IP and network basics, or use IP Finder for Android for the next practical step.
Who chooses the resolver path
On an ordinary network, Android can learn DNS configuration from Wi-Fi or the mobile carrier. Android Private DNS can select an encrypted resolver. A browser may have its own secure-DNS setting. An organization can manage DNS, and a VPN can provide resolver configuration or carry DNS through the tunnel.
These layers can interact. If a test shows an unexpected provider, first write down the active Wi-Fi or mobile network, Android Private DNS setting, browser secure-DNS setting, VPN state, and split-tunneling rules. The result becomes understandable only when compared with the path that configuration was supposed to create.
The protocol details in this guide follow RFC 1034 — Domain Names: Concepts and Facilities and RFC 1035 — Domain Names: Implementation and Specification; use those primary specifications when you need exact terminology or edge-case behavior.
What a DNS leak test observes
A typical leak test causes the device to request unique names controlled by the test operator. When resolver infrastructure asks the authoritative service for those names, the operator can record where those requests appeared to come from. The test then associates that infrastructure with a provider or country where possible.
The test is observing resolver-side requests, not reading a complete history of everything on the phone. Caching, forwarding, anycast, provider naming, application-specific DNS, and timing can affect what appears. A single resolver name also does not tell you the transport path of every application packet.
What “DNS leak” means in VPN context
The word “leak” is meaningful only against an expected setup. If a VPN states that it sends DNS through the tunnel to its own resolver, continued observation of the underlying ISP’s resolver may be unexpected. If the VPN intentionally allows a user-selected resolver or split-tunneled app, a third-party resolver can be consistent with the configuration.
How to run a useful before-and-after check
- Create a baseline
Disconnect the VPN, keep the intended Wi-Fi or mobile network active, and record the public IP, network organization, and DNS result.
- Connect the VPN
Wait until Android reports the VPN active. Do not switch the underlying network during the comparison.
- Run fresh checks
Repeat the public-IP and DNS observations. Record every resolver shown, not just the first label.
- Compare with the expected design
Check the VPN provider’s DNS, split-tunneling, and protocol documentation. Repeat an unexpected result after reconnecting.
A changed public IP and expected DNS resolver are useful evidence that those two test paths changed at that moment. If one result stays unchanged, investigate the relevant setting rather than assuming the entire VPN failed.
Troubleshoot an unexpected resolver
- Repeat with the same browser or app; different applications may use different DNS behavior.
- Check Android Private DNS and any browser secure-DNS setting.
- Review VPN split tunneling and whether the test app or browser is excluded.
- Reconnect the VPN or change server, then run a fresh test instead of relying on a cached page.
- Compare the resolver organization—not only the displayed country—with the provider’s documentation.
- If the expectation remains unclear, send the baseline, VPN result, time, and configuration to the VPN provider.
What the test cannot prove
A DNS leak test does not inspect every application, every protocol, or every packet. It does not prove that traffic content is encrypted, that the VPN implementation is secure, that no non-DNS traffic bypasses a tunnel, or that the user is anonymous. It also cannot repair the configuration it observes.