[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-talk] Fwd: Interesting cases regarding DNS poisoning in China

Thought this post would be of interest to tor-talk:

---------- Forwarded message ----------
From: Percy Alpha <percyalpha@xxxxxxxxx>
Date: Sat, Apr 27, 2013 at 3:46 PM
Subject: [liberationtech] Interesting cases regarding DNS poising in China
To: liberationtech <liberationtech@xxxxxxxxxxxxxxxxxx>

Hello, I'm with the GreatFire.org team and we observed some interesting
cases regarding DNS poising in China recently.
The domain "webcache.googleusercontent.com" has long been DNS poisoned by
GFW. When a user in China, *nslookup  webcache.googleusercontent.com
*(or any foreign IP),GFW will detect this action and return a fake response
which is much faster than the authentic one. The user might be a DNS
operated by local ISP in China. So any DNS server in China will cache the
fake response as well.

But something interesting happened this April.
https://en.greatfire.org/https/webcache.googleusercontent.com If you click
the red dates in April to see the technical detail, you will see that this
domain is still being poisoned by GFW, as can be seen from Invalid Dns
Server Dig Host Ip. However, the responses return by local DNS are valid,
as can been seen from Dig Host Ip.

We observe this phenomenon on multiple google domains, including
https://en.greatfire.org/https/webcache.googleusercontent.com (All local
DNS give correct response)
https://en.greatfire.org/https/plus.google.com(All local DNS give correct
https://en.greatfire.org/https/groups.google.com (All local DNS give
correct response. The domain has *never* been successfully poisoned even
though GFW is poisoning it.)

https://en.greatfire.org/https/drive.google.com (only gives
correct response)
gives correct response) a public DNS operated by tencent- a large IT company in
China, rather than local ISP.

https://en.greatfire.org/https/sites.google.com (No local DNS gives correct
response. This should be the standard behavior)

However, other domains, including https://en.greatfire.org/youtube.com,
facebook and twitter are still poisoned as usual. In other words, local DNS
will cache fake responses.

We want to ask why such phenomenon happened. Because if we can make use of
it, we can un-poison domains. Together with https, GFW will become useless.

One hypothesis is DNSSEC. As the recursive DNS inquiry route is secured(
http://dnsviz.net/d/webcache.googleusercontent.com/dnssec/) from ". to com"
but not "com to googleusercontent.com". So if GFW poisons the response
before the last step, DNSSEC might prevent the poisoning if the user
supports DNSSEC. However, accoding to this logic, youtue.com(or any .com
domain) should not be poisoned either
http://dnsviz.net/d/youtube.com/dnssec/. So we have no idea if this
phenomenon is related to DNSSEC at all. This phenomenon only happened on
April, while DNSSEC implementation on root server happened long ago.
Or is it related to whether the domain uses cname or A-record?

If we can make use of it, we can potentially destroy GFW in a single
strike. So please help us get to the button of it.

Percy Alpha(PGP <https://en.greatfire.org/contact#alt>)
GreatFire.org Team
tor-talk mailing list