When you run a DNS leak test, the results page may suddenly list several unfamiliar server addresses — some labeled with an ISP name, others with different cities — and it is natural to ask: I have already adjusted my network settings, so why are DNS requests still going through these servers?
The truth is, seeing multiple DNS addresses does not necessarily mean a leak. What actually matters is whether domain name resolution requests are routed through any server you did not intend to use, and whether that traffic is encrypted in transit.
Below we start with how to read the test results, then walk through how to configure DNS in Chrome, Edge, Firefox, and Windows.

To troubleshoot, open ToDetect's DNS leak test page and check the DNS servers currently in use, their IP addresses, and the ownership information attached to them. Focus on three questions:
• Does the server ownership match what you expected? If you have already pointed your system at a specific DNS provider but a resolver you do not recognize shows up, you need to trace where it comes from.
• Has an IPv6 address appeared? IPv6 on its own is not a leak, but it may run on a different DNS configuration from IPv4.
• Do the results line up with your network settings? Several servers may all belong to the same public DNS provider, so the number on its own tells you nothing.
Save the results of your first test so that you have something to compare against after you change your settings.
Chrome supports DNS over HTTPS (DoH), which encrypts domain name resolution requests inside an HTTPS connection.
Open Chrome and go to Settings → Privacy and security → Security, where you will find "Use secure DNS".
Turn it on and pick a provider that supports secure DNS, or paste the DoH address of a provider you trust — for example: https://cloudflare-dns.com/dns-query
If you leave it set to "current service provider", whether encrypted resolution is actually used still depends on what that provider supports and on whether the browser successfully established the connection.
Once the change is in place, reopen the browser and run the test again. Keep in mind that secure DNS mainly protects requests made inside the browser — it does not mean every desktop application uses the same setting.
Edge supports secure DNS as well, and the setup is very similar to Chrome's.
Go to Settings → Privacy, search, and services, and look for "Use secure DNS to specify how to lookup the network address for websites" in the security section. The exact menu position varies slightly between versions, so you can also just type "secure DNS" into the settings search box.
Turn it on, then choose a provider that supports encrypted resolution or enter a custom DoH address. If the option cannot be changed, a device management policy or a system configuration is probably overriding it.
Run the test again once it is set. If unexpected DNS servers still show up, check the system network configuration instead of toggling the browser option on and off.
Firefox gives you finer-grained control over DNS over HTTPS.
Open Settings → Privacy & Security and look for "DNS over HTTPS". The two protection modes you will normally see are:
• Increased Protection: keeps DoH active with the provider you selected and only falls back to the system's resolver if that provider fails.
• Max Protection: always uses secure DNS, and shows a security warning page if the resolver cannot be reached — which can mean some sites simply fail to load.
For everyday use, start with "Increased Protection". If you would rather avoid falling back to plain DNS, try "Max Protection" — just keep an eye on network compatibility, since it is the stricter of the two.
We would not recommend disabling IPv6 or WebRTC just to chase down a DNS problem. The two cover different network functions, and switching them off blindly can break normal usage.
| Symptom | Likely cause | What to do |
|---|---|---|
| Your ISP's DNS shows up | The system is still using automatically assigned DNS | Check your Windows DNS settings and confirm that encrypted resolution is enabled |
| An IPv6 DNS address appears | IPv6 uses a separate DNS configuration | Check the IPv6 DNS settings and prefer a provider that supports encrypted resolution |
| Several DNS servers appear | A public DNS provider uses multiple nodes, or more than one resolver is involved | Verify who owns each server and confirm it matches what you expected |
| The browser looks fine but other apps do not | The browser and the system use different DNS settings | Review the system DNS configuration and any app-specific settings |
| Nothing changed after you edited the settings | The change did not take effect, a network policy blocks it, or the cache is interfering | Reconnect to the network, confirm the configuration, and test again |
One thing worth keeping in mind: swapping in a public DNS address does not mean encrypted DNS has been switched on. If your network also runs over IPv6, check the matching DNS configuration as well — and do not simply disable IPv6.
Once the changes are in place, open ToDetect's DNS leak test page again and re-run the test.
Put the two sets of results side by side and focus on three things: whether the ownership of the DNS servers has changed, whether any unexpected resolver is still in the list, and whether the IPv4 and IPv6 configurations are consistent.
If the results still look wrong, work through the browser's secure DNS, the system DNS, and the router settings one at a time. Checking them individually is far easier to debug than changing several options at once.
Also keep in mind that a standard DNS leak test mainly shows which servers took part in the resolution — the addresses alone cannot prove that every DNS query was encrypted.
Mainly the domains you looked up, when you looked them up, and related network information. As long as you are using HTTPS normally, the content of the pages you visit and your account credentials are not handed over simply because of a DNS leak.
Yes. Browsers, the operating system, and other applications may all resolve names in different ways, so the real answer lies in checking your configuration and running the test.
No. Public DNS providers often run multiple resolution nodes. What counts is whether those servers are the ones you expected.
Yes. Android and iOS configure DNS differently, so it is worth testing separately on Wi-Fi and on mobile data. Android's Private DNS usually uses DoT, while encrypted DNS on iOS may require a configuration profile or a supporting app.
One last note: Tracking down a DNS leak is not complicated — the tricky part is working out which layer, the browser, the operating system, or the network device, is responsible for which part of the resolution. Look at your results on ToDetect first, adjust the settings that actually apply to your setup, and then run the test again. That is far more reliable than simply swapping in a different DNS address.