"DNS leaks" - what they are, & are not; a primer, of sorts

A core mission of cryptostorm is ensuring consistent, reliable network security with minimal fuss & drama. From DNS-based services like our DeepDNS in-browser native .onion/.i2p site access, through grounbreaking research on IP6 leakblocking, & to firewall-based structures to enable "fail-closed" security, this is where we discuss & develop cryptostorm-style leakblock tech.
User avatar
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am

"DNS leaks" - what they are, & are not; a primer, of sorts

Post by Pattern_Juggled » Tue Apr 09, 2013 1:30 pm

DNS leaks. All the cool kids are talking about them. The boffins at Wilder's have achingly long threads discussing them. Some VPN companies promise super-secret-magickal "fixes" to them (but don't release source code). Security pundits (rightly) flag them as a Pretty Big Deal when it comes to the overall reliability of VPNs for online privacy. They're around, they're talked about, they're elusive, they're... hot.

But what the fuck is a DNS leak?

The goal of this post is to answer that question. Which might seem stupid. I'm sure there's a Wikistupedia page on it, and there's literally thousands of posts in dozens of forums talking about them. Everyone seems to know exactly what they are... and I suspect that non-technical folks scan through these threads and conclude, understandably, that the actual definition of "DNS leak" is not subject to stochastic variation.

But it is. In fact, I think that people are talking about several different things in all those threads, often at the same time. And some people, it's quite clear, don't have the slightest idea what they're talking about - they're parroting what someone else said, with a bit of random error thrown in for good measure. I also suspect some of these automated "DNS leak testing" websites are full of fail. Because I don't think we're actually being precise on what "DNS leak" actually means.

So I'm going to define how I understand it, and explain that definition. And argue for why it's the right one to apply in the context of ensuring privacy protection whilst using an Encrypted Packet Routing (i.e. "VPN") service online. There may be tons of reasons to use different definitions of a "DNS leak" on other contexts; I really don't know. I just know this context, and really care about this context. So I'm defining to this context.

First, some disclosures:
  • 1. I am not a network technician, I don't have my CCNA, and I'm not able to make subnetting work reliably (it's black magic, as far as I'm concerned). DNS, too, is full of dark magics if you peel off the surface. I know folks who actually understand the guts of networking, and DNS, and so on. I'm not one of those people. I could do a good job of playing a network technician on TeeVee. Maybe. And I've done enough real-life network implementations over, um, several decades working with digital machines (remember Netware, anyone?) to have build some tactical ability and a smattering of theoretical awareness. I know what the OSI model is; I know how many layers there are... but I can't recite them from memory, or argue cogently about whether more should be added, or not. There are - quite literally - lots of folks out there, some of whom will surely read this, who have forgotten more about networking than I'll ever learn. If you're one of those people, I bow down to you.

    2. I am, however, an academic theorist in a rather abstract branch of mathematics and maybe that helps me frame this question in a somewhat useful manner relative to the traditional perspective of a genuine network guru. If it seems to you like I'm always tempted to slide into set theory as I discuss this stuff, then give yourself a gold star: I am tempted to. But I won't; don't worry.

    3. I've been active on the front lines of the online privacy world for longer than I care to admit in writing - since before there was a "cyberpunk" label to put on folks, then drop because it was limiting, then pick back up, then drop again... you get the idea. I've seen activists go to prison for mistakes in network security - I know such activists, on a first name basis, in several cases. I've helped folks in seriously repressive regimes (read: get caught, get tortured to death) keep safe and make good choices about network security technologies. So I do know things from the "what actually works, in the real world" perspective - which helps, I think.
There, enough of the preamble. I hope my definition will be surprisingly concise, particularly after the lengthy lead-up. And, alas, I'm not going to have pretty graphics and diagrams and screenshots to help explain this - that's not a skill of mine, although I'd love to see someone with that skill use their magic to turn my boring words into visual poetry. I'm a words dude.

Now, to work:

When you aren't using an EPR service - ok, I'll just call it "a VPN" for the rest of the article, although I hate the term as it's basically being misapplied and it's become vacuous as a result - your packets stream off your local machine (be it a PC plugged into a cable modem, a laptop hitting the wifi hub at the coffee shop, or your Android phone pushing packets to the cellular network) plaintext (let's just assume protocols like HTTP that don't force crypto at the protocol level, for ease of argument - since DNS leaks are totally agnostic to protocol level crypto anyway). That means plaintext in two discrete, and important, ways: the payload of the packet is plaintext, and the destination address of the packet is in plaintext.

An eavesdropper - we'll call her "Eve," for tradition's sake - sits as effectively a "bump on the wire" and watches those packets go past: she might be sitting at your local ISP, sitting at the ATT interconnect facilities (that means you, NSA!), or sitting inside the cellular company's IP transmission network. Whatever. She's sitting there, watching packets come off your machine. There they go, one after another: packets. And each packet has (along with other stuff not relevant here) a payload, and a destination address. She can see all if it, since you're not using a VPN.

Now, you log into a VPN service...

Eve sits there, and now this is what she is supposed to see: each packet comes past her, and they all look boringly similar. Their payload is encrypted, so it's gibberish to her (in mathematical terms: indistinguishable from random, maximum entropy, lacking in identifiable pattern). Useless. Also: the "destination address" - the Internet Protocol address - is boringly repetitive: it's just the IP address of the VPN "exit node" through which your (virtual) connection is routing. {note: this gets into virtual versus physical network topologies... I'm not going there, at this point, although it's a fascinating area of thought}

That's why using an EPR service, errr "VPN," protects you: Eve is stripped of the ability to see either the content of your packets, or the destination to which they're being sent (I'm just discussing outbound packets here; it's trivial to expand the framework to include inbound, as well, but they just confuse things in the simplest test-case scenario). And if you use, for example, HTTPS to "encrypt" your web packets (port 443/TLS) that protects the payload from Eve's ever-curious eyes... but not the destination IP. She'd still know you were visiting kinkypornwebsite.com or unusualpoliticalopinion.org or whatever - even if she couldn't read the contents of the packet. That's not good. We don't have a clever phrase for that, either: we still call the connection "encrypted" when we use HTTPS, even though Eve can see something really important about every packet that goes by: the destination.

So that causes confusion, in terms of what it means to be "using encryption to protect your online activity." And it's why well-intentioned efforts like the EFF's "HTTPS everywhere" are only partially useful, and perhaps even a little dangerous as they tend to leave aside the issue of destination address obfuscation... which, as we'll see below, has some metaphorical similarities to DNS leaks. HTTPS is better than nothing, but it's still got a good dose of "nothing" in it's security offered. In contrast, a VPN connection doesn't have this problem: it protects payload and destination address, both. {note: this is because a VPN connection is encrypting the network activity at a different level of the OSI model... I'll spare you the boring details, and spare myself the need to go look up which layer is which, again, for the time being}

So what's all this to do with DNS leaks?

There you are, running happily with your VPN connection. Let's say for ease of example, it's a connection based on the OpenVPN model (with which I'm most familiar, personally). It creates a virtual network adapter on your computer ("TUN/TAP interface") and then it shoves all your outbound packets through that adapter. As part of that, the "adapter" does the fancy work of encrypting the payload of your packets and also re-addressing them so that the destination IP address is now the exit node of the VPN network (the actual destination address is bundled up in the encrypted payload, where it's not visible to Eve - it gets pulled back out at the VPN exit node, and then stuck back on the packet during "re-packetization" prior to departure from the exit node onto the plaintext internet).

It doesn't matter if those are HTTP packets, HTTPS packets, FTP packets - nor whether they're being transmitted via TCP or UDP - nor if they're IMCP requests ("pings") or whatever: if the packets are IP packets (and pretty much everything outside of deep corporate computing environments is IP nowadays), they get shoved through the virtual VPN adapter. And, in doing so, they get "wrapped" in the VPN crypto - so when they leave, they're encrypted and stripped of destination address. That's a nice thing about OpenVPN: it's good at gathering up all the packets your machine produces and, via the fundamental architecture of the client app as it relates to the OS kernel itself, funnelling them into the virtual adapter and thence into the "tunnel" of secure encryption. Other protocols, like PPTP, are far less good at that - they leak all over the place, all the time, for a host of structural and piss-poor implementation reasons. But we digress...

Are we closer to defining what a "DNS leak" is in this context? Yes, we're there in fact. A DNS leak happens when, despite being connected to the VPN and despite the fact that - in theory - all outbound IP packets must by definition go through the virtual network adapter (and hence into the "tunnel" of encryption), an unencrypted packet "slips by" and travels out down the wire, past Eve's curious eyes, for all the world to see.

Wait a minute! How could that happen? Isn't the virtual adapter supposed to capture all the packets?

Well, yes but... and the but ends up being sort of a door that opens to a large field of issues. Truth is, this whole "virtual adapter" thing isn't exactly like stringing two physical network adapters in series, so that no packet could "jump" past the first one and get to the second one - or get past the second one and out onto the wire. These virtual adapters are, well, virtual. In actual fact, all the actual IP packets are still leaving the machine via actual electrons being shot out on the wire (RJ45 ethernet or wifi or whatever) by a physical network adapter. The whole "virtual adapter" thing is a nice way to convince (trick?) the OS into reliably using the VPN without all the applications needing to understand this (again: ISO model layers)... but it's a trick. A sleight of hand. And, like all tricks, sometimes it breaks down if the light comes from just the right angle, or whatever.

This has to be the case. Think about it: what happens when your VPN connection shuts down, after all? Well, the virtual adapter goes dormant, and the OS drops back to "routing the IP packets through the physical ethernet adapter" (which it's been doing all along, just not being aware of it... sorta) - the virtual NIC disappears, and the physical NIC starts pushing unencryped packets out over the wire. The physical NIC was there all along, of course. And the only thing stopping it from sending out unencrypted packets - even when the VPN is connected and the "virtual adapter" is engaged - is the degree to which the OS basically follows its own rules. In theory, the "rule" is that all packets go through the virtual NIC, and onto the VPN.

But OSs don't always follow their own rules. They access the network - the physical NIC - from lots of different angles, for lots of different reasons (note that I'm - obviously - not an OS expert, so I'll not even pretend to understand that stuff well). One reason the OS has to talk to the network, via some network interface, is to resolve DNS queries (I'm not going to do a "what is a DNS query" tutorial here - maybe someone can link to a good one, and I'll pull the link up here, for those who want to refresh that topic). The OS says "hmmm, I've got mylittleponyfanclub.org here that this application wants to talk to, and I need to know what IP address that corresponds to so I can address some packets... guess I have to ask a DNS server that question, since that's what DNS servers do; hmm, what is my 'rule' for picking what DNS server to ask?" And now we're at the heart of the matter.

When you're on a VPN, the DNS servers are "pushed down" to your computer as part of the VPN session setup (at least under OpenVPN they are, as part of ovpn.conf parameters) - they become a part of your routing table on your local machine. And that means, if the OS follows its own rules, it'll use those DNS servers to do DNS lookups. Yay! So, then, a DNS leak means that the OS uses different servers? No!

No. No. No. No. No.

This is not a DNS leak, not in any useful sense of the phrase. This is, well, simply a case of the OS using the wrong DNS settings for lookups. That could be bad, and it could be sorta "leaky" in one sense: if your computer usually uses the DNS servers of your local ISP (which, by the way, is a terrible fucking idea - so this should never be an issue for you), but it uses a bigger, less local (to you) DNS service (like OpenDNS, or Google) when you're on the VPN, then falling back to your local ISP's DNS lookups, ceteris paribus, whilst still on the VPN connection could decrease your privacy somewhat (your local ISP could, in theory, sit there and watch DNS queries coming into the DNS resolver it's running and say "aha, I see John Doe at leased IP address xxx.xxx.xxx.xxx just looked up the DNS entry for kinkyfrenchcuisine.fr - what a freak!" - rather than that DNS query going to Google's DNS servers (the now-mythical octet) which, we assume, doesn't have someone sitting there watching to see if weird queries come through.

But that's not really a DNS leak. That's just choosing a more- or less-reliably discrete DNS server, during a VPN session. That is still "an issue," sorta, but it's fairly easy to fix if you just go on a jihad and strip out all reference to DNS servers other than the ones you really want to use, in every place they appear in your OS and your router and your NICs and whatnot. That's what alot of the "how to fix DNS leaks" threads seem to be discussing, fwiw. And, yeah, that's not rocket science. But it's really an incremental issue, if we're going to be brutally honest about it.

A real DNS leak, in contrast happens like this:

You're happily connected to your VPN, happily doing your online stuff. Eve's sitting there, as usual just a bump on the wire, ever-curious. She's watching your packets go by: they're boring, predictable almost. Payload is encrypted, and the destination IP address is always the same (the VPN network exit node). Sigh. Poor Eve. But wait - what's this?! A packet comes by on Eve's wire, and it's not at all like the other ones:

[list]...this packet has a different destination IP address, namely the destination IP address is for a DNS server somewhere (doesn't matter which one - could be Google, could be your local ISP, totally irrelevant). And the payload is asking a question, namely: "I want to know what the IP address is for the domain name pervertedplushiepleasures.com is, please?." It's a DNS query... but it's in plaintext. Plaintext payload (the actual question of resolving the domain name into an IP address) and the destination IP address (which is just some DNS server, somewhere).[/list][/i]

That is a DNS leak. Go back and read the preceding paragraph again, if you will, as it's deceptively simple. Actually, it is simple - but that makes it easy to skip over the importance.

The DNS leak happens when a packet "slips past" the virtual network adapter... and gets out onto the wire unencrypted - both the destination IP address visible, and the payload in plaintext. In a sea of encrypted packets coming off your machine, this leaked packet stands out like a neon sign in the Stygian darkness. It's got useful information in it, perhaps very useful, for Eve.

What does Eve learn from seeing that one packet go by? She knows that you're visiting pervertedplushiepleasures.com - she knows it with almost total certainty. Why else would you be looking up its IP address? (sure, you might just be doing a random manual resolution of or ping to the domain - but probably not.) And with that knowledge, she can take some targeted actions. She can go to the admins of pervertedplushiepleasures.com and demand they cough up your account there. She can engage in "traffic analysis" and perhaps get a sense of what time of day you visit the site, for how long, and what sort of stuff you're doing there (uploading massive files, or downloading a stream of something, or whatever). She can go on Twitter and broadcast to the world that @yourtwitterhandle visits pervertedplushiepleasures.com... and you'll have absolutely no idea how she knows that - since you're using a VPN connection all the time! Spooky. Embarrassing (maybe, if you're a closet plushophile that is). Or worse - if you're actually visiting a website for an opposition political party in a country where such could lead to you and your family being killed by the government.

Why would this one particular packet leak like that and not, say, a random packet from within a radio stream? Because the OS might break its own rules about respecting the virtual network adapter - it might just "shortcut" things and push a DNS query directly to the physical NIC, bypassing the virtual NIC - and hence the VPN tunnel and concomitant encryption - entirely. But that's... just wrong, isn't it? Well, yes it is - but it happens. It happens alot with some VPN protocols (like, for example, PPTP) that aren't good at working with the OS to ensure it honors the VPN tunnel. It happens far less often with OpenVPN - but it happens.

So I can test these leaks by going to a DNS leak website tester, right?


There's only one way to diagnose real DNS leaks: put a packet sniffer on your machine, dump a log of packets physically leaving your physical network adapter(s) during a VPN session, and inspect those packets to see if any are coming off with destination IP addresses other than the VPN network exit node during your VPN session. That is the only metric by which to confirm a leak is happening, or not.

After all, that's what Eve is seeing as she sits there on the wire - watching your packets go by, one by one. She's not at some website out there, in the cloud; she's right on that fucking wire, watching your packets. And to diagnose a leak, that's where you need to be (virtually speaking).

These DNS leaks - the real kind, in my definition - are far, far more serious than the "oops, my computer used the wrong DNS server during my VPN connection" kind of issue we discussed above. Because Eve won't see anything different about your packets, in the latter sort of "leak" - they're still encrypted, still in the VPN tunnel, still secure from her prying eyes. But real DNS leaks involve real plaintext running out down your wire, even during a supposedly "encrypted" VPN session. And those leaking packets are telling Eve seriously private, sensitive stuff: what domains you're visiting.

I don't know of any automated tool to test for real DNS leaks. We use Wireshark, stuck on a network adapter coming out of a VPN connection spooled up within a VM running on a host OS. Which isn't as tedious as it sounds, but isn't exactly "click here to install" either.

So how do you fix a real DNS leak like this?

Yeah, good question.

If you think about it, about the topology (in logical terms) of the network resources in question, then it's self-evidently obvious that no amount of tweaks to the VPN application itself will necessarily fix all such leaks if the leaks "spring" from the OS not following the rules of the virtual adapter, for whatever reason. You might be able to bully the OS - or trick the OS - into being better about following the rules, but really... it's the OS. It's root, by definition. It owns itself. Your VPN application - running in userland! - can't compel the OS to do stuff like that, not reliably. Either the OS does what it says it's going to do, or we have to just do our best to deal with whatever way it actually does behave, rules be damned.

Real VPN leaks like this, coming from the level of interactions between physical and virtual network adapters, are nontrivial. These are the kinds of leaks that cryptographers (like Bruce Schneier) talk about when they talk about DNS leaks. They are specific to the way a given VPN tool/protocol/architecture interacts with a specific operating system; they are genuine bugs, in the sense of being an unexpected behavior that manifests without being specifically intended by the developers coding the system.

In conclusion...

There are circumstances in which OpenVPN exhibits DNS leaks, as defined above. Some such leaks seem to result from certain ways of configuring the OpenVPN sessions themselves (choice of parameters within ovpn.conf) - we're tracking one right now that has to do with routing table entry metrics, and conflict between them. I have anecdotally heard of several other etiologies for such leaks; I'm in process of hunting them down and bringing back details to the forum here, but it's made vastly more difficult because people use the term "DNS leak" in such varying ways - often to refer to something that's close to being trivial, in my opinion.

And, lastly, there's really only one way to GUARANTEE against a DNS leak - or any other kind of leak - during a VPN session: an external application that, through some cleverness or other, sits right on top of the physical network adapter and enforces some heuristics on packets heading out on the wire. Trust, but verify.... look at the actual packets streaming out of the actual physical adapter (or as close as possible to this) and either say "yep, you look good, out you go little packet..." or "no way dude, you're plaintext and you are NOT leaving this machine - off to /dev/null with 'ya."

If that sounds a little bit like the Leakblock project that's been mentioned around here on and off this winter, well, that's no coincidence. More on that soon...


  • - Pattern_Juggled
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github

Posts: 1
Joined: Mon Jun 24, 2013 7:40 pm

Re: Tech essentials: what, precisely, is a "DNS leak?"

Post by axa » Wed Jul 03, 2013 6:37 pm

I've been evaluating an alpha copy of LeakBlock for the past week and it works fine.

I have been using the method provided by dnsleaktest.com to prevent DNS leaks from the physical adapter. Changing the LAN to static and removing the DNS entries should absolutely prevent DNS leaks.

To prevent other VPN leaks I also edit the routing tables as outlined at http://forums.comodo.com/firewall-help- ... 13.15.html

Problem is sometimes the deleted route gets renewed, so I also bind my applications to the VPN using Comodo firewall.

Using LeakBlock in addition may provide an extra layer of protection. Thanks for sharing!

User avatar
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am

alpha feedback - feedback on the feedback :-P

Post by Pattern_Juggled » Thu Jul 04, 2013 5:34 pm

axa wrote:I've been evaluating an alpha copy of LeakBlock for the past week and it works fine.
Thanks so much for taking the time to do the alpha testing, and reporting your results here.

A couple of Cryptocloud's more talented tech folks have been contributing personal time to Leakblock during the winter and spring months, with yours truly contributing vague theoretical advice regarding network topology and structural issues relating to network stack access from within various OS models (which is far from my area of expertise, so I've done my best to reach out to other folks with more direct wisdom in this area). Obviously, it's the work of the actual coders which has been the lion's share contribution.

Oh, there's also been some interesting work in exactly how Peerblock (which forms the guts of Leakblock) thinks about/defines "whitelists" and "blacklists" on a per-packet basis. Which required wireshark to untangle. Turns out there's some subtle set-theoretic issues at play in the manner the two methods of *listing interact. Once we'd figured out the actual stepwise process each packet goes through in the Peerblock architecture, it was not too complex to set up the *listing to get the job done.

So far in these early steps of the Leakblock project, our goal has been clarity and conceptual simplicity in how we go about preventing "leaks" as we've defined them, in the essay above. The more complex an application is, the more likely it's going to argue with some other component of the overall architecture - and fail as a result. So we've discarded vast swaths of potential approaches to the problem, in favour of one that's as tight and complexity-free as we could find.

There's a bit more alpha feedback being sought, and once that's back in we're going to push out the "official" beta... and encourage the community to share suggestions, criticisms, and - most importantly - ways to improve Leakblock in a monotonically increasing manner over time. :thumbup:
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github

User avatar
Posts: 288
Joined: Thu Oct 24, 2013 2:37 pm

Re: "DNS leaks" - what they are, & are not; a primer, of sor

Post by DesuStrike » Wed Dec 11, 2013 10:20 pm

Haha. I come here from Twitter and thought "wow! A fresh new post by PJ and what a detailed one!" but then realized that this is from April. Well, some information might get stale fast but this one is as fresh and important as when it was posted. (PS: Somebody really should register those domains you used! :mrgreen: )

As for something that explains DNS and how the queries work:

It's REALLY superficial(?) but it has enough colorful animations to keep the average Joe interested long enough. But maybe that's not the intended audience after all considering the length of your post...

All in all I learned a valuable lesson today. I am also one the guys who used DNS-Leaks for both using the wrong DNS servers and those pesky little queries that just snuck out past the VPN for some mystical reason.
home is where the artillery hits

Posts: 5
Joined: Thu Oct 10, 2013 8:53 pm

Re: "DNS leaks" - what they are, & are not; a primer, of sor

Post by anon » Thu Dec 12, 2013 5:10 am

Pattern_Juggled wrote:{direct link: leaks.cryptostorm.ch}
if you're actually visiting a website for an opposition political party in a country where such could lead to you and your family being killed by the government.
  • - Pattern_Juggled

This could sound very exagerated but as an instance my goverment is run by crazy mafia drug lord thugs and there have been several cases where jornalists get killed by these mother fuckers, they also use the army and the police to do this kind of tasks. Great explaniation! ;)

User avatar
Posts: 434
Joined: Mon Aug 05, 2013 11:39 am

Re: "DNS leaks" - what they are, & are not; a primer, of sorts

Post by marzametal » Sat Feb 14, 2015 3:33 pm

CS staffers...

Have you been working on the DNS addresses that are pushed out via Windows widget? Yesterday, all DNS's matched, regardless of exit node. Right now, some of the nodes are pushing their own set of DNS.


Re: "DNS leaks" - what they are, & are not; a primer, of sorts

Post by Username: » Mon Aug 10, 2015 4:17 am

Thank you for another interesting article. I'm still more interested in details, though.

Here's some trivia that I recently discovered: Weendoze (who uses that?) does not appear to use its routing table to determine which DNS server to query, but, rather, the "binding order" of the adapters.

Regarding protection from leaks (DNS or otherwise), using hardware like a Bannana Pi (or Raspberry or whatever you have) with two physical network interfaces as a cheap hardware firewall will do the trick.

Another little, obvious, thing when using a VPN, TOR, or whatnot...make sure that the encrypted connection and the routing table to it is the last thing to be shut down...there can be all kinds of things living in a browser calling back home after the routing table to the encrypted connection is shut down. Javascript is not your friend.

Also bothering is the fact that most governments are bent on TIA (Total Information Awareness) and are able to see the traffic at the VPN "exit node" (as you call it). Because of this and various leaks of information in the TCP protocol itself, it becomes easier for them to correlate a little DNS leak with your exit traffic, and, then, pop goes the weasel.

Anyway, I guess I'm rambling...