墙的 DNS 污染系统升级了？

Fake

+short

seq

84 条回复 • 2015-05-26 00:24:50 +08:00

1

ma0dan

2014-12-31 22:12:43 +08:00

有这种预感，维基百科上说大概查询google+的返回google的ip,我顿时凌乱了。已经改用了ss-tunnel方案。

2

commoccoom

2014-12-31 22:31:28 +08:00

root@OpenWrt:~# nslookup www.youtube.com
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost

Name: www.youtube.com
Address 1: 2404:6800:4005:807::1007
Address 2: 5.10.68.254 asphostserver.eu
root@OpenWrt:~#

打开 youtube 直接提示证书错误。

3

commoccoom

2014-12-31 22:33:59 +08:00

为什么把 5.10.68.254 这个 ip 加入 chinadns_iplist.txt 还是不能过滤掉呢？

4

aa65535

OP

2014-12-31 22:37:02 +08:00

@commoccoom 刷新一下 DNS 缓存。

5

LazyZhu

2014-12-31 22:44:08 +08:00

貌似是改成随机的了, 而且ip大都是有网站的
很多网站天降超级DDos哦, 明天看新闻吧...

6

commoccoom

2014-12-31 22:44:54 +08:00

@aa65535

openwrt 要怎么刷新dns缓存啊，我重启了路由器，但是还是不行。

7

xiao201261

2014-12-31 22:45:52 +08:00

求独立ip～

8

Draplater

2014-12-31 22:49:39 +08:00 via Android

已经开始筹备白名单DNS代理了

9

aa65535

OP

2014-12-31 22:51:23 +08:00

@LazyZhu 的确有不少 IP 是有网站的(比如#2 的 5.10.68.254)。
114.114.114.114 比 8.8.114.114 可以获取更多的 fake IP.

10

Dreista

2014-12-31 22:53:26 +08:00

在学校的DNS服务器用了BIND+ChinaDNS-C，前几天在V2上看到新的fake IP想也没想就加进去了。结果还是返回了一些奇怪的IP。
回V2一看，果然。数量短时间内上升到375个的话估计是开始随机生成了。但是在学校里用tunnel的话有时候会存在不稳定因素。纠结中。

11

GhostFlying

2014-12-31 22:54:02 +08:00

来自墙的新年礼物么。。我也试下

12

LazyZhu

2014-12-31 23:07:41 +08:00

GFW也是有条不紊的在实施白名单啊,ip先随机劣化以减少访问量,然后完全屏蔽,dns污染也是.
猜测最终白名单的形态应该是GFW自己建一个超级服务器,以缓存符合"伟光正"的国外网站内容,就像搜索引擎一样.

14

treo

2014-12-31 23:18:20 +08:00

如果gfw真的开始随机生成fake IP，可以换个思路嘛，整理一个top500或top1000的墙内网站域名列表，只有在列表里的域名才通过墙内dns解析，其他全都默认走ss/vpn通过墙外dns解析。毕竟一般只有大型网站才会部署Location aware DNS+CDN。
唯一的影响是第一次解析的时候会慢100~300ms。

15

zent00

2014-12-31 23:19:59 +08:00 via Android

这次升级的效果很明显，直接把 ChinaDNS 给废掉了。不过也如楼上所说，GFW 要做的远不止这么简单，他们应该在筹划着更大的一盘棋。

16

Dreista

2014-12-31 23:24:31 +08:00

就像温水煮青蛙。身边那些基本只使用国内服务的人对此几乎不知情，长期翻墙的久而久之也可能会没有感觉了。实在乐观不起来。
不能推墙也得尽全力肉身翻墙。可惜个人能力实在有限。

17

leopard080264

2014-12-31 23:27:10 +08:00

已把ipv4 dns关闭，改成127.0.0.1 只启用ipv6 dns

18

KyonLi

2014-12-31 23:54:28 +08:00 via Android

1

看来有必要整理一份国内域名列表了，其余全转发

19

datou

2014-12-31 23:56:13 +08:00

ipv6 dns似乎不存在污染的烦恼

我目前用的这个2001:470:20::2

20

msxcms

2014-12-31 23:56:36 +08:00

早就想到会搞随机，没想到这么快

21

Missex

2015-01-01 00:06:27 +08:00

一堆有网站的IP，这帮人越来越不地道了

22

cokebar

2015-01-01 00:16:45 +08:00

这个之前在IPv6已经有了，大概半年前我试验过，AAAA地址会出现各种奇葩的比如说1:2:3::4这种，不过IPv6的污染情况一直变化，现在貌似又没之前那么严重了。
其实只要IP返回随机值+多次抢答就可以很好的干扰ChinaDNS的正确解析
彻底解决还是需要避开53端口或者使用ss-tunnel

23

mazk

2015-01-01 00:25:16 +08:00 via iPhone

不知道chinadns作者对此有什么看法呢…想必很多人都在用这套方案…想想已经放弃的了goagent作者，不禁感慨…希望坚持下去

24

infinte

2015-01-01 00:38:18 +08:00

我相当怀疑 tg 是不是有人在天天刷 v2ex 然后想针对性的方法……使用随机 IP 代替固定的 IP 明显是针对 chinadns 去的，很像是既有系统调整了一个小部分。

26

Missex

2015-01-01 01:04:55 +08:00

重复几率很大，不像完全随机，也可能有缓存。随机试了几个ip都能打开，各式各样的网站，这岂不是相当于开启攻击漠视了

27

infinte

2015-01-01 01:11:40 +08:00

@Missex 是随机的，通过查询「不存在的 DNS」可以观察到。
而且只有以前有污染的域名上有此行为，其他域名正常。推测是原来的系统小改下的结果。
当然对 chinadns 是大杀器。

啊 TG 终于进化到 counter-force 策略了，可喜可贺，可喜可贺。

28

Missex

2015-01-01 01:16:18 +08:00

@infinte 随机的数量会很大。现在这个不断重复获取污染ip保存起来去重排序，数量就逐渐不增加了。

29

infinte

2015-01-01 01:25:11 +08:00

@Missex 我去实验下

30

9999999999999999

2015-01-01 01:30:35 +08:00

我表示沉默，我表示我只上ｖ２ｅｘ

31

Missex

2015-01-01 01:31:02 +08:00

@infinte 刚才数量稳定了一会，现在又开始猛增了，到三百多了。

32

kqz901002

2015-01-01 01:37:35 +08:00

➜ ~ dig www.googlevideo.com @218.4.4.4

; <<>> DiG 9.10.1-P1 <<>> www.googlevideo.com @218.4.4.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12065
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.googlevideo.com. IN A

;; ANSWER SECTION:
www.googlevideo.com. 3600 IN CNAME www.google.com.
www.google.com. 192 IN A 173.194.127.242
www.google.com. 192 IN A 173.194.127.244
www.google.com. 192 IN A 173.194.127.241
www.google.com. 192 IN A 173.194.127.243
www.google.com. 192 IN A 173.194.127.240

;; AUTHORITY SECTION:
google.com. 84991 IN NS ns4.google.com.
google.com. 84991 IN NS ns2.google.com.
google.com. 84991 IN NS ns3.google.com.
google.com. 84991 IN NS ns1.google.com.

;; ADDITIONAL SECTION:
ns1.google.com. 85320 IN A 216.239.32.10
ns2.google.com. 85315 IN A 216.239.34.10
ns3.google.com. 87724 IN A 216.239.36.10
ns4.google.com. 87415 IN A 216.239.38.10

;; Query time: 77 msec
;; SERVER: 218.4.4.4#53(218.4.4.4)
;; WHEN: Thu Jan 01 01:36:44 CST 2015
;; MSG SIZE rcvd: 278

33

Septembers

2015-01-01 01:43:16 +08:00

只从 root查询或许可以

34

infinte

2015-01-01 01:48:01 +08:00

@Missex 好玩了，我这边测试，收敛到了 100 个 ip。不多不少，刚好 100 个。

35

aa65535

OP

2015-01-01 01:53:58 +08:00

@mazk 如果使用 ChinaDNS 方案的话可以设置一个 cron ，使用上面的脚本每隔两小时更新一次 iplist，然后重启服务。

@Missex 目前 fake IP 的 TTL 设置的比较长，初步估算是在 3600s 左右，估计是想依靠这个来减轻压力，在一段时间内应该都不会有变化。

36

infinte

2015-01-01 01:59:29 +08:00

而且有意思的是：不同使用另一组有污染的域名测试结果居然是相同的……尼玛还真只是扩大列表啊……
那群人也太懒了吧，一点做高「质量」产品的精神都没有。

37

infinte

2015-01-01 02:03:57 +08:00

唉，不对，2:01 测试的结果和 1:53、1:56 的不同。
难道说每小时变一次？

38

Dreista

2015-01-01 02:36:35 +08:00

@infinte 好像也有这样的情况。

@aa65535 对这方面不是很了解，不知道这样理解是否正确：现在如果每小时更新一遍iplist，可以较为有效地减小出现fake ip的几率；一旦TTL也开始随机的话，这样的方式就会基本失效。因为新的 fake ip 出现的时间点随机。

39

infinte

2015-01-01 02:38:59 +08:00

@Dreista 现在探出来的结果貌似是 30 分钟一更新，而且很可能是从一份更大的列表中抽取 100 个用作实际污染。
我需要更长时间的探测。

40

infinte

2015-01-01 03:09:18 +08:00

1

@Dreista 刚才跑出了一个更加有趣的情况：3:00 之后的那 100 个 fake ip 和之前的有 3 个重叠，那么可以估算现在的 fake ip 是从一个大约 3300 规模的 ip 池中每 30 分钟随机选出 100 个部署到污染系统中？
我需要更多的测试。

41

clowwindy

2015-01-01 03:24:23 +08:00

2

C 版 1.2.0 加了个过滤策略，没有 IP 列表也能过滤了，现在跑着看上去好像没什么问题
https://github.com/clowwindy/ChinaDNS-C/releases/tag/1.2.0

对 GFW 的实现虽然有很多想吐槽的地方……不过干嘛给他们提建议呢？让他们继续慢慢摸索吧

Python 版暂时懒得更新了，谁有兴趣发 Pull Request 吧

42

infinte

2015-01-01 03:37:51 +08:00

三个台阶分别是 100、197 和 285

43

v201411

2015-01-01 06:19:11 +08:00

不可否认，GFW虽然是把大家关起来了，但同时也培养了很多民间高手。

44

xuzizzz

2015-01-01 06:20:58 +08:00 via Android

确实有fake ip

45

Dreista

2015-01-01 06:42:58 +08:00 via Android

@infinte ip池的规模如果只根据这一次的数据来估算的话感觉还是会有较大的偏差。不过想要取得更准确的数据需要的时间就长了
(呃，太困睡着了这条这个点才发出来…按后来的图看实际数目可能比3300小，但是不直接随机生成而是费了这么大功夫，动机是啥…想不通。减少误伤几率？)

46

infinte

2015-01-01 07:21:23 +08:00

1

@Dreista 不知道，也许只是想增加 fake ip 的数量，并且同时增加人们获取整个列表的难度（现在获取整个列表的时间可能需要好几天）。
夜里跑了两个小时，五个台阶是 100、197、285、373、457。
目前观察到「一级池」（100）和「二级池」（~3000），是否有更高级的池尚不得知。
我待会跑个时间很长的，看看结果会是怎样。

47

xiaozhizhu1997

2015-01-01 08:14:12 +08:00 via Android

@clowwindy 原理是？将GFW返回的包含错误IP的包推迟？

48

a2z

2015-01-01 10:20:54 +08:00

1

明显是你们太懒了……搞什么伪造IP黑名单，这样主动权完全在gfw手里……做个安全的DNS转发器才是正确的做法

49

jasontse

2015-01-01 12:14:19 +08:00 via iPad

看样子像是隔一段时间生成一个新 IP 池

50

clowwindy

2015-01-01 12:24:12 +08:00

@xiaozhizhu1997

类似，等待一小段时间然后挑一个看起来最靠谱的结果

总之已经不需要 fake IP 列表了

51

Missex

2015-01-01 12:36:43 +08:00

@clowwindy 都是国外ip吧，有国内ip么

52

xiaozhizhu1997

2015-01-01 14:59:21 +08:00 via Android

已经把自建的DNS由转发208.67.222.222:53改成5353了，完全规避了污染。
中国用户访问OpenDNS是日本的208.67.222.222。
不过，支持非标端口的DNS就那几个…
也许有一天我们需要在国内外都有VPS，二次转发。

53

msxcms

2015-01-01 18:22:56 +08:00

1

还有一种思路，本地DNS服务自行去遍历所有上游NS服务，获得到域名NS后判断NS的IP，如果是国内IP用国内DNS解析，国外IP用国外防污染DNS解析

54

cty

2015-01-01 20:25:20 +08:00

@datou

你发现了！如果 IPV6 还有 DNS 污染，大学生就该闹事了。

55

kqz901002

2015-01-01 20:27:08 +08:00

@xiaozhizhu1997 中国移动访问的208.67.222.222 是香港节点只有40ms 延迟，电信貌似从美国又到日本的好像 300ms延迟

56

kqz901002

2015-01-01 20:27:45 +08:00

@cty 你想多了，完全闹不起来的好么

57

myi918

2015-01-01 20:42:08 +08:00

用你的最新版的 chinadns 打不开 youtube。打开的是个奇怪的网站~~iplist问题？用@clowwindy 重装是可以的~~~用的是ramips版本，你的版本能出LUCI~~但是clowwindy 界面上是木有的纠结

58

myi918

2015-01-01 20:47:37 +08:00

请问你的 chinadns-c 是修改版么？

59

aa65535

OP

2015-01-01 21:05:50 +08:00

@myi918 我提供的是带有 UCI 的，也就是可以使用 LuCI 进行配置，其他没有改动。

60

ekucn

2015-01-01 21:38:44 +08:00

@aa65535 @myi918 我跟你情况一样，新版的也打不开，打开youtube是个别的网站，

61

xiaozhizhu1997

2015-01-01 22:10:16 +08:00

@kqz901002 我多线VPS自建的DNS访问的是日本的208.67.222.222，70ms
自家电信也是日本的208.67.222.222，因为NTT线路和电信互连质量糟糕所以150ms。

62

xiaozhizhu1997

2015-01-01 22:10:42 +08:00

@cty 如果没有，哪来的IPv6-hosts。
IPv6只是能有效避免RST。

63

Missex

2015-01-01 22:42:54 +08:00

@Missex 也有一些国内IP，看来是一通乱搞啊

64

infinte

2015-01-01 23:19:33 +08:00

@Missex 做了一个 8h 的测试，大概是在 2500 个 ip 中每 30m 挑选 100 个作为一级池。

65

Missex

2015-01-01 23:25:17 +08:00

@infinte 还继续增加么

66

clowwindy

2015-01-01 23:52:15 +08:00

@myi918
@ekucn

https://www.v2ex.com/t/158525

67

infinte

2015-01-01 23:57:50 +08:00

@Missex 之后台阶越来越「矮」，用数学方法可以算出总数在 2500 个，而且应该不会有更长期的变化。

68

BlackF

2015-01-03 04:49:34 +08:00

GFW这次升级之后webproxy都用不了了。

69

reguser12005

2015-01-04 09:14:58 +08:00

@aa65535, 能不能麻烦把ss-local也放到spec 包里面, 有时候想用的可以用用, 谢谢啊

70

reguser12005

2015-01-04 14:00:29 +08:00

@aa65535 升级你的ss到1.6.2-2, ar71xx, 不会自动启动了. 每次重启路由必须手工去start.

71

reguser12005

2015-01-04 15:14:30 +08:00

1

@aa65535 你的ss 1.6.2-2 报告一个bug, 在703n上有无法随系统启动的情况. 经查是没有/var/etc目录所致, 所以我参考dnsmasq在rules函数下添加了一句.mkdir -p $(dirname $CONFIG_FILE)

rules() {
config_load shadowsocks
config_foreach get_args shadowsocks
mkdir -p $(dirname $CONFIG_FILE)

72

aa65535

OP

2015-01-04 16:08:04 +08:00

@reguser12005 谢谢反馈！
因为方案本身用不到 ss-local ，所以暂时没有打算添加，如果需要这个的用户多的话可以考虑添加。

73

logtee

2015-01-07 12:09:39 +08:00

我脚本跑了一天左右,现在已经有3413个IP了

74

ptsa

2015-01-08 11:46:58 +08:00

@aa65535 chinadns 能不能白名单 v2 访问很有问题还有就是今天更新了你的 shadowsocks-libev-spec_1.6.4-1_ar71xx.ipk 无法启动

75

aa65535

OP

2015-01-08 12:36:26 +08:00

@ptsa 不要启用「双向过滤」，v2 的解析设置是国内外IP混用的。
shadowsocks-libev-spec 无法启动的报错以及你的设置是什么？

76

ptsa

2015-01-08 17:29:09 +08:00

@aa65535 我就和 161 是一样的设置报错不知道在哪里看.....
双向过滤是加速解析吗? 没办法只对 v2 做特赦

77

aa65535

OP

2015-01-08 20:39:45 +08:00

@ptsa 直接在终端执行 /etc/init.d/shadowsocks start 查看是否有报错
「双向过滤」是同时过滤从国外DNS返回的IP为国内的结果，不是加速解析
「特赦」的话，可以 dig 一下 v2 的域名，将其中的几个国外 IP 段加到 /etc/chinadns_chnroute.txt 中

78

Septembers

2015-01-09 01:57:43 +08:00

@LazyZhu 已经有报告表明确实存在随机DNS解析已经构成DDoS了
https://plus.google.com/u/0/104603245338932141930/posts/ggyZDbonh8S

79

ptsa

2015-01-09 11:51:48 +08:00

@aa65535 找到问题所在了, 是用配置文件可以启动,luci配置的无法启动,更新了 1.3.0的luci 问题依旧

80

aa65535

OP

2015-01-09 12:23:10 +08:00

@ptsa 应该是密码里有「#」这个符号吧。目前是不支持这种密码的。

81

ptsa

2015-01-09 20:23:32 +08:00

@aa65535 额真有... 之前的版本都可以,,,奇怪....

82

ptsa

2015-01-10 11:21:13 +08:00

@aa65535 遇到个问题, 路由器没去动的情况下.ss 状态变成未运行, 手动运行一下,就好了, 在哪里看出错信息?

83

gqfBzoLVY3Wl4Tng

2015-01-28 10:02:03 +08:00

chinadns是坑，打开了好多国内网站都挂了，不能解析，

84

lilydjwg

2015-05-26 00:24:50 +08:00

我最近的统计中，只发现了 111 个（很可能是污染的）IP，其中大部分只出现过一次，出现最多的是 78.16.49.15（172），其次是 37.61.54.158（29）。