[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