Is a Google DNS server in your leak test a leak?

A Google DNS server in your leak test is not a leak on its own. A resolver is a leak only relative to where you browse from. If your traffic leaves through a proxy and the lookups were made by the resolver that proxy's exit uses, Google included, nothing leaked. If the lookups came from the resolver your own internet connection uses, they did, whatever company runs it.

We had to write that rule into code, because the first version of our DNS check got it wrong in both directions.

Why "is google dns a dns leak" has no yes-or-no answer

A DNS leak test page makes your browser look up a few random subdomains, then asks its own name servers which resolvers came to fetch them. You get back a list of addresses, the company behind each one and a country.

That list says who resolved the names. It does not say whose resolver that is, and that is the whole question. Google's public resolver is used by millions of home routers, by plenty of VPN servers and by proxy exit nodes. Seeing it tells you that somebody in the chain chose Google. You still have to find out who.

There are two tempting shortcuts, and both fail:

• Compare countries. Public resolvers are anycast: one address, answered by whichever of the operator's sites is nearest by network routing. A resolver in a different country from your exit is ordinary on that kind of service.
• Accept a matching country as clean. If your proxy exits in the country next door to you, or in your own country, your real ISP's resolver will match the exit's country perfectly. That is exactly what a leak looks like when the exit is close.

A rule over country codes gets both of those wrong at once.

How it works: Provider minting

What we measured

It started as a Whoer score. Whoer docked one of our profiles 30 percent for "DNS different — Your DNS server country differs from the IP country", the biggest single deduction it makes, and a stock Chrome on the same Mac scored clean. That Chrome had no proxy, though, so the comparison was never fair. We reloaded the profile six times without restarting it: 100, 100, 100, 100, 35, 30. The score fell when the residential session rotated, not when anything in the browser changed.

The control used no browser at all. Plain curl through the same proxy:

through the proxy      resolver Google LLC, Germany, then the Netherlands
the exit itself        Verizon, United States
this machine, direct   resolver kabelplus, Austria

The third row is the one that settles it, twice over. Our lookups did go through the proxy, or the test would have seen the Austrian ISP. And the browser was not involved, because curl got the same answer. When a browser is given a proxy, it hands the hostname to the proxy rather than resolving it, so the exit node resolves the name with its own resolver. No browser switch, content setting or engine patch reaches that. (The other half of checking this, reading whether the proxy was asked for a name or an address, is in a numeric CONNECT means DNS leaked.)

So that exit leaked nothing. It used Google in Europe while it sat in the United States, and a scanner that compares countries charges for it.

How our DNS row decides now

Our detection runner reads BrowserLeaks' DNS page from inside the profile. Before it ran, the row was a readout someone had to judge by eye. To make it give a verdict, the run now reads the exit address and the proxy setting before any test starts, and the DNS row reads three cases:

1. No proxy: pass, with the verdict "no proxy, so this is the machine's own resolver" and a line asking for a re-run behind one. Browsing and lookups both leave from this computer, so there is nothing to keep apart.
2. A proxy, and BrowserLeaks names the exit's own address as the resolver: pass, "DNS is resolving through the proxy."
3. A proxy, and the resolver is anything else: FAIL, printing the resolver's IP, ISP and location next to the exit. The detail says this is a leak if the ISP is yours and normal if the seller runs DNS somewhere else, and leaves that call to whoever reads the ISP.

Case 2 broke on its first outing. Residential exits are often dual-stack, so the same session showed BrowserLeaks a 2603: IPv6 address and another site an IPv4 one, and the runner compared against whichever it had read first. A proxy that was working fine got a FAIL. It now keeps every address the exit has shown in that run (two IP addresses, one exit has the run that caught it).

Where to act on it

No browser setting picks the exit's resolver, so Mosaic shows it in the proxy check, on the Proxies page, before any profile uses that proxy. The check sends one extra request through the relay it already has open and asks edns.ip-api.com which resolver fetched a hostname nobody has looked up before. On the result you get dnsCountryCode, dnsIsp and dnsMismatch, and when the countries differ the banner turns amber: "a different country from the exit", with a note that another pool or another seller is the only fix. We do not call that a leak. We flag it because Whoer takes 30 points for it. When the resolver cannot be read, all three fields stay empty, so "we did not find out" never shows up as "they agree". Tunnelling, rotation and blocklists, the other things that check reads, are in how to check a proxy before you use it.

Reading a leak test by hand works in the same order. Note your exit IP with the proxy on. Turn the proxy off and note your own resolver on browserleaks.com/dns. Then turn it back on and run the test. Google on that list only tells you that somebody configured Google; your two notes say who.