DNS leaks on team devices: how to test for one and fix it

Teams route research traffic through a proxy for good reasons and then assume the job is done. Often it is not. The browser or script may still ask the network's usual DNS resolver for every hostname, and that resolver is frequently run by your internet provider, which therefore receives a list of every site the team opens. That gap is a DNS leak. It matters most when staff research competitors, prepare a launch or work on confidential client projects, because the lookups show which sites were involved. Below: how a leak happens, how to test for one, and how to close it in code, on Windows, on macOS and on work phones.

What happens before every connection

Each visit starts with a question. Before connecting, the device asks a DNS resolver which IP address belongs to a name such as example.com, and only with the answer can the real connection begin. Unless someone changes it, the operating system sends those questions to whichever resolver the network handed out, often the internet provider's.

So a leak is a split route: the connection takes the proxy or VPN, but the lookups do not. The content of each page stays private, but the questions that name which pages you wanted reach your provider in plain text, and anyone able to read them can rebuild your browsing history.

Where leaks come from

• Names resolved on your side. The application resolves the hostname itself and only then passes the connection to the proxy, which never sees the lookup.
• Resolvers fixed in software. Some programs, and some routers, insist on a particular DNS server whatever tunnel is running.
• Fallback behaviour. Windows especially may ask several resolvers at the same time, including some outside the tunnel.
• IPv6 left open. When the tunnel only handles IPv4, IPv6 lookups can travel around it.

Test before you change anything

Measure rather than assume. Turn the proxy or VPN on, then open our DNS leak test; it lists the servers that really answered your lookups. A leak shows up as your own provider's name, or a resolver in your home country, in place of the proxy's. Our my IP tool completes the picture: a proxy-location IP alongside your real provider's DNS is the signature of a leak.

In code: let the proxy resolve names

For scripts, hand the lookups to the proxy. A Python job using SOCKS5 should use the socks5h scheme, where the closing h tells the client to let the proxy resolve hostnames:

import requests

proxies = {
    "http": "socks5h://USER:PASS@HOST:PORT",
    "https": "socks5h://USER:PASS@HOST:PORT",
}

r = requests.get("https://httpbin.org/ip", proxies=proxies, timeout=20)
print(r.json())

Drop that letter and use socks5://, and names are resolved locally again, leak included. HTTP proxies generally do the resolving themselves, but the leak test is still the proof.

Windows: choose the resolver and encrypt lookups

1. In Settings > Network & internet, open the connection you are using.
2. Go to Hardware properties and choose Edit beside DNS server assignment.
3. Pick Manual and enter a resolver your company has approved, in place of the provider's default.
4. Where Windows offers it, set Preferred DNS encryption to Encrypted (DNS over HTTPS), so lookups that still happen are not readable on the wire.
5. If the tunnel carries no IPv6, consider switching IPv6 off on the adapter to close that route.

macOS: replace the assigned DNS servers

1. In System Settings > Network, click Details next to the connection in use.
2. Switch to the DNS tab.
3. Under DNS Servers, delete the entries your provider supplied and add an approved resolver.
4. Save with OK, then repeat the leak test.

Work phones: private DNS

Android handles this centrally: Settings > Network & internet > Private DNS takes the hostname of a private DNS provider and encrypts lookups for the whole device. On iPhone and iPad, a configuration profile or an app can set DNS over HTTPS or TLS. Afterwards, switch Airplane Mode on and off on either platform so the network stack picks up the new resolver.

Run the test again

Repeat the DNS leak test after every change, with the proxy active. Every resolver on the list should be your proxy's or the private DNS service you picked; anything pointing at your real provider or location means work remains. Two causes account for most stubborn leaks, IPv6 and an application with its own fixed resolver, so turn IPv6 off on the tunnel and look inside that application's network settings.

Proxy type and DNS

Leaks come from configuration, not from the type of proxy. The type decides something else: which kind of address the destination sees once DNS is fixed. Remote DNS pairs well with household addresses from residential proxies or premium residential proxies. For speed-focused work, datacenter proxies do the job, provided lookups go through them as well. The proxies page covers each option, and running our proxy checker alongside the leak test confirms the exit IP and the DNS path in one session.

Add leak tests to the team checklist

A clean result does not stay clean by itself. An operating system update, a different network or a reinstalled application can change DNS settings without anyone noticing, so last month's pass is no promise for today. Put a leak test on the checklist for starting sensitive work and for joining a new network, next to the exit-IP check. It takes under a minute and replaces assumed privacy with verified privacy.

The lookup is the first step of every connection, which makes it an easy place to lose privacy. Test before you trust a setup, let the proxy resolve names, choose the resolver deliberately, and retest after every change; then the lookups are as private as the traffic.