41

I live in a country which is under many sanctions. Both internal sanctions (government on people) and external sanctions (US on our people).

In our country, YouTube, Twitter, Facebook and many other sites are blocked by default and we can only access them through VPN.

But there is one thing that should work: DNS. If I set my DNS to 8.8.8.8, theoretically it should return the right IP address for www.youtube.com and that IP address should get blocked by the ISP.

But it is not. It looks like our government is manipulating the DNS servers, even the public ones.

I have Ubuntu 18.04 (Bionic Beaver), and I have disabled Network Manager DNS. I have disabled resolvconf and systemd-resolve, by which I mean that no entity in my own system can change the file /etc/resolv.conf.

I changed the content of /etc/resolv.conf to:

nameserver 8.8.8.8

and only this name server. So now every application uses this server by default, and they should query this server for the IP address of websites, but unfortunately they are not doing so!

kasra@ubuntu:~$ nslookup google.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   google.com
Address: 216.58.214.110
Name:   google.com
Address: 2a00:1450:4001:812::200e

kasra@ubuntu:~$ nslookup youtube.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   youtube.com
Address: 10.10.34.35
Name:   youtube.com
Address: 10.10.34.35

kasra@ubuntu:~$ nslookup twitter.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   twitter.com
Address: 10.10.34.35
Name:   twitter.com
Address: 10.10.34.35

kasra@ubuntu:~$ █

10.10.34.35 is the intranet IP address for the filtering authority.

How is the ISP achieving this? Are they really stealing and MITM-ing the traffic of 8.8.8.8? Is it some kind of BGP hijack?

How can I get around this without a VPN?

Peter Mortensen
  • 877
  • 5
  • 10
AlwaysLearner
  • 499
  • 4
  • 6
  • 10
    ...if they control the ISP, they can read everything, and modify anything you attempt to access, DNS or otherwise. SSL only helps if you downloaded the root certificates over an "independent" channel - in a tech-savvy totalitarian regime, you have a bootstrapping problem (your only channel is opponent controlled). – Clockwork-Muse Aug 14 '18 at 06:59
  • The problem you face is a called "DNS Leak", which mostly due to mislook DNS request that bypass VPN. Another common DNS leak misconfiguration is overlooking IPv6 DNS request. – mootmoot Aug 14 '18 at 07:17
  • 6
    say you add youtube's ip adresses to your hosts.conf `208.65.153.238, 208.65.153.251, 208.65.153.253, 208.117.236.69` and try to access youtube. does that work or will the request to the ip adress also be blocked by your isp? because if that is blocked then as well a fix for the dns won't help you either. Also, without a vpn your ISP will know what you're requesting and might pass that info on to the authorities. – Tschallacka Aug 14 '18 at 09:18
  • 5
    [DNScrypt](https://www.opendns.com/about/innovations/dnscrypt/) *may* be helpful in your situation. – northerner Aug 14 '18 at 10:33
  • 12
    thank God they didn't block stackexchange! – Srinath Ganesh Aug 14 '18 at 11:28
  • you can test for MITM by comparing the difference in latency between a "ping" to a given server and a DNS lookup (e.g. with `dig`). If the DNS lookup response is returned much faster than a ping is you can be reasonably sure that there's a more local interception going on. – Alnitak Aug 15 '18 at 13:26
  • as an example of this, an acquaintance was recently in the middle east and could see ping RTTs of 50ms+ to reach one of the root DNS servers, and that server was known to geographically be in India so those RTTs were consistent with the distance involved. However DNS queries sent to that same address were being responded to within a coupe of milliseconds, so clearly were not coming from India. – Alnitak Aug 15 '18 at 16:29
  • @mootmoot No, If I use a vpn I dont have dns leak and everything is fine. This situation happens on default, i.e. nothing in between me and internet. – AlwaysLearner Aug 20 '18 at 12:53
  • @Tschallacka neigher of these ips come up. The browser keeps trying. I neither can ping these IPs. I think the traffic is captured. – AlwaysLearner Aug 20 '18 at 12:54
  • @northerner Yeah dnscrypt can help to get IPs, but the IPs themselves are blocked too. – AlwaysLearner Aug 20 '18 at 12:56
  • @SrinathGanesh Actually they are blocking imgur and many CDNs. Which in turn causes images not to load and I am facing a page that looks like 1980s ... – AlwaysLearner Aug 20 '18 at 12:59
  • @Alnitak no their difference is 50 to 70 ms. – AlwaysLearner Aug 20 '18 at 13:01
  • @Alnitak sometimes in the past, When I connected to internet, my Ip was for romania, russia etc.. I dont live in romania, etc.! I dont know the reason, but this kind of stuff used to happen (and happens occasionally). – AlwaysLearner Aug 20 '18 at 13:06

4 Answers4

48

How are they (ISP) achieving this, Are they really stealing and MITM ing the traffic of 8.8.8.8?

They probably simply redirect all packets with destination port 53 (i.e. DNS) to their own servers and answer the query themselves. This is not that hard to do.

How can I get around this without VPN?

A properly configured VPN (i.e. no DNS leaks) can get around this (unless they block VPN too). Also using a HTTP proxy or SOCKS proxy can help (make sure to configure external name resolution for the last one) for HTTP and HTTPS traffic. And DNS privacy techniques like dnscurve, dnscrypt, DNS over TLS and DNS over HTTPS (supported already by Firefox) will help too.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Actually I think dns crypt and stuff like these can not help me. The IP address themselves are blocked (I know if the ip addresses are dynamic It can help but it is by chance and I dont like browsing web by chance) – AlwaysLearner Aug 20 '18 at 13:08
  • I currently use Shadowsocks which Is created by myself for me and some of my friends. It works perfectly. – AlwaysLearner Aug 20 '18 at 13:10
21

unfortunately they are not doing so!

They are doing so, and your typescript shows it happening, with nslookup querying that IP address and getting answers from it.

Your confusion stems in part from a misconception of what 8.8.8.8 is. It is an anycast IP address. Traffic sent to it is routed to the network interfaces of multiple machines around the world, run by Google in various datacentres. That routing is done by every node that it is sent to, including one's own ISP immediately after it leaves one's own network(s).

Firstly, Google itself can make those machines behave differently in different countries. It can make the machines in one country answer differently to the machines in other countries, if it decides to, or if it is required to by authorities in that country.

Secondly, the content DNS servers that Google Public DNS queries from its back end can respond differently to different Google machines. Their back end IP addresses, and what countries they correspond to, are published as part of the Google Public DNS doco. Content DNS servers giving out different answers to different clients (clients here being the back ends of resolving proxy DNS servers) based upon their source IP addresses is a feature in several DNS server softwares.

Thirdly, ISPs subject to a particular country's jurisdiction can be told to simply route the anycast to other machines under the control of someone other than Google. As happened in Turkey in 2014. It has been claimed that Taiwan has similar plans.

Iran was already doing this a year before Turkey. Iranian ISPs intercept all DNS/UDP traffic routed through them and respond to it from machines under Iranian control. Interestingly, this appears to be not done very competently, as dummy TCP (sic!) packets still pass through to the original machines.

(The same happens to Cloudflare's 1.1.1.1 service, but less for political and censorship reasons and more because of human laziness and foolishness. It has long been abused as a test IP address or as an unofficial extra private IP address range, by people programming routers and others.)

Of course, if one arranges that DNS traffic leaves one's own machine over the VPN rather than directly to one's ISP, then all three of these change. The traffic goes via the VPN to a different Google machine in a different country, that sends its back-end queries from a different source IP address, and that isn't routed to 8.8.8.8 by one's ISP.

The downside of appearing as if one is in a different country for DNS service is appearing as if one is in a different country, as Australians using Google Public DNS back in 2010 discovered. CDNs direct one to content HTTP servers that are much further away and not local. Services that are low cost or free but only within one's own country are suddenly coming from expensive content HTTP servers instead.

Further reading

schroeder
  • 123,438
  • 55
  • 284
  • 319
JdeBP
  • 681
  • 4
  • 13
  • 11
    I don't think this is related to anycast but works even without out. ISP can re-route any traffic which passes through their network, no matter if anycast or not. And even DNS servers on normal unicast addresses can serve different replies based on the source IP address (and thus geolocation) of the client. – Steffen Ullrich Aug 14 '18 at 16:09
  • 1
    You missed all of the other stuff that I wrote, explaining the consequences of anycast across machines in multiple countries, and you haven't correctly understood what server provides the variant answers. Read again. – JdeBP Aug 14 '18 at 16:52
  • 14
    I'm not sure why you reply in what I consider a not really friendly and constructive way. Anyway, I only pointed out that anycast is not needed for intercepting DNS or giving different answers to different clients, simple unicast is sufficient both for re-routing and for giving client-specific replies. And that's why I think that focusing only on anycast like you do is wrong. – Steffen Ullrich Aug 14 '18 at 17:21
  • 4
    @JdeBP there are no attacks being made &no one is suggesting that you are in any way incorrect about the function of anycast. Your phrasing at the very start of your answer seems to indicate that you see this *entirely* as a Google/anycast issue. The only suggestion being made is that the effect that the OP is seeing does not *have* to be the result of anycast routing. The same thing could happen with unicast, too (see your link Aryan et al.). Yes, the effect the OP is seeing *could* be because of anycast and Google's bespoke DNS results. But not only that. – schroeder Aug 15 '18 at 09:24
  • Untrue. "in part" is quite clear as well. And M. Ullrich is repeating a blatant error about what servers are yielding the variant results, completely at odds with _what is written in front of you both_, and then rejecting a request to read it with veiled attacks about not being "friendly". I give _four different_ ways in which things could be set up. ("Thirdly" is really two.) There is even a fifth. Please do not buy into the nonsense that "in part" translates to "entirely" or that "the content DNS servers that Google Public DNS queries from its back end" are the 8.8.8.8 anycast address. – JdeBP Aug 15 '18 at 11:07
  • 3
    I think you can safely assume that your phrasing is not as clear as you wanted it to be. "in part" appears to be in reference to the OP's confusion, not that anycast is part of the issue. Secondly, the way you have set up your answer, the 3 scenarios appear to be coupled with anycast. You might need to take a second edit to the question to make sure that the ideas you wanted to be separate are more clearly so. I, as a completely 3rd party, and trying to find support in your answer for what you mean to say, had a lot of trouble. – schroeder Aug 15 '18 at 11:44
  • 2
    I also think the text about Anycast is a distraction. A BGP hijack (if that's what this were, but it isn't) would work whether the destination server is unicast or anycast. It is *far* more likely that the ISP is directly intercepting all outbound DNS traffic to a server under their control. – Alnitak Aug 15 '18 at 13:18
  • 2
    Your text about Google getting different answers is a red herring, since without EDNS Client Subnet their caches will only maintain a single "true" answer for each domain being queried. Google only send ECS enabled queries to specific white-listed DNS servers. Furthermore, the OP showed the *same* answer being returned for both youtube (a Google service) and Twitter. – Alnitak Aug 15 '18 at 13:20
13

In short, your are being MITMed. The censor you're facing is doing something to your DNS requests directed at 8.8.8.8 so that you get non-genuine responses. There are many ways to achieve this, and different entities execute this censorship by different means. To take a closer look, use your favorite packet capture tool (Wireshark or tcpdump).

As a demonstration, I have taken a capture of me querying Google's DNS server at 8.8.8.8 for the addresses of "www.google.com".

Screenshot of nslookup

Screenshot of Wireshark

As can be seen in the Wireshark screenshot, my computer sends two DNS queries to the DNS server, one for the A record (IPv4 addresses) and one for the AAAA record (IPv6 addresses). For each request, 3 responses were received. The first two responses contain fake addresses, and interestingly, the first two responses for the AAAA query contain an A record in the answer - clearly a malformed response. The third and last response for each request contains the real IP address for www.google.com. The nslookup tool, not knowing any better, accepted the first response for each request and displayed those addresses.

This hints at what my national censor is doing. Evidently, they are not blocking network traffic to 8.8.8.8 outright. Instead they monitor such traffic, and when a DNS request for a blocked domain is found, the censor injects fake responses. The censor can't be bothered to create a proper AAAA response, hence the malformed responses. The authentic responses from the real DNS server aren't dropped, either. However, the early fake responses are enough to fool the client who made the DNS request into accepting fake addresses.

Your censor could be doing something similar, or they could be doing something completely different. Take some packet captures, and we might be able to tell more.

As for how to get around this, the practical answer is probably an local encrypted DNS proxy, such as DNSCrypt Proxy or Stubby. These tools run a DNS server on your computer, and DNS requests directed at them will be encrypted and sent to a DNS server that understands the encryption protocol. This way the censor cannot know which domain the request is for, and cannot forge responses. The censor can still block these servers outright, though.

(If you're trying to circumvent a national censor, defeating DNS poisoning alone may not be enough. You may need to use different tools for different occasions.)

twisteroid ambassador
  • 771
  • 4
  • 6
  • 1
    Try `dig +trace` next time, it will show you all DNS queries and replies done to resolve a given name, in a more DNS-related format that Wireshark. – Patrick Mevzek Aug 14 '18 at 22:09
4

Since you are running Linux, an easy way around this without a full fledged VPN is SSH tunelling. If you can set up or get an account on a server in a neutral, unfiltered location, you can tunnel your traffic through that location using SSH with just a couple of commands. You can tunnel both your dns traffic on port 53 and your web traffic through the remote machine.

You could use an Amazon Web services or Google Compute Engine instance, or just a regular remote vps.

https://www.ssh.com/ssh/tunneling/example#sec-What-Is-SSH-Port-Forwarding-aka-SSH-Tunneling

https://serverfault.com/questions/78351/can-i-create-ssh-to-tunnel-http-through-server-like-it-was-proxy

Cameron Roberts
  • 141
  • 3
  • 1
    If you live somewhere which employs such censorship, then they are likely to also monitor attempts to bypass that censorship. While its trivial to setup adequate encrpyiotn that they cannot acess the cleartext, the mere presence of recurring encrypted connections to an unusual host using anything other than https may suffice to make them very interested in what you are doing. – symcbean Aug 15 '18 at 12:13
  • `You can tunnel both your dns traffic on port 53` - standard SSH tunnel works for TCP only, where DNS runs on UDP – rkosegi Aug 15 '18 at 12:21
  • 1
    @rkosegi you are half correct. SSH tunnels indeed do not support UDP, but DNS does not *only* run on UDP. – Alnitak Aug 15 '18 at 13:22
  • good point, ssh -D sets up a SOCKS proxy, which takes care of everything. This usage is mentioned in the links, but it's not super clear from the wording in my answer that just tunelling port 53 might not work as expected. – Cameron Roberts Aug 15 '18 at 14:28
  • Ok, I use shadowsocks and and a socks proxy running locally on my machine. Can I turn this into a full fledged vpn? I heared of tap2tun, does it help? – AlwaysLearner Aug 20 '18 at 13:17