DNS and the GFW



While the ability to the GFW to send RST packets in an attempt to terminate a connection between a source IP and a destination IP based on keywords appearing in packets (keyword in GET requests and possibly the HTML responses) has been documented in http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf and http://www.cs.unm.edu/~crandall/concept_doppler_ccs07.pdf China also employs a similar system to interfere with DNS. If a DNS request to resolve a hostname is sent in to an IP in China, an intermediary will respond with a DNS response containing an incorrect IP. This is not totally new, it has been documented from inside China already.

I start with a “UDP Traceroute” (DNS packets with no qname with incrementing TTL’s) in order to find the first hop inside China. The IP address of contained in the ICMP response is checked in Team Cymru‘s IP lookup service to find the AS, Country and Network Name.

1|192.168.2.1|time-exceeded  NA
2|64.230.*.*|time-exceeded CA NA
3|64.230.*.*|time-exceeded CA NA
4|64.230.*.*|time-exceeded CA NA
5|64.230.*.*|time-exceeded CA NA
6|64.230.147.14|time-exceeded CA NA
7|206.108.103.138|time-exceeded CA NA
8|160.81.109.193|time-exceeded US SPRINTLINK - Sprint
9|144.232.10.19|time-exceeded US SPRINTLINK - Sprint
10|144.232.8.169|time-exceeded US SPRINTLINK - Sprint
11|144.232.9.224|time-exceeded US SPRINTLINK - Sprint
12|144.232.9.32|time-exceeded US SPRINTLINK - Sprint
13|144.232.2.171|time-exceeded US SPRINTLINK - Sprint
14|144.223.148.2|time-exceeded US SPRINTLINK - Sprint
15|219.158.4.193|time-exceeded CN CHINA169-BACKBONE CNCGROUP China169 Backbone

For me the first CN hop to the IP address 202.165.102.247 (www.yahoo.cn) is 15. So I send a DNS request for “www.citizenlab.org” to 202.165.102.247 (which is not a DNS server) with a TTL of 15, its IP is 219.158.4.193 (CHINA169-BACKBONE CNCGROUP China169 Backbone).

###[ IP ]###
  version   = 4
  ihl       = 0
  tos       = 0x0
  len       = 0
  id        = 1
  flags     = 
  frag      = 0
  ttl       = 15
  proto     = udp
  chksum    = 0x0
  src       = 192.168.2.11
  dst       = 202.165.102.247
  options   = ''
###[ UDP ]###
     sport     = domain
     dport     = domain
     len       = 0
     chksum    = 0x0
###[ DNS ]###
        id        = 0
        qr        = 0
        opcode    = QUERY
        aa        = 0
        tc        = 0
        rd        = 1
        ra        = 0
        z         = 0
        rcode     = ok
        qdcount   = 0
        ancount   = 0
        nscount   = 0
        arcount   = 0
        \qd        \
         |###[ DNS Question Record ]###
         |  qname     = 'www.citizenlab.org'
         |  qtype     = A
         |  qclass    = IN
        an        = 0
        ns        = 0
        ar        = 0

The ICMP response comes back from hop 15:

###[ IP ]###
  version   = 4L
  ihl       = 5L
  tos       = 0x0
  len       = 56
  id        = 5984
  flags     = 
  frag      = 0L
  ttl       = 241
  proto     = icmp
  chksum    = 0xf52
  src       = 219.158.4.193
  dst       = 192.168.2.11
  options   = ''
###[ ICMP ]###
     type      = time-exceeded
     code      = 0
     chksum    = 0xc2d7
     id        = 0xeacf
     seq       = 0x3af8
###[ IP in ICMP ]###
        version   = 4L
        ihl       = 5L
        tos       = 0x0
        len       = 64
        id        = 1
        flags     = 
        frag      = 0L
        ttl       = 1
        proto     = udp
        chksum    = 0xc55c
        src       = 192.168.2.11
        dst       = 202.165.102.247
        options   = ''
###[ UDP in ICMP ]###
           sport     = domain
           dport     = domain
           len       = 44
           chksum    = 0xbca

While this is occurring I also sniff the wire to see if other packets are being sent my way, and they are. Four bad DNS responses were sent my way claiming to be from 202.165.102.247.

###[ IP ]###
     version   = 4L
     ihl       = 5L
     tos       = 0x10
     len       = 98
     id        = 45372
     flags     = 
     frag      = 0L
     ttl       = 45
     proto     = udp
     chksum    = 0xe7ee
     src       = 202.165.102.247
     dst       = 192.168.2.11
     options   = ''
###[ UDP ]###
        sport     = domain
        dport     = domain
        len       = 78
        chksum    = 0xe286
###[ DNS ]###
           id        = 0
           qr        = 1L
           opcode    = QUERY
           aa        = 1L
           tc        = 0L
           rd        = 1L
           ra        = 1L
           z         = 0L
           rcode     = ok
           qdcount   = 1
           ancount   = 1
           nscount   = 0
           arcount   = 0
           \qd        \
            |###[ DNS Question Record ]###
            |  qname     = 'www.citizenlab.org.'
            |  qtype     = A
            |  qclass    = IN
           \an        \
            |###[ DNS Resource Record ]###
            |  rrname    = 'www.citizenlab.org.'
            |  type      = A
            |  rclass    = IN
            |  ttl       = 86400
            |  rdlen     = 0
            |  rdata     = '216.234.179.13'
           ns        = 0
           ar        = 0

Summary:

192.168.2.11 > 202.165.102.247 <DNSQR  qname='www.citizenlab.org.' qtype=A qclass=IN |> 0
219.158.4.193 > 192.168.2.11   time-exceeded
202.165.102.247 > 192.168.2.11 <DNSQR  qname='www.citizenlab.org.' qtype=A qclass=IN |> 
    <DNSRR  rrname='www.citizenlab.org.' type=A rclass=IN ttl=300 rdata='64.33.88.161' |>
202.165.102.247 > 192.168.2.11 <DNSQR  qname='www.citizenlab.org.' qtype=A qclass=IN |> 
    <DNSRR  rrname='www.citizenlab.org.' type=A rclass=IN ttl=86400 rdata='216.234.179.13' |>
202.165.102.247 > 192.168.2.11 <DNSQR  qname='www.citizenlab.org.' qtype=A qclass=IN |> 
    <DNSRR  rrname='www.citizenlab.org.' type=A rclass=IN ttl=86400 rdata='216.234.179.13' |>
202.165.102.247 > 192.168.2.11 <DNSQR  qname='www.citizenlab.org.' qtype=A qclass=IN |> 
    <DNSRR  rrname='www.citizenlab.org.' type=A rclass=IN ttl=86400 rdata='216.234.179.13' |>

64.33.88.161 and 216.234.179.13 are not IP addresses that “www.citizenlab.org” should resolve to.

I used 38 IP addresses on 38 different AS’s in China as targets. A DNS packet was sent to the first CN hop from a udp traceroute to each of these IPs. The IP’s returned from the ICMP packet received from each hop are distributed across 11 AS’s in China.

In total, I received 8 unique bad IP addresses.

211.94.66.147 24403 CN CNNIC-CNCITYNET-AP Beijing Kuanjie Net communication technology Ltd
209.145.54.50 6428 US CDM - CDM
203.161.230.171 9925 HK HKTHOST-AP Powerbase DataCenter Services (HK) Ltd.
64.33.88.161 19916 US ASTRUM-0001 - OLM LLC
202.181.7.85 7489 AU FIRSTLINK-AS-AP First Link Internet Services
4.36.66.178 3356 US LEVEL3 Level 3 Communications
216.234.179.13 13911 CA TERA-BYTE - Tera-byte Online Services
202.106.1.2 4808 CN CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network

Two of the IP’s are in Mainland China and one is in Hong Kong; three are in the US and one in Australia. Only one of the CN IP’s, 211.94.66.147, has a web server running when I checked which means that this server could log IP addresses that connect to it and host name in the requests. Why these IPs?

I don’t know. It is pretty strange.

64.33.88.161 was the IP for falundafa.ca, the IP was blocked so an domains that resolved to it were also blocked. Seems to be legacy blocking.

If you $host bbs.hygung.com you’ll get back most of these IP’s, along with a bunch of others. Many of these IP’s also appear on some kind of IP blocking list (another one), RobotDog anyone? Seems to be a list for a Router OS by http://www.mikrotik.com.cn/. Another site has a post about dns cache poisoning/phishing and one of these IP’s, this time affecting an ISP in Taiwan.

Anyone?

2 comments.

  1. figured out that realy blocking in DNS way most of sites

    216.234.179.13 this ip

    i tried to change default ip server
    to my linux pc it worked then i tried to resolve myhomepc.dyndns.org in europe in nslookup(windows) 216.234.179.13 appeared

  2. […] weeks ago about how he accidentally discovered this criminal practice of the GFW.  Since then, another blogger has also come forward to share his […]

Post a comment.