VPN DNS, DoH, and Private DNS: a practical guide

Why DNS still matters when your VPN is on

When you open a site by name, such as example.com, your device first needs its IP address. It asks a DNS resolver to look up the address. That request is part of connecting to a service, but it is not the page itself: DNS does not carry your password or message text. Domain names can still reveal something about network activity, so it is worth understanding how these requests travel.

A VPN creates an encrypted tunnel between your device and a VPN server, but it does not answer every question about DNS. The destination for DNS requests, the transport used, and the resolver that receives them all matter. A VPN app commonly sets a DNS route or uses a resolver available through the tunnel, but exact behavior depends on the app, operating system, profile, and settings. A “connected” indicator alone does not tell you which resolver handled a particular request.

This guide focuses on DNS behavior and settings. For a broader connection checklist, see how to check a VPN connection.

Who can see DNS requests?

With ordinary DNS, your device sends a request to a resolver. If the transport is unencrypted, parties along the route may be able to observe or interfere with it. That is a statement about what may be possible, not proof that every network operator records queries.

The resolver itself receives the request so it can find the answer. Choosing a different resolver changes which organization you trust to process DNS; it does not remove the need for trust. Its data-handling policy, security practices, and any onward forwarding matter. DNS resolution can involve caches and additional servers, so the process may extend beyond the first resolver your device contacts.

When a VPN is working as intended, ordinary DNS traffic may travel inside the tunnel, making it unavailable as plaintext to the local Wi‑Fi network or access provider. The VPN operator or the resolver may still be in a position to process the request. If an app sends DNS over a separate encrypted channel, such as DoH, its route may differ. You cannot determine the route merely from the VPN status icon.

VPN DNS, DoH, and DoT are different things

DNS through a VPN describes a route. The device sends a DNS request to a resolver through the VPN tunnel. The request may use ordinary DNS transport, while the tunnel protects the leg between the device and VPN server. Which resolver receives it depends on the service and configuration.

DNS over TLS (DoT) uses TLS to protect the connection between a DNS client and resolver. Android’s Private DNS setting is associated with DoT. The protocol is specified in RFC 7858. DoT protects the channel to the configured resolver, but the resolver still processes the query.

DNS over HTTPS (DoH) carries DNS requests over HTTPS, as specified in RFC 8484. A browser or system may use a DoH resolver independently of the DNS settings installed by a VPN app. HTTPS protects the connection to that resolver; it does not prevent the resolver from handling the request.

These are different layers, not interchangeable names for one feature. A VPN provides a network tunnel; DoT and DoH protect DNS transport to a particular resolver. DoH or DoT can operate inside a VPN tunnel, so using one does not automatically cancel the other. But encryption alone does not prove that a request went to the resolver you expected or that settings are conflict-free.

Why your browser may not use the VPN’s DNS setting

Some apps rely on the operating system’s DNS configuration; others can contact a resolver directly. A browser with Secure DNS or DoH enabled may use its own provider even when the VPN app has set device-level DNS. The name may then be resolved by a different service than you assumed.

The details vary by implementation. Browsers may offer an automatic mode that enables secure DNS under certain conditions and a custom mode that uses a selected provider. Automatic mode may fall back to system DNS if there is a problem. In a stricter custom mode, an unavailable resolver may instead cause a lookup error. Labels and behavior can change between versions, so check the documentation for your browser version.

Other sources of separate DNS behavior include apps with their own networking libraries, device-management policies, and filtering tools. Android’s developer documentation warns that apps which customize DNS transport or bypass system defaults can create unexpected configurations. A test in one browser therefore does not necessarily describe every app on your device.

A step-by-step settings check

Start with a specific question: which resolver handles requests from your browser or device while the VPN is connected? Do not enter passwords into test pages or install unfamiliar “DNS tester” apps just to investigate. Begin with settings already on your device.

Record the starting state. Connect the VPN and note whether ordinary browsing works. Avoid changing several settings at once; otherwise, it will be harder to identify the cause of any change.
Review the VPN configuration. Check whether the app exposes DNS, filtering, or profile options. Do not paste in server addresses or configuration values from unverified posts. If an administrator or support team provided your profile, ask what DNS behavior it is expected to use.
Check system DNS. On Android, look for Private DNS in the network settings; the exact menu path varies by manufacturer and version. Automatic mode and a specified provider hostname are different choices. Organization-managed devices may restrict the setting.
Check the browser separately. Look in privacy or security settings for Secure DNS, DNS over HTTPS, or a similar option. Note the mode and provider. You can temporarily compare system DNS with protected DNS, but change only one setting at a time.
Compare with the VPN disconnected. Run the same test on the same network once with the VPN and once without it. A difference is useful evidence, but does not by itself prove a leak or rule one out: the test may cover only one browser’s requests.
Check more than one app. If your browser and another app behave differently, they may use different DNS mechanisms. Do not generalize to the whole device from one test page.
Undo a change if connectivity gets worse. If sites stop loading, revert the last change, reconnect the VPN, and test again. Keep the setting names and error text available if you contact support.

For a wider diagnostic process, follow how to check a VPN connection. If you intentionally exclude some apps from the tunnel, also review VPN split tunneling: DNS behavior can differ with an app’s route.

What a DNS test can—and cannot—tell you

A DNS test site typically reports the resolvers it observed while running its own checks. That can be useful, but it is not a complete audit of your device. Results can depend on cached answers, the browser, the test itself, split tunneling, IPv4 and IPv6, and whether an app uses its own DoH service.

If the test shows a resolver you did not expect, do not automatically treat that as proof of a leak. First find out which request was tested and which app sent it. A device may use more than one resolver—for example, the browser and operating system may handle requests separately. A test may also show infrastructure shared with a partner or a common network provider; a name alone does not establish ownership or the full route.

A result that looks expected is not proof that every request on the device follows the same path either. For a useful comparison, repeat the test after changing one setting and in the apps that matter to your use case.

Common symptoms and safe troubleshooting

Sites stop loading after enabling Private DNS or DoH. Check whether the selected resolver is reachable on the current network, then temporarily return to the previous mode. This can help distinguish a DNS problem from a VPN-server or general internet problem. Avoid turning off every protection at once.

A browser works, but an app does not. The browser may use its own DoH provider while the app relies on system DNS, or the reverse. Check both sets of settings. If you recently enabled filtering, its rules may also explain the difference.

The error happens only with the VPN connected. Reconnect to the VPN and, if your service offers them, try another available profile or server. Avoid entering unknown DNS addresses manually: doing so can send queries to a third-party operator and make the issue harder to diagnose.

The result changes between Wi‑Fi and mobile data. That can happen because system settings, resolver reachability, and network rules may differ. Compare results under consistent conditions and record which connection you used.

If internet access stopped after a DNS change, first undo that change. The public Wi‑Fi guide also covers useful checks when testing on hotel, café, or airport networks.

A practical approach to DNS settings

For most users, a sensible first step is to leave the VPN and device DNS settings at their defaults unless there is a specific reason to change them. If you choose DoH or DoT, choose the provider deliberately, read its query-handling policy, and understand what happens if the resolver becomes unavailable.

Do not enable several new features at the same time. First observe how the VPN behaves with system DNS, then review the browser’s settings separately. If an error appears after a change, revert the last setting. This approach cannot guarantee complete privacy, but it can help you understand the route and avoid accidental redirection.

Protected DNS does not hide everything you do online, and it does not replace HTTPS. It changes or protects the domain-lookup stage through a selected channel. For a broader view of routing and connection behavior, use the VPN connection checklist: DNS is one part of the picture.

VPN and DNS: how encrypted DNS settings work