[dns-operations] Quick DNS report from behind the Great Firewall of China

[Shane Kerr]

Hello,

I'm doing some work comparing IANA root server answers with Yeti root
server answers. As a baseline I decided to compare IANA servers with
themselves, and discovered differences. I am doing this work in China
right now, so I probably should have expected something like this,
because of the Great Firewall and all of its evil.

So here are some observations about DNS and the Great Firewall of
China, from my hotel room. Note that I am not encouraging anyone to
bypass Chinese laws or regulations, but as a technical DNS person I
find the details interesting and thought other people would too.

After a little poking around it seems that there is some DPI happening
for all DNS packets that come into China via the Great Firewall. This
means that, for example, the F, J, and L root servers are not impacted
by the Great Firewall since they have instances in Beijing. (Packets
from some root servers are *sometimes* modified, like I root, and I'm
not sure why that is.) I didn't look at any TLD. I don't know
if any have servers in China other than the various Chinese TLDs.

It looks like there is a blacklist. Of course I can't know the full
extent, but I did notice that answers for "google.com" and
"twitter.com" are modified. If you query anything on the list, then you
get an A record back with some IP addresses that are not always the
same, but also not completely random.

WHOIS lookup on some of the addresses shows valid networks in Germany,
Azerbaijan, the UK, and so on. When I traceroute to these IP addresses
though they terminate at a hop within the China Unicom network, which
seems to be the provider that I'm currently connected to - so while I
would consider it BGP hijacking, as Randy Bush says, "your network, your
rules". ;) My guess is that there is some disk somewhere recording all
packets that try to get to those addresses and making a careful note
for future auditing, but perhaps these packets are just dropped on the
floor. (The NSA would save these, maybe the Chinese officials are
smarter though?)

It looks like the DNS answers are being modified on the return path, not
the outbound path. At least, I can query IP addresses I run for
"google.com" and I see the query packets at that host ("dig @my.host
google.com").

It looks like TCP is not being intercepted, so a simple approach for
someone in China wishing to get clean DNS might be to use TCP to a
resolver outside of China. A Linux host can usually do this by setting:

   options use-vc

In the /etc/resolv.conf file.

If you want to run a resolver *inside* of China and get the answers that
authority operators are actually returning, this is probably also
possible, although trickier.

Right now, it seems that NS records are not being intercepted. This
means that if you use QNAME minimization, a resolver in China should be
able to get information on (for example) the Google name servers.
UDP answers from those servers will be spoofed.

These spoofed A records are not signed (of course), so anyone performing
DNSSEC validation will reject the spoofed answers.

Since TCP is not being intercepted, a resolver can:

1. Use QNAME minimization to get to the authoritative servers, then
2. Reject UDP answers because validation will break, and then
3. Use TCP to get a valid answer.

I don't know if any resolvers can work this way, but in principle it is
at least *possible*.

To be clear, this won't actually let you get to any blocked server,
since there are IP layer blocks in place too, but at least DNS will be
correct. :) (Actually, detecting such blocks could allow someone to
build a middlebox which used VPN only when needed and otherwise used
normal upstream. Hm...)

Cheers,

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