You might’ve run a DNS leak test while connected to Windscribe and thought, “Oh no, a leak!” But before you cancel your subscription and go off the grid, let’s break down what’s really going on.
Spoiler: it’s not a leak, it’s a failover. And it’s actually working as designed.
How DNS Lookups Normally Work on Windscribe
When you’re connected to Windscribe and make a DNS request, it gets routed through a built-in DNS proxy called R.O.B.E.R.T. (yes, that R.O.B.E.R.T., the same one who blocks ads, trackers, and malicious nonsense). R.O.B.E.R.T. sends your request to one of our local recursive resolvers running BIND9 on the VPN server you’re connected to.
Here’s the ideal flow:
- You send a DNS query to 10.255.255.1–4 (our internal listeners).
- R.O.B.E.R.T. hands it off to BIND9 on the same VPN server.
- BIND9 resolves it normally.
- R.O.B.E.R.T. sends the answer back to you.
Smooth, local, private. No drama.
Yegor Sak
But Sometimes, BIND9 Says "Nope"
There are edge cases where the local BIND9 resolver runs into issues. When that happens, R.O.B.E.R.T. kicks in a backup... and this is where things might look weird to DNS leak test websites.
Let’s break down two scenarios:
Scenario 1: The Authoritative Nameserver Sends Garbage
Some DNS servers out there are just... broken. Take dnsleaktest.com for example. If you trace the domain using a tool like Dig Web Interface, you’ll see that its authoritative nameservers (ns1.dnsleaktest.com, ns2.dnsleaktest.com) return a malformed response.
Newer versions of BIND9 (like the one we run) don’t play nice with this junk and instead return a SERVFAIL: basically saying, “I can't resolve this nonsense.”
So what happens next?
- R.O.B.E.R.T. sees the failure and says, “Fine, I’ll do it myself.”
- It forwards the request to Control D, our secondary DNS resolver.
- Control D, which is built to handle edge cases like this, resolves the domain.
- R.O.B.E.R.T. gets the response and passes it back to you.
🧠 Result: You get your DNS answer. But because it came from a Control D IP, a leak test might think it didn’t go through the VPN. It did. It’s just the backup system doing its job.
Scenario 2: The Authoritative Nameserver Blocks VPN IPs
Another reason for fallback? Abuse-based IP blocks.
Some DNS servers will outright block requests from certain IP. nd yes, VPN server IPs are often on that hit list. If an authoritative DNS server refuses to talk to one of our VPN hosts, BIND9 returns a SERVFAIL again.
Same process kicks in:
- R.O.B.E.R.T. notices the failure.
- It retries the query using a Control D resolver (which uses a different IP).
- The authoritative server responds to Control D just fine.
- The answer comes back to you.
🧠 Result: Again, no data was leaked. The fallback path just used another Windscribe-operated resolver — routed securely via NetActuate — to complete the lookup.
So Why Do Leak Tests Freak Out?
DNS leak test websites typically expect all DNS queries to come only from the IP you’re connected to. But when we fail over to Control D, that DNS response might come from a slightly different IP; one that the test doesn’t recognize as being tied to your VPN connection.
The test sees a different IP and goes, “Aha! A leak!”
But really, that’s like saying your umbrella is leaking because you used a second umbrella when the first one snapped. No rain got through. You just stayed dry using a backup.
Rebecca Rosenberg
TL;DR
Is your DNS leaking?
Nope. It’s just being resolved via Control D because the primary path failed.
Is your data exposed?
Still no. Everything is handled securely and privately within Windscribe’s infrastructure.
Should you panic?
Only if you forgot to renew your Windscribe subscription.
Final Thought
We built Windscribe to just work, even when the internet throws garbage responses or VPN-blocking tantrums. If a DNS test says otherwise, now you know: it’s not a leak, it’s resilience.
Still unsure? Run a real-world test. Visit multiple sites, check your IP, and monitor what you see. And if you’re ever concerned, reach out. We’ll bring the receipts.
