It is well-known, for many years, that the
This technique have been studied and documented in several
papers such as "The Great DNS
Wall of China" or "Source
code to identify the fake DNS packets from
China". Basically, every DNS request in a chinese network,
whatever the destination IP address, is examined and, if the qname
(Query Name) in it matches a predefined list of censored domains,
a fake reply is generated and sent to the requester. The bad
consequences of this technique outside of
To see this DNS tampering, one just has to query any IP address
in China (it does not need to be an existing machine, since the
fake DNS reply is made by the network, not by an evil DNS server,
the address here was choosen at random and tested to be sure it
does not reply to any other packet):
> DiG 9.9.5-8-Debian <<>> @218.76.74.42 A www.ssi.gouv.fr
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
]]>
As expected, this non-existing machine does not reply. But if we
try with a censored name, here
> DiG 9.9.5-8-Debian <<>> @218.76.74.42 A www.facebook.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30344
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.facebook.com. IN A
;; ANSWER SECTION:
www.facebook.com. 2655 IN A 67.205.10.141
;; Query time: 313 msec
;; SERVER: 218.76.74.42#53(218.76.74.42)
;; WHEN: Wed Feb 04 12:06:43 CET 2015
;; MSG SIZE rcvd: 50
]]>
This time, we get an IP address, and completely unrelated to
Facebook (it is a USAn hoster). It is not just a match of the
string that triggers the lying answer, the system actually
understands DNS:
> DiG 9.9.5-8-Debian <<>> @218.76.74.42 A www.facebook.com.example.net
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
]]>
Besides going to China and testing from your laptop, there are
other ways to see this DNS tampering: one is to use the RIPE Atlas probes. Few of
them are in China and many seem immune to the DNS tampering,
probably because they are located on a network with a safe
% python resolve-name.py --country=CN --requested=30 www.facebook.com
Measurement #1854647 for www.facebook.com/A uses 15 probes
[66.220.158.19] : 4 occurrences
[179.60.192.3] : 2 occurrences
[31.13.79.246] : 3 occurrences
[31.13.68.84] : 3 occurrences
[173.252.74.22] : 1 occurrences
[153.122.20.47] : 2 occurrences
[31.13.68.70] : 3 occurrences
[67.205.10.141] : 1 occurrences
[173.252.73.52] : 1 occurrences
[114.200.196.34] : 1 occurrences
[31.13.76.102] : 1 occurrences
Test done at 2015-02-04T11:11:19Z
(The program
And a last solution is to use the cloud, actually a Web site hosted in China which allows you to perform DNS requests, for instance, .
Until the beginning of 2015, the returned IP addresses were
apparently non-reachable addresses, unallocated, or even "class D"
(
The first report, seen from the chinese site (chinese users sent to unexpected Web sites) was "Visitors to blocked sites redirected to porn". Many other reports documented the other side, the point of view of the site suddently receiving chinese traffic. See "Fear China", "DDOS on La Quadrature du Net, analysis" or "DDoS from China – Facebook, WordPress and Twitter Users Receiving Sucuri Error Pages".
Let's look at this traffic, as seen by one of the Web servers
of
(The source IP address was from "Graduate University of Chinese Academy of Sciences") The request is for
]]>
Unfortunately, the HTTP server, like most HTTP servers, did not log
the Host: field in the HTTP request. This field indicates which host
was requested by the client. Here, we can guess it was
x.y.z.t - - [21/Jan/2015:00:53:33 +0100] "GET /plugins/like.php?href= [...] "Mozilla/5.0 (Linux; U; Android 4.4.4; zh-CN; L39h Build/14.4.A.0.108) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 UCBrowser/10.0.0.488 U3/0.8.0 Mobile Safari/534.30" 0 www.facebook.com
The
Another very common HTTP request is:
(The original source IP address was "China Mobile Communications
Corporation".) The requested path,
OK, so we see a lot of HTTP traffic, coming almost only from
chinese IP addresses, and we see that the requested names are indeed
censored in China. Can we prove that the Great FireWall redirected to
the IP addresses of the victims? We can do it with , a passive DNS (a system which records DNS answers observed on the network)
database located in China. First, we can check (like we did with
% flint rrset tracker.thepiratebay.org A
[api error]: http://www.passivedns.cn/api/rrset/keyword/tracker.thepiratebay.org/rtype/1/
:-( This request works for non-censored names. I suspect that censored
names, being redirected to many IP addresses, exceed some limit of
PassiveDNS.cn, leading to this bug. But the Web interface of
PassiveDNS.cn still works so we can see indeed that we have many IP
addresses for
% flint rdata 212.234.228.143 A | more
212.234.228.143 A In rdata
--------
50congres.cgt.fr 212.234.228.143 2014-11-26 10:10:13
accounts.youtube.com 212.234.228.143 2015-01-28 10:26:25
adecco.cgt.fr 212.234.228.143 2014-11-29 12:56:14
adm-salaries.cgt.fr 212.234.228.143 2015-01-04 06:39:26
aful.cgt.fr 212.234.228.143 2015-02-04 06:04:32
platform.twitter.com 212.234.228.143 2015-01-15 23:20:37
plus.google.com 212.234.228.143 2015-02-03 03:23:34
tracker.thepiratebay.org 212.234.228.143 2015-01-31 23:58:02
www.bloomberg.com 212.234.228.143 2015-02-01 10:00:13
www.facebook.com 212.234.228.143 2015-02-01 21:37:59
www.kanzhongguo.com 212.234.228.143 2015-01-15 23:18:35
...
So, we can see that the original interpretation is correct: the Great
Firewall, through DNS tampering, redirects many very popular names to
innocent servers.
How many sites are used as "sinkholes" by the chinese censorship
system? Let's query repeatedly
205.186.162.167 (MEDIATEMPLE - Media Temple, Inc.,US): 26
77.66.57.6 (NGDC NetGroup A/S,DK): 24
205.157.169.156 (ASN-PENNWELL - PennWell corporation,US): 24
216.201.83.226 (NATIONALNET-1 - NationalNet, Inc.,US): 24
64.20.49.2 (NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US): 24
193.188.112.80 (AS6453 - TATA COMMUNICATIONS (AMERICA) INC,US): 23
114.130.54.22 (BCC-MANGOCLIENT-AS-AP Bangladesh Computer Council,BD): 22
216.57.200.175 (WHIDBEY1 - Whidbey Internet Services,US): 22
74.121.192.250 (BLACKMESH-RST - BlackMesh Inc.,US): 21
137.117.70.70 (MICROSOFT-CORP-MSN-AS-BLOCK - Microsoft Corporation,US): 21
70.32.110.223 (MEDIATEMPLE - Media Temple, Inc.,US): 21
184.173.133.194 (SOFTLAYER - SoftLayer Technologies Inc.,US): 21
5.9.26.245 (HETZNER-AS Hetzner Online AG,DE): 20
195.205.239.197 (TPNET Orange Polska Spolka Akcyjna,PL): 20
222.230.141.241 (VECTANT VECTANT Ltd.,JP): 20
91.213.100.50 (BRACK-AS Brack.ch AG,CH): 20
14.139.212.165 (NKN-CORE-NW NKN Core Network,IN): 20
54.235.118.83 (AMAZON-AES - Amazon.com, Inc.,US): 20
200.57.151.168 (Triara.com, S.A. de C.V.,MX): 20
62.109.134.70 (IGNUM-AS Ignum s.r.o.,CZ): 20
...
As you can see, many IP addresses are used in the Great FireWall lies.
Now, let's indulge in some speculation. How are the IP addresses of
the victim choosen? At random, and the Great FireWall administrators
do not care of the consequences? On purpose, to turn every chinese
Internet user into an involuntary accomplice of the
This sort of "attack by referral" is a scourge of the Internet, because there is a very little to do against it. A famous example a few years ago, not involving the DNS, was D-Link NTP "attack".
Thanks to Benjamin Sonntag and Éric Duval for the data.