A new type of DNS leak – ExpressVPN's research raises concern for VPNs

DNS is a vital part of the machine that keeps the internet running smoothly. If you think of the internet as a highway, DNS is the signpost pointing traffic in the right direction.

Unfortunately, DNS was conceived in an era when the internet was significantly smaller and its users more trustworthy. As such, there are a bunch of different privacy issues surrounding DNS that've been discovered over the years. It's vital you understand how they interact with your connection to the Internet if you’re concerned about your online anonymity.

Most VPN providers claim that their services are a complete panacea for online privacy. The reality, however, is that DNS often creates a gaping hole in their veil of anonymity. I'll cover the biggest DNS security vulnerabilities, how you can tell if the best VPNs are implementing DNS safely, and what VPNs can and can't defend against. 

What is DNS?

Before I go any further, it would probably help to explain what DNS actually is. DNS (or Domain Name System) is a distributed set of servers that collectively contain the naming system for every website on the Internet.

When you look up a website in your browser's address bar, DNS is the system that returns the IP address associated with that domain so that your computer can start communicating with it. On a basic level, you can think of it as an address book or a phone number lookup. The way DNS actually works is a little more complex than that, naturally, but it's a useful abstraction to keep in mind. 

The networking protocols that power the internet use numeric IP addresses – which aren't very human-friendly. You can probably name a few different website URLs off the top of your head, but imagine if every website you wanted to access required you to remember a 12-digit number. It'd be a nightmare, right?

This is why DNS is so important – it translates handy URLs into a numeric format machines can use, and vice versa.

For example, imagine you run a small eCommerce website and you're switching to a cheaper hosting provider. As part of the process, you'll need to move the site onto new servers – and get a new IP address. Without DNS, you'd have to manually notify all of your customers that your IP address has now changed. With DNS, it's as simple as updating your DNS records to point your domain name to a new IP address. It all happens seamlessly, without your customers even knowing that there's been a change.

DNS makes the internet a more user-friendly place, but translating domain requests like this also helps maintain the internet in more subtle ways.

DNS can dynamically route your requests to servers that are geographically nearby to reduce lag, or send your requests to the least congested server in a pool of IPs to help with load balancing. DNS geo-location is actually how a lot of content providers enforce copyright restrictions, which is why some VPN providers offer a smart DNS service that routes your requests intelligently to get around content blocks without using a full VPN connection. 

How does DNS work?

A series of checks happen when you make a DNS request. First, your operating system will refer to your hosts file to see whether there’s a relevant hardcoded DNS record already on your machine.

Usually, you'll find there's at least one DNS record already in your hosts file: "localhost", which translates to the local loopback address 127.0.0.1. This allows you to refer to your own computer's network services without actually exposing them to the network. You could set other domains you don't want your computer to access to 127.0.0.1, too, which would override any other DNS lookup. 

If the record isn't in your hosts file, the next check is made against your local DNS cache. This is a list of DNS records that you've recently requested and stored in your operating system. This cache stops you from sending network traffic to request DNS records for sites that you visit all the time, cutting down on the bandwidth required to access the internet.

If, tragically, the domain you've requested isn't in your DNS cache, either, your request will be forwarded to the DNS recursive resolver server you're connected to. 

For most denizens of the internet, this will be one of the DNS servers run by their ISP, assigned via their router by DHCP. This setup has its privacy issues - but I'll get into those later.  If the record isn’t in the ISP’s DNS cache, it's time for the recursive server to look it up on your behalf.

Domain names are broken into several "zones" and each is managed by a different tier of servers. 

• The ISP's DNS server will maintain a record of the root name servers to query.
• Those root servers keep a record of which DNS servers maintain the records for Top Level Domains, such as .com, .org, .co.uk, and so on.
• Each TLD DNS server contains a list of all the domains that end in that TLD, as well as the authoritative nameserver associated with that domain.
• These authoritative DNS servers maintain all of the records related to a single domain.

It's this server your recursive DNS server actually queries to get a definitive answer on which IP is associated with a domain URL. Once it gets an answer, that record is passed back to your local computer.

DNS works on trust. You trust your recursive DNS server to return a true answer. Your recursive DNS server trusts that the root servers it's pointed at return the right TLD servers. Those TLD servers trust that each authoritative domain nameserver is run by the domain owner, who has the correct DNS records. Unfortunately, a variety of attacks launched using DNS show that this approach is fundamentally flawed. 

Let's compare and contrast with SSL. When you connect to a site using the best SSL, there is a central authority that indicates you’re connecting to the site you expect to connect to, and that your connection is only able to be decrypted by the site owner. 

Using SSL is now considered a basic security for most websites; it's just good practice. However, the same cannot be said for DNS. 

In most network configurations, DNS servers are taken at their word. The thought behind this is that the validity of a DNS record can be verified once you visit the actual website and validate it against the SSL certificate. This approach is changing, but many DNS servers are yet to adopt DNSSEC which protects against trust-based attacks.

I'm going to walk you through a set of attacks to demonstrate how vulnerable DNS can be, and why it’s essential you pick a secure VPN that can protect against them.

DNS hijacks

Hackers don't necessarily need to breach a DNS server to cause massive damage. Remember, DNS is really just a series of IP pointers and records. If you can change which nameservers are pointed to for a particular domain, you can use your own DNS servers and control everything that happens downstream from there. 

This is exactly how a group of attackers associated with Iran launched a two-year-long intelligence-gathering campaign between 2017 and 2019 that compromised hundreds of domains in the Middle East and Africa. While the exact methods used to compromise each DNS server varied, some were hijacked by simply stealing credentials for the domain registrar for some of these sites and changing the authoritative nameserver to one owned by the attackers.

This allowed the hackers to point the domain records for each site they controlled to a series of transparent proxies that would capture all of the traffic sent back and forth to that domain. They even replaced the SSL certificates with new certificates issued automatically from the certificate authority Let's Encrypt, which allowed the cybercriminals to unencrypt any traffic they captured without alerting their victims.

The worst part of a DNS hijack like this is that it’s difficult to detect. There's no intrusion into an organization's actual network, so unless someone audits the DNS records or notices the changed certifications, it's pretty hard to spot. Compromised DNS servers can also be highly selective in which users they send false records to, making it even harder for the average user to identify.

You might think that a VPN's encryption could put a stop to these attacks – but that isn't the case. Your data gets unencrypted when it reaches the VPN endpoint, and from then on the only protection your traffic has is TLS, which the attacker already has the keys for.

Even if you're using a VPN’s DNS servers, it won’t make any difference – the authoritative server has been compromised, and that's going to propagate all the way back to any DNS server you use… except, not really.

There is one way to shield against this attack. Remember when we were talking about SSL? Well, you can apply the same principle to DNS. Enter DNSSEC. 

DNSSEC applies the same asymmetric key cryptography that powers SSL/TLS, with a single twist that enforces the web of trust baked into the DNS-distributed hierarchy. Each certificate is signed by the nameserver that exists above it in the resolution chain, indicating that the nameserver is trusted by the zone above it.

If your VPN provider runs their own DNS resolver (and they should!) then they should have DNSSEC turned on. However, domain owners also need to have DNSSEC enabled in order to benefit from the cryptographically enforced chain of trust that DNSSEC provides. 

DNS interception

DNS hijacking has pretty spooky implications, but DNS attacks happen much closer to home, too. Let's say you're using a public Wi-Fi access point while you're in an airport. Sitting at the other end of the departure hall is a hacker monitoring all the traffic being sent over that router.

DNS requests aren't encrypted by default so, in this scenario, the hacker can analyze all of your DNS requests to a DNS server and capture them, as well as return DNS responses that direct you to any website of their choice.

This attack doesn't just work for HTTP, either. It can also allow an attacker to redirect any DNS request you make to any internet-enabled service, such as SSH, RDP, and so on.

This even poses a problem for SSL, which is supposed to protect against eavesdropping. An attacker with the ability to monitor and alter your traffic on the local network can conduct an SSL stripping attack, preventing you from using SSL to verify the contents of the connection by downgrading the connection to HTTP. The intricacies of SSL stripping are beyond the scope of this article – but it can be done.

The good news is that a quality VPN protects you against this type of attack. As long as your VPN client strictly enforces that DNS requests are only made through an encrypted tunnel, a hacker present on your local network can’t intercept your DNS requests. 

DNS poisoning

Attackers do not need to be on the same network as you in order to manipulate the DNS records you have access to. Advanced attackers can also engage in a practice called DNS poisoning, where they manipulate the records stored on a DNS server by remotely sending false data. 

There are a multitude of methods attackers can use to perform a DNS cache poison attack, but the general shape of the attack is that they are taking advantage of a quirk of how a particular DNS server works to poison records remotely. They do not have direct access to the DNS server, as in a DNS hijack attack.

To explain how DNS cache poisoning works, we need to revisit how DNS works again. DNS records come in two flavors: authoritative and non-authoritative.

Your ISP's DNS server returns non-authoritative records because it is a recursive DNS server. It does not hold the canonical DNS records for a zone: it simply caches records from elsewhere. Only the DNS records stored at the zone owner’s name server are authoritative.

To make sure that non-authoritative records don't cause connections to permanently fail when the authoritative records are updated, all cached records have a "Time-To-Live". This is set by the authoritative zone holder and can range from seconds to weeks. Once a DNS record outlives its TTL, it must be requested from the authoritative zone owner again.

DNS requests also use UDP instead of TCP to make DNS requests quicker and reduce overhead. However, this means that a DNS request doesn't involve establishing a connection with a DNS server. Instead, you just send out a request and wait for a response.

The problem with running DNS over UDP is that the fastest correct answer is the one that remains in the cache until the TTL expires. If a hacker can get a false answer back to the requesting server quicker than the true answer from the authoritative zone owner, the true answer is simply discarded as it's already cached.

To stop man-in-the-middle attacks across the Internet, DNS servers use a field called a query ID to ensure that the query matches with the recipient. This prevents hackers from just making DNS requests to a recursive DNS server and then spamming false results before the real DNS server has a chance to return.

While this made the process more difficult, the query ID space was only 16 bits wide (about 65,000 possible values), which meant that if you repeatedly made requests to the same domain, it would be possible to guess the query ID before the true answer had a chance to return. 

This sounds pretty bad, but one heavy limitation of the attack was that you could only poison a single domain record at a time. You'd also only be able to guess during the period between the TTL expiring and a new authoritative response being cached. Given that TTLs are usually at least a day long, you'd be waiting years to get lucky just for a single domain record.

However, research published by Dan Kaminsky in 2008 indicated that not only could you poison the DNS records themselves, but you could also poison DNS resolvers' authority records.

Essentially, this would allow you to host your own authoritative DNS server for a zone and trick a recursive ISP DNS server into visiting it, meaning that you now have control over all of the DNS records for that particular zone. By spamming DNS requests for new subdomains in a particular domain that would force the DNS server to re-request the authority pointer, you could reduce the time taken to carry out this attack from years to seconds.

From here, it's straightforward to direct anyone who requests a domain through that poisoned DNS resolver to your server instead of their original destination.

Importantly, this means that you can redirect requests to any subdomain. One reason this attack works is because DNS records are sent using a specific port over UDP that doesn't change between requests. Since there's no transactional checking beyond the client ID number, it's first-come, first-served. 

One solution to this attack is by randomizing the UDP port sending the response, vastly increasing the number of possible combinations you would need to send before the legitimate response returns. Most DNS providers have updated their servers to protect against this attack, but the fundamental issue with cache poisoning still exists. It's just much harder to do.

This attack demonstrates that the attacker doesn't necessarily need to own the compromised DNS server in question to manipulate DNS records. As such, the DNS resolver you use must be patched to remain up to date with new techniques that reinvent the DNS cache poisoning technique.

Plus, using a VPN provider with an encrypted DNS server means you won’t have to worry if your ISP’s DNS servers are vulnerable to cache attacks.

DNS reflection

DNS servers aren't just used to carry out malicious redirection; they're also abused to amplify existing DDoS attacks by multiplying the amount of traffic sent to a target.

A traditional DDoS attack involves a network of computers, each controlled by a botmaster, using their Internet connections to flood a target computer with packets in order to deny other connections to that computer.

There are two main strategies when it comes to DDoS attacks: protocol-based and volumetric-based.

• In a protocol-based attack, the attacker attempts to fill all of the target's connection slots with connection attempts that will never be completed – usually by sending the initial part of a TCP handshake chain and then ignoring the responses. It takes a certain amount of time before the handshake response times out and the connection slot becomes free again, so tying all of these up is an effective way to keep a server from responding.
• In a volumetric-based attack, it's all about sending as much data as possible to keep resources busy or network pipelines saturated. UDP is preferred over TCP for these types of attacks, which is where DNS comes into play. DNS reflection attacks significantly reduce the amount of data an attacker needs to send to execute a DDoS attack.

In a DNS reflection attack, however, a resolution request is sent to an open DNS server misconfigured to accept responses from any computer on the open internet.

The key mechanism here is that hackers can forge the recipient's IP address on packets sent to these open servers. Consequently, when the response to the DNS request arrives, instead of being directed to the originating computer, it's directed to the victim.

What this means is that open DNS servers are a serious threat, as they can easily be exploited by hackers to launch powerful DDoS attacks while maintaining anonymity. 

Even a few relatively small packets sent to a recursive DNS server can prompt a disproportionately larger response. A single DNS record isn't particularly large, but an entire Zone transfer can be orders of magnitude larger than the original DNS request.

If the request hasn't been cached, recursive requests are sent to several more DNS servers, further magnifying the attack's impact. The alarming aspect of this type of attack is its scalability – the more servers and computers involved, the greater the potential damage.

Thankfully, VPNs safeguard against these attacks, too – because hackers can only DDoS you if they know your IP address.

When you use a VPN, not only is your home IP disguised, but your VPN provider is likely to have invested in high-powered DDoS protection. Even in the unlikely event that you get knocked offline by a DDoS attack, all you need to do is reconnect to another VPN server and you'll be A-OK.

DNS rebinding

The final type of DNS vulnerability I'll put under the microscope today is the DNS rebinding attack. It, in a nutshell, aims to bypass the same-origin policy implemented by modern Internet browsers.

This policy acts as a type of sandbox for Javascript, ensuring that scripts from a particular website can only access resources related to that site, like its cookies. Without the same-origin policy, an attacker would be able to use malicious code to read data from other websites.

Attackers seek to exploit this safeguard by leveraging your browser as a pivot point to execute malicious JavaScript that can access resources beyond the site's scope.

In a DNS rebinding attack, the attacker attempts to bypass this policy by employing a malicious authoritative DNS server for a domain they control. This means that they can update the DNS records related to that domain at any given time.

When you visit the attacker's domain, your browser requests the IP address associated with the domain from the attacker-controlled DNS server. However, the returned DNS request has an extremely short time-to-live, allowing you to access the site without it being cached locally. 

Additional DNS requests are made for that domain as you interact with the site. At this point, the attacker updates the DNS record in their controlled DNS server to point to a resource they want to access, such as another website containing malicious content or an internal resource within your home network. This manipulation enables the attacker to redirect your browser's requests to their desired destination, completely bypassing the same-origin policy.

Once the attackers have updated the DNS records, they can embed an iframe within the webpage, directed to whichever resource the attacker is attempting to access. 

This attack can be massively damaging for businesses since it allows an attacker to tunnel past the corporate firewall. However, it can be just as harmful for the average internet user too.

Consider this: how do you access your router? Almost all routers have a web portal accessible from a local IP on the network. If attackers manage to gain access to your router's admin page by pivoting through your browser with a DNS rebinding attack, they can begin brute-forcing your router's login credentials.

Once in, they can extract valuable information. Not only would it give them a list of all devices connected to the network, but owning the router would allow an attacker to change the DNS settings to a rogue server, enforce blacklists or remove router-level blocking to websites, and even install custom firmware that gives an attacker full control over your internet traffic.

Even if a hacker can't get into your router, most modern home networks host a myriad of IoT devices, which are often more susceptible to attacks compared to home-grade routers.

Unfortunately, IoT devices are usually built with the absolute minimum of security features in place on the assumption that an attacker wouldn't be able to get into the home network to access them.

Browsers shield against such attacks through a mechanism known as domain pinning. Essentially, once a browser session is established, the IP resolution for the domain is pinned. Even if the DNS cache is compromised, this prevents the IP for the domain from being reassigned mid-session, effectively thwarting this type of attack. 

A VPN provider can also keep you safe from this type of attack if their DNS resolvers can detect rebinding attacks or employ DNSSEC.

VPNs and DNS Leaks

By now, you should have a fairly good idea of the range of attacks that DNS servers can facilitate.

VPN providers play a massive role in reducing the prevalence of DNS-based attacks on the internet. While a well-managed VPN can't keep you safe from every variant of a DNS attack, enforcing access to a strict pool of DNS resolvers managed by your VPN provider significantly reduces the number of potential threats you’re exposed to.

There’s another benefit to using VPNs to improve your DNS safety. The attacks I’ve talked about so far assume that a hacker is trying to infiltrate your systems or deny you access to the Internet. They're not the only ones who can use DNS to malicious ends – your ISP can monitor your activity on the Internet just by recording your DNS requests and seeing which domains you're asking for.

Even worse, if your VPN doesn't send DNS requests through its encrypted connection, your IP address is exposed every time you make a request.

Many public Wi-Fi points also use their own DNS servers to enable data collection for marketing intelligence. Even if your VPN client uses an encrypted tunnel to transmit your DNS requests, it might not consistently send them to the VPN’s DNS server, potentially exposing your browsing activity to whichever DNS server is set on the public Wi-Fi.

Unfortunately, there are quite a few VPN providers that don’t take DNS leaks seriously. Even if a VPN provider does protect against VPN leaks, it's unlikely they provide their own DNS servers.

Consider NordVPN and ExpressVPN if you're on the hunt for a VPN with DNS protection, as they both run their own private encrypted DNS servers.

This minimizes the likelihood of your IP being linked to a third party and prevents your ISP from spying on you by directing all of your DNS requests through its servers.

As an added bonus, VPN-managed DNS services maintain blacklists and actively drop connections to known malware distributors, phishing sites, and advertising networks. 

As VPN providers become increasingly competitive in terms of features and quality, the differentiating factor is rapidly becoming "the basics done well". DNS is one of these essentials. Going forward, it's going to be a necessity for VPN providers to invest in their own, well-configured DNS resolvers to protect users against a wide world of DNS-based attacks and surveillance.