Have you ever had the annoying experience where you enabled your VPN and browsed to a blocked website, only to discover that site will not load? And, frustratingly, other blocked sites would work completely fine?
Well, today I’ll explain to you what DNS poisoning is, what DNS is, and why you have to make use of a bizarre workaround on iOS. Let’s get started!
What is DNS?
DNS stands for Domain Name System. It’s used to translate human-readable domains into IPv4/IPv6 addresses.
You’ve probably heard of this analogy thousands of times. Suppose you want to go to twitter.com. Your browser sends a request to the DNS server, ‘twitter.com’, and gets back an IP address as a response. Then the browser makes the actual request to Twitter’s servers using the unique IP address representing Twitter.
But, how did the browser contact your DNS server? Well, even if we’re simplifying everything it’s important to keep in mind that your operating system will probably be the one making the request, not your browser, except that’s getting all befuddled because of DNS-over-HTTPS, or DNS-over-TLS, and now browsers do make DNS requests sometimes, but it’s not widely available yet… Sorry, I made it overly complicated again. Let’s go back to the main topic – how does the computer know how to communicate with the DNS server?
DNS servers are usually known to the computer by an IP address, not a domain. The most notable example is Google’s DNS service –
18.104.22.168 – or CloudFlare’s DNS –
22.214.171.124. You configure them in your router’s DHCP settings, and then your router tells all of your connected devices: “Hey, connect to
x.x.x.x for your DNS queries!”
“Hold up just one minute.” You say. “I never configured no stinking DNS address on my router!” Well, for starters, that’s a double negative, and for the actual serious explanation: you don’t have to. Often, your internet service provider will be hosting an additional DHCP server, which your router will tune into to get the DNS address from. It’s DHCP servers all the way down!
But here’s where the problem occurs. Suppose your ISP is bad. Suppose your country is restrictive. Suppose they filter your DNS queries. Wouldn’t it theoretically be possible to alter the DNS address so that state actors could intercept and even modify your DNS queries?
Yes. And that is called:
DNS poisoning occurs when a malicious DNS server sends back an IP address that does not correspond to the actual IP address associated with a domain name. Think back to the ‘twitter.com’ example. Let me show you what my DNS server sends back when I query for it:
Let’s break this down! The dig command is used to make a query to the DNS server. In the ANSWER SECTION, we see that we received an A record response of
104.2x4.42.x5 (actual IP address censored to prevent bots from scraping it). And we see that the DNS server used was
126.96.36.199 at port
So we would expect that all DNS servers would send us that IP address,
104.2x4.42.x5, to connect to Twitter’s servers.1 But what happens when they don’t?
“Yeah, can I redirect them to my own server’s IP address?”
Let’s see. All modern websites are protected by SSL certificates and something called HSTS. Long story short, it is hard to get led into a malicious web server. Provided that you are on a sufficiently updated and secured operating system and recent browser, your browser will quickly detect something is wrong and show you a “This connection is not secure” error message.
But what if the end goal is to prevent you from visiting that website?
This is what most state-level firewalls do, like the ones found in China, Israel, and so on. (Do keep in mind that it isn’t the ONLY thing that these firewalls do!) They poison your DNS queries and send back bogus answers, because as they can control the ISPs, they can direct the DHCP servers at the respective ISPs to direct users to their own censored DNS servers.
“But what about SSL certificates and what not? I thought you said that would protect me!”
Yes, it protects you from a malicious server masquerading as something it is not. Think of it as this way – my phonebook also lists addresses for my friends. Suppose I want to visit my friend Tom. If I look at my phonebook (DNS server) and look up an address for my friend Tom, and the phonebook is an evil phonebook that directs me to my enemy Dave, then I will know that this is not Tom’s address when I see he looks completely different from Tom’s facial features (SSL and HSTS). But imagine if your phonebook directs you to… nowhere? Or to yourself? You’ll be left confused.
Because your own computer (localhost) is not actively hosting a web server, your browser will be pinging your own computer for a non-existent web server until it times out and fails.
So why does it affect my VPN?
Try this: turn on your VPN and browse to a blocked site. Voilà, it works!
Now, reboot your phone.
Try this: go to a blocked site. The site will obviously not load, as it is blocked. Now, turn on your VPN and browse to the blocked site. What? Why doesn’t it work?
What’s the difference?
In the first scenario, your DNS query went through your VPN. If you have a good VPN provider they will have their own DNS server that provides good responses. Therefore, you got a good address and was able to connect to the blocked website.
But in the second scenario, your DNS query went to your poisoned DNS server, which sent back a bogus answer. Now, even if you activate your VPN, that bogus answer is cached and used again. This is because all modern operating systems and browsers cache DNS responses so that they can be fast. Imagine if they did the query hundreds of times while you browsed Twitter or YouTube! DNS records don’t change that quick, so a cache of an hour or so is completely acceptable for a good browsing experience.
So if you ever fall into the second scenario, you can reset your DNS cache. But how? Simple. I wrote a blog post about it three months ago to help you guys out!
However, in that blog post, I said there was no known method for flushing the cache on iOS. Yes, you can reboot, but that takes too long.
Well, as a completely bizarre workaround, you can actually enable airplane mode. Doing so will flush the DNS cache (what?!) and save you from rebooting your device.
Weird workaround! But hey, whatever works, works!
One thing to note here is that, due to CDNs, your query may report a different IP address than what is shown above. It is also possible that Twitter has already cycled through to a new IP address by the time you are reading this article. This is completely normal and something that happens all the time. DNS records get updated every day, yet it’s all transparent to you so you don’t have to remember any IP addresses! Think of it as a constantly updating phonebook that you never need to pay attention to. ↩