Iyfjky

Question

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?

...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). — Aug 14 at 6: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. — Aug 14 at 7:17
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. — Aug 14 at 9:18

Steffen Ullrich 104k10172242 · Answer 1 · 2018-08-14 03:39:17Z

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.

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) — Aug 20 at 13:08
I currently use Shadowsocks which Is created by myself for me and some of my friends. It works perfectly. — Aug 20 at 13:10

schroederâ™¦ 63.5k24137171 · Answer 2 · 2018-08-15 09:17:27Z

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.

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. — Aug 14 at 16:09
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. — Aug 14 at 17:21
@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. — Aug 15 at 9:24
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. — Aug 15 at 11:44
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. — Aug 15 at 13:18

score 12 · Answer 3 · 2018-08-14 15:50:09Z

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.)

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. — Aug 14 at 22:09

Cameron Roberts 1412 · Answer 4 · 2018-08-14 18:05:25Z

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

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. — Aug 15 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 — Aug 15 at 12:21
@rkosegi you are half correct. SSH tunnels indeed do not support UDP, but DNS does not only run on UDP. — Aug 15 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. — Aug 15 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? — Aug 20 at 13:17

AlwaysLearner 17425 · Answer 5 · 2018-09-04 04:48:26Z

What I learned just now is that It does not matter which nameserver you choose. DNS Traffic is being intercepted as a whole!

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

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

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

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

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

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

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

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

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

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

kasra@ubuntu:~$ nslookup youtube.com 8.8.8.8
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 youtube.com 7.7.7.7
Server: 7.7.7.7
Address: 7.7.7.7#53

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

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

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

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

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

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

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

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

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

kasra@ubuntu:~$ nslookup youtube.com 200.100.23.432
nslookup: couldn't get address for '200.100.23.432': not found
kasra@ubuntu:~$ nslookup youtube.com 200.100.23.44
Server: 200.100.23.44
Address: 200.100.23.44#53

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

kasra@ubuntu:~$

Steffen Ullrich 104k10172242 · Answer 6 · 2018-08-14 03:39:17Z

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.

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) — Aug 20 at 13:08
I currently use Shadowsocks which Is created by myself for me and some of my friends. It works perfectly. — Aug 20 at 13:10

schroederâ™¦ 63.5k24137171 · Answer 7 · 2018-08-15 09:17:27Z