[dns-operations] Google DNS in mainland .cn

Shane Kerr shane at time-travellers.org
Sun Jan 22 06:30:10 UTC 2017


John,

At 2017-01-21 14:30:55 -0600
John Kristoff <jtk at depaul.edu> wrote:

> This might be best directed at Google, but I'd welcome unofficial
> insight as well.  It doesn't strictly apply just to Google, but they
> are often the de facto resolver choice for many systems.

The GFW does modify return packets, like I described here:

https://lists.dns-oarc.net/pipermail/dns-operations/2016-June/014962.html

It seems to be basically the same now.

Presumably blacklisted answers will break if DNSSEC is used, but I
checked the Wikipedia page with blacklisted sites, and none of them are
using DNSSEC:

https://en.wikipedia.org/wiki/Websites_blocked_in_mainland_China

:(

> I'm interested in the current state of access (DNS client queries)
> to Google DNS resolvers (8.8.8.8, 8.8.4.4 and IPv6 equivalent) from
> within mainland China.  Particularly availability and trustworthiness.
> Keyword triggering by the GFW is not a big concern, but the just idea
> that something may be tampered with is not reassuring.

I'm sitting in Beijing right now.

It looks like some traffic to 8.8.8.8 goes through the GFW:

$ mtr --report-wide 8.8.8.8
Start: Sun Jan 22 13:36:33 2017
HOST: pallas                                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- gateway                                     0.0%    10    3.8   4.8   3.7   7.6   1.3
  2.|-- 10.255.45.4                                 0.0%    10    0.7   0.5   0.4   0.7   0.0
  3.|-- 118.145.7.131                               0.0%    10    2.4   3.2   1.3  16.6   4.7
  4.|-- 10.244.246.41                               0.0%    10    4.4   3.7   2.5   8.3   1.9
  5.|-- 10.244.244.1                                0.0%    10    2.6   2.6   2.5   2.7   0.0
  6.|-- 10.244.200.1                                0.0%    10    2.7   3.6   2.6   9.4   2.2
  7.|-- 124.202.11.81                               0.0%    10   50.3  11.1   3.5  50.3  13.9
  8.|-- 202.99.1.225                               40.0%    10    3.4   4.4   3.4   8.2   1.8
  9.|-- 218.241.244.98                              0.0%    10    3.9   8.0   3.7  14.1   4.2
 10.|-- ???                                        100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- bj141-142-118.bjtelecom.net                 0.0%    10    3.9   4.0   3.8   4.4   0.0
 12.|-- 202.97.53.86                                0.0%    10    8.8  11.2   7.1  16.2   2.9
 13.|-- 202.97.53.226                              10.0%    10    7.2   8.1   6.9  10.7   1.1
 14.|-- 202.97.52.34                                0.0%    10  227.5 222.2 217.1 227.5   3.0
 15.|-- ix-xe-2-3-3-0.tcore1.LDN-London.as6453.net 20.0%    10  181.7 178.2 176.6 181.7   1.6
 16.|-- 72.14.218.214                              10.0%    10  166.0 169.3 165.9 175.5   3.3
 17.|-- 108.170.246.225                            30.0%    10  263.5 293.8 263.5 336.4  32.0
 18.|-- 74.125.37.119                              50.0%    10  261.4 283.1 261.4 327.6  27.7
 19.|-- google-public-dns-a.google.com             30.0%    10  256.9 269.7 254.5 327.2  26.1

But my traffic to 8.8.4.4 gets dropped on the floor:

$ mtr --report-wide 8.8.4.4
Start: Sun Jan 22 13:37:25 2017
HOST: pallas                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- gateway                      0.0%    10    4.3   8.9   3.7  53.3  15.6
  2.|-- 10.255.45.4                  0.0%    10    0.4   0.6   0.4   0.7   0.0
  3.|-- 118.145.7.131                0.0%    10    1.3   2.0   1.2   7.7   1.9
  4.|-- 10.244.246.41                0.0%    10    3.1   3.2   2.5   6.0   1.1
  5.|-- 10.244.244.5                 0.0%    10    2.8   2.9   2.6   3.5   0.0
  6.|-- 10.244.200.1                 0.0%    10   19.6   9.9   2.6  29.0   8.9
  7.|-- 124.202.11.109               0.0%    10    3.4   4.5   3.4   8.2   1.6
  8.|-- 202.99.1.213                 0.0%    10    5.6   4.1   3.4   5.6   0.6
  9.|-- 218.241.244.98               0.0%    10    4.0   4.0   3.6   4.3   0.0
 10.|-- ???                         100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- bj141-142-118.bjtelecom.net 20.0%    10    3.7   3.9   3.7   4.3   0.0
 12.|-- 202.97.53.98                 0.0%    10   33.2  34.2  31.6  38.8   1.8
 13.|-- 202.97.58.118               20.0%    10   28.9  15.7   5.8  28.9   7.7
 14.|-- 202.97.61.54                10.0%    10   68.9  69.2  65.4  72.0   2.0
 15.|-- 202.97.122.70                0.0%    10   53.8  48.7  41.3  64.4   7.3
 16.|-- 108.170.241.33              10.0%    10   69.7  69.1  67.2  70.1   0.6
 17.|-- 216.239.43.187               0.0%    10   47.4  47.1  40.3  62.0   8.9
 18.|-- ???                         100.0    10    0.0   0.0   0.0   0.0   0.0

(Lovely all those RFC 1918 addresses.)

We're connected to the academic network here. There are basically 4
networks in China: 3 commercial and 1 academic. I don't know what
blocks the commercial networks have.

Unlike the general case for TCP port 53, TCP connections to 8.8.8.8:53
get a TCP reset.
 
> I'm considering whether it would be OK to utilize a traditional
> resolv.conf that points to Google DNS for some systems or if I should
> just start getting used to implementing something like dnscrypt or DNS
> over TLS to try avoid potential problems.
> 
> I've searched around the net a bit and have seen some of the GFW
> papers in the past, but a current and clear status of the situation I
> couldn't find.  Thoughts and experience welcome.  Thanks in advance.

The answer depends on what you are trying to do.

You're not going to be able to get to most blacklisted sites, even if
you can resolve their DNS names, because they are blocked at the IP
layer too.

Using a VPN can circumvent all of this, and the GFW doesn't seem to
block VPN packets going to arbitrary IP addresses. At least, I am able
to run a VPN on a VPS that I have and it works, whereas commercial VPN
are often blocked. However, since the GFW also seems to drop anywhere
from 5% to 60% of packets depending on the network weather, using a VPN
for all Internet access sucks. (Plus in some cases routing is broken...
my traffic to many sites in Europe goes through the US, basically
taking 2x as long as it needs to.)

My own thinking is that an ideal solution would be one that detects GFW
interference and routes only traffic modified by it to a VPN. Right now
the GFW breaks resolution because answers from referral servers (for
example gtld-servers.net) get modified. So a smart resolver could try
queries that fail DNSSEC over a VPN, and if they work then a routing
table could be updated to forward traffic for the resulting A/AAAA
records over the VPN. (An "upgrade" to the GFW which modifies only
answers without DNSSEC signatures would break this scheme, because the
delegation from the referral servers would work, and since nobody signs
their delegation the final answer could be modified by the GFW
without anyone being able to detect it.)

Or you can just whitelist certain sites and use the VPN for them. Maybe
simpler is better? :)

One approach that might help with the high packet loss and latency of
the GFW is to refresh caches super aggressively. (This is especially
important if you are using a VPN, since all DNS lookups will incur
those penalties then.) What I mean is, even when no client asks for a
query, keep it in cache and re-ask the authority server again before the
records expire. (We may try this here. We have queries that users issue
infrequently which take more than a second the resolve fully and stub
resolvers timeout.)

Finally, if you are using a VPN getting one with good connectivity to
China is a win. I find that Hong Kong tends to have pretty good
connection with mainland China, and the Internet access there seems to
be relatively unfiltered... at least the GFW is not there yet. A number
of VPN vendors have terminations in Hong Kong, although as I mentioned
VPN vendor traffic is often blocked. You can get a VPS in Hong Kong for
like $12/month from  Alibaba Cloud though and run your own (warning: I
haven't tried this, but will Real Soon Now).

Cheers,

--
Shane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20170122/d875f3f8/attachment.sig>


More information about the dns-operations mailing list