现象

就是DNS解析的结果是伪造的结果。据说GFW在DNS应答返回前伪造一个应答。因为DNS是无连接的，所以等真的应答返回的时候，客户端也不要了。即使用国外的正常的DNS服务也无法避免被污染

从Google的DNS获取结果都是被污染的了：

$ dig @8.8.8.8 twitter.com

; <<>> DiG 9.7.1-P2 <<>> @8.8.8.8 twitter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34202
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;twitter.com.            IN    A

;; ANSWER SECTION:
twitter.com.        300    IN    A    46.82.174.68

;; Query time: 76 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Apr 18 21:51:50 2011
;; MSG SIZE  rcvd: 45


$ dig @8.8.4.4 twitter.com

; <<>> DiG 9.7.1-P2 <<>> @8.8.4.4 twitter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64519
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;twitter.com.            IN    A

;; ANSWER SECTION:
twitter.com.        300    IN    A    159.106.121.75

;; Query time: 78 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Mon Apr 18 21:52:31 2011
;; MSG SIZE  rcvd: 45

在VPS上获得的正确结果：

$ dig @8.8.8.8 twitter.com

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.6.amzn1 <<>> @8.8.8.8 twitter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33679
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;twitter.com.            IN    A

;; ANSWER SECTION:
twitter.com.        18    IN    A    199.59.148.11
twitter.com.        18    IN    A    199.59.148.10
twitter.com.        18    IN    A    199.59.148.82

;; Query time: 5 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Apr 18 21:54:16 2011
;; MSG SIZE  rcvd: 77

把系统DNS服务器设置为Google的DNS后，在syslog发现如下内容：

Oct  1 10:20:59 dell kernel: [325133.184238] UDP: bad checksum. From 8.8.4.4:53 to 192.168.1.10:37939 ulen 53
Oct  1 10:31:46 dell kernel: [325780.224749] UDP: bad checksum. From 8.8.4.4:53 to 192.168.1.10:44500 ulen 57
Oct  1 11:07:10 dell kernel: [327904.147263] UDP: bad checksum. From 8.8.4.4:53 to 192.168.1.10:47737 ulen 55
Oct  1 18:38:05 dell kernel: [343201.426818] UDP: bad checksum. From 8.8.4.4:53 to 192.168.1.10:54419 ulen 61
Oct  1 18:45:16 dell kernel: [343632.701244] UDP: bad checksum. From 8.8.4.4:53 to 192.168.1.10:44704 ulen 57
Oct  1 21:57:42 dell kernel: [347350.711036] UDP: bad checksum. From 8.8.4.4:53 to 192.168.1.10:43468 ulen 53
Oct  1 22:06:51 dell kernel: [347899.314636] UDP: bad checksum. From 8.8.4.4:53 to 192.168.1.10:38349 ulen 57
Oct  1 22:24:07 dell kernel: [348935.325926] UDP: bad checksum. From 8.8.4.4:53 to 192.168.1.10:47844 ulen 53
Oct  1 22:33:13 dell kernel: [349481.936919] UDP: bad checksum. From 8.8.4.4:53 to 192.168.1.10:53953 ulen 53
Oct  3 10:25:37 dell kernel: [384548.422055] UDP: bad checksum. From 8.8.4.4:53 to 192.168.1.10:46105 ulen 57
Oct  3 11:51:15 dell kernel: [386237.362217] UDP: bad checksum. From 8.8.4.4:53 to 192.168.1.10:54084 ulen 57

这个应该是每次收到GFW污染的DNS解析结果后，内核检查出回复包有问题。

 

被污染网站

  • twitter.com

  • facebook.com

  • youtube.com

  • encrypted.google.com

 

解决办法

用V-B-N加密即可，但是在开启V-B-N之前，系统可能会缓冲污染的DNS解析结果，这样开启V-B-N后仍然得到错误的解析结果。

如果是Windows，有命令来清除DNS缓存，用SSH隧道的话，要设置远程DNS解析。