墙的 DNS 污染系统升级了？

[aa65535]

将 https://github.com/clowwindy/ChinaDNS-C/blob/master/tests/iplist.py 用 shell 改写了一下：

#!/bin/sh

( for i in `seq 400 1400`; do
    dig +short @8.8.114.114 a r$i-1.googlevideo.com
done ) | sort -u

之前 fake IP 也就 49 个，而且长期固定不变，在 /t/156926 已经有出现新的 fake IP ，今天用脚本试了一下，目前获取到的 fake IP 已经 375 个了，估计还会增加，莫非墙已经学会随机生成 fake IP 了？

[Missex]

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

[cokebar]

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

[mazk]

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

[infinte]

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

[fclql]

@infinte @mazk @msxcms 生活如此多娇

[Missex]

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

[infinte]

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

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

[Missex]

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

[infinte]

@Missex 我去实验下

[9999999999999999]

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

[Missex]

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

[kqz901002]

➜ ~ 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

[Septembers]

只从 root查询 或许可以

[infinte]

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

[aa65535]

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

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

[infinte]

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

[infinte]

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

[Dreista]

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

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

[infinte]

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

[infinte]

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