1
GPU 2016-06-11 10:41:03 +08:00
就不能详细点?
还有就是这个域名没有解析 ip 啊 |
2
lslqtz 2016-06-11 10:53:46 +08:00
666...
Microsoft Windows [版本 10.0.10586] (c) 2015 Microsoft Corporation 。保留所有权利。 C:\Users\lslqtz>dig n.yiz.me ; <<>> DiG 9.10-P2 <<>> n.yiz.me ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20826 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;n.yiz.me. IN A ;; Query time: 3346 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Sat Jun 11 10:56:40 中国标准时间 2016 ;; MSG SIZE rcvd: 37 C:\Users\lslqtz> |
3
phoenixlzx 2016-06-11 10:57:47 +08:00
测试方法是 域名+n.yiz.me
Phoenix-X1-Carbon :: ~ » dig www.google.com.n.yiz.me ; <<>> DiG 9.10.4-P1 <<>> www.google.com.n.yiz.me ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54283 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.google.com.n.yiz.me. IN A ;; ANSWER SECTION: www.google.com.n.yiz.me. 76 IN A 216.58.216.36 ;; Query time: 326 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Jun 11 10:59:47 CST 2016 ;; MSG SIZE rcvd: 68 然而我本地本来就是反污染的方案所以并看不出效果ㄟ( ▔, ▔ )ㄏ |
4
popu111 2016-06-11 10:58:13 +08:00
@GPU
@lslqtz nslookup google.com.n.yiz.me 名称: google.com.n.yiz.me Addresses: 2607:f8b0:4007:80a::200e 216.58.217.206 搜索域是这么用的 |
5
qcloud 2016-06-11 11:01:06 +08:00
说的好像真的似的
|
6
pagxir OP 只需要添加搜索后缀,不需要 IP 。设置了搜索后缀之后,当你浏览器发送查询 www.baidu.com 这个域名的时候,系统会自动将 www.baidu.com 转换为 www.baidu.com.<搜索后缀> 例如 www.baidu.com.n.yiz.me , 对于没有污染的域名,因为并没有修改你的上游 DNS 服务器,所以 CDN 还是可以正常的工作,你访问的还是离你最近的网站,之后第一次没有命中域名缓存会解析慢些。
|
7
Neveroldmilk 2016-06-11 11:22:43 +08:00 1
用这个治标不治本,建议用 dnscrypt 。
|
8
fcicq 2016-06-11 11:27:17 +08:00
yiz.me. 86400 IN NS dns10.hichina.com.
yiz.me. 86400 IN NS dns9.hichina.com. 万网的 DNS 是怎么玩的才搞成这个效果? 只是做了几个障眼法记录吧? |
9
GPU 2016-06-11 11:31:30 +08:00
|
10
pagxir OP @Neveroldmilk 你知道原理就不会这么说了。
@fcicq 直接中转给 8.8.8.8 进行解析,不做任何缓存和配置(只需一份 gfwlist 的域名)。 $ dig -t NS +norecurse n.yiz.me @dns9.hichina.com ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -t NS +norecurse n.yiz.me @dns9.hichina.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60431 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;n.yiz.me. IN NS ;; AUTHORITY SECTION: n.yiz.me. 43200 IN NS ns1.keziwo.com. ;; Query time: 1 msec ;; SERVER: 42.120.221.13#53(42.120.221.13) ;; WHEN: Sat Jun 11 11:38:06 2016 ;; MSG SIZE rcvd: 54 |
12
InFaNg 2016-06-11 11:46:45 +08:00 via Android
这个后缀会不会直接被墙了
|
13
lslqtz 2016-06-11 11:47:15 +08:00
|
14
pagxir OP @fcicq 是可以对域名进行重编码,只是需要另外安装 client 端而已。至于放国内,如果不公开使用,才没人去查你呢。
|
16
lslqtz 2016-06-11 11:52:24 +08:00
这样的倒是挺好的,但是并没看出怎么配置。 dns 也是万网的。。不可能添加一大堆记录进去吧。
|
17
JackBlack2006 2016-06-11 11:53:45 +08:00
@Neveroldmilk 请问你知道 mac 下面怎么改 dnscrypt 端口吗?直接改 plist 无法启动服务呢
|
20
tSQghkfhTtQt9mtd 2016-06-11 12:06:53 +08:00 via Android
@GPU 🌚因为 Google 不止被 DNS 污染(其实好像也没污染),只是把 Google 很多 IP 端封了。。所以解析对了也没用
|
21
UnisandK 2016-06-11 12:07:02 +08:00
好东西,感谢楼主分享
|
22
21grams 2016-06-11 12:19:24 +08:00
cdn 肯定有问题啊
|
23
yeyeye 2016-06-11 12:22:32 +08:00
@GPU
@fcicq 我也是看了 10 楼的方法才知道方法……原来竟然是这样玩的。简单来说,就是在 n.yiz.me 这个域名配置了一个 NS 服务器,所以它和它的子域名都将向那个 NS 服务器发起查询请求,也就实现了这个我们看着莫名其妙的东西。 重点在于 n.yiz.me 配置了单独的 ns 服务器 重点在于 n.yiz.me 的子域名全部靠那个 NS 服务器来解析 重点在于 增加了 n.yiz.me 后缀(在电脑里做好设置后,所有域名查询请求就自动加了 n.yiz.me 后缀),墙的域名匹配规则就匹配不到了 就不存在劫持了 所以可以正常解析了 但是我仍然没搞懂,虽然没改变 DNS 服务器(电脑端),怎么就能查询到最近的服务器了,难道请求不是全部发往 n.yiz.me 来做查询吗?全部由 n.yiz.me 解析?那它怎样知道每个电脑端最近的服务器是哪个呢(因为需要楼主的服务器代为查询吧?)?表示不解。 |
24
RoyLaw 2016-06-11 12:27:12 +08:00
探半个身子到墙外没什么意义啊,直接 SS 出去 DNS 远程解析啊。
|
26
pagxir OP @yeyeye 因为对于无污染的域名,仅返回 cname 而不是递归查询,接收到 cname 之后,运营商的 dns 会自己查询 cname 的 ip 。这是标准的 dns 协议行为,所以能够正确返回 cdn 的地址。
|
30
ovear 2016-06-11 13:09:18 +08:00 1
@pagxir 恩。。。 lz 这个的确是个新思路,我比较好奇 lz 怎么配置的,能分享下么。
n.yiz.me 独立一个 ns 记录, ns 到自己的服务器是么_(:з」∠)_ 然后自己的服务器用的应该是标准的递归 dns ,关于搜索域这块怎么配置呢~ @21grams 这个真不存在, 真的黑科技。 解析过程如下 root@web1 [~]# dig +trace qq.com.n.yiz.me ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> +trace qq.com.n.yiz.me ;; global options: +cmd . 361365 IN NS h.root-servers.net. . 361365 IN NS k.root-servers.net. . 361365 IN NS e.root-servers.net. . 361365 IN NS j.root-servers.net. . 361365 IN NS m.root-servers.net. . 361365 IN NS b.root-servers.net. . 361365 IN NS l.root-servers.net. . 361365 IN NS f.root-servers.net. . 361365 IN NS a.root-servers.net. . 361365 IN NS c.root-servers.net. . 361365 IN NS d.root-servers.net. . 361365 IN NS i.root-servers.net. . 361365 IN NS g.root-servers.net. ;; Received 228 bytes from 114.114.114.114#53(114.114.114.114) in 186 ms me. 172800 IN NS a2.me.afilias-nst.info. me. 172800 IN NS ns.nic.me. me. 172800 IN NS d0.cctld.afilias-nst.org. me. 172800 IN NS b2.me.afilias-nst.org. me. 172800 IN NS a0.cctld.afilias-nst.info. me. 172800 IN NS ns2.nic.me. me. 172800 IN NS b0.cctld.afilias-nst.org. me. 172800 IN NS c0.cctld.afilias-nst.info. ;; Received 503 bytes from 192.5.5.241#53(192.5.5.241) in 112 ms yiz.me. 86400 IN NS dns9.hichina.com. yiz.me. 86400 IN NS dns10.hichina.com. ;; Received 83 bytes from 199.254.62.1#53(199.254.62.1) in 172 ms n.yiz.me. 43200 IN NS ns1.keziwo.com. ;; Received 61 bytes from 140.205.228.13#53(140.205.228.13) in 25 ms qq.com.n.yiz.me. 50 IN CNAME qq.com. qq.com. 50 IN A 125.39.240.113 qq.com.n.yiz.me. 50 IN A 61.135.157.156 ;; Received 121 bytes from 167.160.166.177#53(167.160.166.177) in 217 ms root@web1 [~]# 可以很明显的看到, lz 的 qq.com.n.yiz.me 返回的是一个 cname 值, cname 为真实的域名 qq.com ,根据 dns 协议,如果是 cname 别名,递归 dns 会再次深度递归,直到返回 a 记录,也就是只要保证原本的 cdn 没问题,并且调度正确或者支持 edns , lz 这个也基本不受影响。 对于被劫持的 ip , lz 的做法则是采用直接劫持返回值,解析过程如下 ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> +trace youtube.com.n.yiz.me ;; global options: +cmd . 361218 IN NS h.root-servers.net. . 361218 IN NS k.root-servers.net. . 361218 IN NS e.root-servers.net. . 361218 IN NS j.root-servers.net. . 361218 IN NS m.root-servers.net. . 361218 IN NS b.root-servers.net. . 361218 IN NS l.root-servers.net. . 361218 IN NS f.root-servers.net. . 361218 IN NS a.root-servers.net. . 361218 IN NS c.root-servers.net. . 361218 IN NS d.root-servers.net. . 361218 IN NS i.root-servers.net. . 361218 IN NS g.root-servers.net. ;; Received 228 bytes from 114.114.114.114#53(114.114.114.114) in 169 ms me. 172800 IN NS ns.nic.me. me. 172800 IN NS d0.cctld.afilias-nst.org. me. 172800 IN NS a0.cctld.afilias-nst.info. me. 172800 IN NS a2.me.afilias-nst.info. me. 172800 IN NS b0.cctld.afilias-nst.org. me. 172800 IN NS b2.me.afilias-nst.org. me. 172800 IN NS c0.cctld.afilias-nst.info. me. 172800 IN NS ns2.nic.me. ;; Received 496 bytes from 192.228.79.201#53(192.228.79.201) in 399 ms yiz.me. 86400 IN NS dns9.hichina.com. yiz.me. 86400 IN NS dns10.hichina.com. ;; Received 88 bytes from 89.188.44.88#53(89.188.44.88) in 365 ms n.yiz.me. 43200 IN NS ns1.keziwo.com. ;; Received 66 bytes from 42.120.221.13#53(42.120.221.13) in 36 ms youtube.com.n.yiz.me. 299 IN A 216.58.216.46 ;; Received 74 bytes from 167.160.166.177#53(167.160.166.177) in 226 ms 也就是直接劫持到正确的 ip 上,在这个情况下是会影响 cdn 的调度的。 |
31
pagxir OP @yeyeye 是有冲突的,两者都配置会导致 DNS 解析出现不可预期的行为, CNAME 会覆盖 MX 记录,得到的是 CNAME 的 MX 记录,而原来的 MX 记录像没有配置过一样。
https://www.cloudxns.net/Support/detail/id/6.html |
32
yeyeye 2016-06-11 13:15:21 +08:00
@21grams 他解释之后我就明白了,简单说就是所有域名查询都加上了一个域名后缀,相当于全部发到他的服务器去解析了,如果被墙域名(他做个列表检测一下),就转发域名(去掉后缀)请求到 8.8.8.8 ,返回的记录又转发给用户,实现解析被墙域名。
那么不被墙的域名又要如何解析呢?它不转发,直接返回一个 cname 记录,记录所指的就是你请求的域名本身(没有后缀),然后你的 DNS 服务器会去查询这个 cname 记录的值,然后返回给客户端。 dig www.v2ex.com.n.yiz.me n.yiz.me NS 服务器返回 www.v2ex.com.n.yiz.me. 1308 IN CNAME www.v2ex.com. v2ex.com NS 服务器返回 www.v2ex.com. 642 IN CNAME v2ex.global.zgslb.net. zgslb.net NS 服务器返回 v2ex.global.zgslb.net. 1799 IN CNAME v2ex.edge.zgslb.net. zgslb.net NS 服务器再返回 v2ex.edge.zgslb.net. 9 IN A 23.251.124.132 v2ex.edge.zgslb.net. 9 IN A 23.251.96.131 v2ex.edge.zgslb.net. 9 IN A 23.251.124.131 v2ex.edge.zgslb.net. 9 IN A 23.251.126.133 v2ex.edge.zgslb.net. 9 IN A 23.251.100.132 解析完毕 从 www.v2ex.com 开始 都是交给回给你本地的 DNS 服务器去代为查询了,使用的域名记录也是该域名本身,所以 CDN 不会出问题啊 并不是 n.yiz.me 的服务器在代为查询,最后返回 IP 给程序,搞定。 唯一我觉得有异常的地方就是说了很多年的 cname 和 mx 记录有冲突,所以可能导致点毛病,不知道它这个会不会有影响 |
33
kn007 2016-06-11 13:16:22 +08:00
神奇。。
|
34
pagxir OP @ovear 曾经写的一个 C++小程序,之前公布过,不过那时不是很稳定,也没什么人关注。这两天,刚好有空,发现有这么有趣的玩法,所以修改了实现方式增加对 CDN 的支持。
|
35
ovear 2016-06-11 13:18:33 +08:00
@pagxir 哈哈 原来是自己写的,不是标准递归 dns 呀。膜拜_(:з」∠)_,我之前也写了个,然后还有很多问题,也没公布。
总之谢谢 lz 显啦~ |
36
yeyeye 2016-06-11 13:21:12 +08:00
@pagxir
nslookup -q=mx v2ex.com.n.yiz.me 没有返回 mx 记录 nslookup -q=mx v2ex.com 返回了 mx 记录 这就是传说中的坑。没猜错的话, cname 只会转发 a 记录,其他记录不管。 |
37
yeyeye 2016-06-11 13:23:59 +08:00
@21grams 这种东西没公布的时候是黑科技,但是一公布了,会这方面编程的都能随手写一个程序来做,简直是……我咋就刚好不会呢……
|
38
yeyeye 2016-06-11 13:27:18 +08:00
36 楼 补充
应该是只返回 a 记录和 aaaa 记录 |
39
21grams 2016-06-11 13:35:25 +08:00
@yeyeye 我不是说他整个这个是黑科技,这个东西 N 年前就有人做了,原理一望便知。 我唯一疑惑的是按我的理解这肯定有 cdn 问题,但如果按上面说的,其实只是返回一个 CNAME 的话,倒也解释的通了。
|
40
21grams 2016-06-11 13:37:39 +08:00
|
42
Jasmine2016 2016-06-11 13:41:22 +08:00 via iPhone 1
是不是和 YouTube.com.hcs.world 这个网址一样的思路
|
44
qq651438555 2016-06-11 13:54:25 +08:00
看来是好用啊
|
45
bclerdx 2016-06-11 14:04:23 +08:00
这个似乎是利用了 Windows 域网络来实现的。
|
46
Lentin 2016-06-11 14:07:24 +08:00
linux 怎么用呢,刚好再想怎么不牺牲 CDN 又能解析正确 DNS
|
47
yeyeye 2016-06-11 14:10:01 +08:00
@popu111 这就是这样 提建议 没人理 提意见 没人理 提好想法 没人理 提出某些设计很不合理 没人理
关键是如果你替管理组解答问题,他们又可能跳出来说你不要替我们强行解释(比如跳出来说“我没说过这样的话”) 唯一做得比较好的就是举报垃圾贴的时候 基本上都会处理 |
49
congeec 2016-06-11 14:25:01 +08:00
Mac OS X 用户一行搞定 search domains :
sudo networksetup -setsearchdomains Wi-Fi n.yiz.me |
50
ksmter 2016-06-11 14:37:26 +08:00
我现在在用 pcap dns proxy,虽然效果不错,但配置起来好麻烦。这种方法还是第一次接触到,先好奇一番,有空试试
|
51
coffeecat 2016-06-11 14:42:36 +08:00
学习了。。。。
|
52
kofip 2016-06-11 14:55:51 +08:00
涨见识了。
|
53
Lentin 2016-06-11 14:55:55 +08:00 via Android
效率感觉并不高啊,楼主有配置缓存吗?
|
54
hanqian 2016-06-11 15:12:51 +08:00
懂了,楼主实在机智。
|
55
hljjhb 2016-06-11 15:25:14 +08:00
实用性一般,但思路不错
|
56
aprikyblue 2016-06-11 16:11:02 +08:00
@yeyeye
cname 将域名解析权交给记录的域名 domain1 ---cname---> domain2 domain1 的所有记录都会变成 domain2 的,包括 a , mx , txt 等等 所以,如果配置了 cname ,查询 domain1 的 mx 记录相当于变成了查询 domain2 的 mx 记录 如果此时 domain2 无 mx 记录,就出现了你的查询 domain1 无 mx 记录 |
57
googlebot 2016-06-11 16:36:12 +08:00 via Android 1
lz 也许无意,但劝别人改 dns 很不道德,
dns 是很重要的,别人可以窃听你数据, |
58
ivmm 2016-06-11 16:41:17 +08:00
求教怎么搭建
|
60
KingsWay 2016-06-11 18:45:45 +08:00
@Lentin Linux 下面为什么你会选择用 \r\n 。。。。 OS X 是 \r , Win 是 \r\n , Linux 的风格是 \n 。。。
还有,单单一行 search 指令,好像连基本的 dns 服务器都没了吧,我实验了下,确实什么都解析不了了。 Ps: 虽然我加了 nameserver ,但是 search 指令好像并没有生效。。。疑惑中 |
62
kmahyyg 2016-06-11 19:13:01 +08:00 via Android
android 下如何配置?
|
63
Lentin 2016-06-11 19:59:46 +08:00 via Android
|
65
googlefans 2016-06-11 21:05:04 +08:00 1
安全性如何保证?
|
66
just4test 2016-06-11 21:14:01 +08:00 via Android
https 不会挂掉吗?
|
67
gpw1987 2016-06-11 21:35:06 +08:00
这个的确是长见识了。一起都不太懂这东西
|
69
Oi0Ydz26h9NkGCIz 2016-06-11 21:53:50 +08:00
的确是很好的思路!
|
70
chiu 2016-06-11 23:54:04 +08:00
|
71
yeyeye 2016-06-12 00:01:39 +08:00
@chiu 因为在墙看来 你查询的是 google.com.n.yiz.me 而不是 google.com 自然就会放过了(被墙的域名会通过他的服务器转发,不是被墙的则返回墙内服务器交给你电脑设置的服务器自行查询去)
|
72
Oi0Ydz26h9NkGCIz 2016-06-12 00:13:44 +08:00
|
74
zhoujianqingz 2016-06-12 09:24:30 +08:00
很谢谢你,但是看了半天也没懂 windows 和 mac 下怎么用,请问能详细一点教教我吗
|
75
wujunze 2016-06-12 10:09:07 +08:00
这个玩意儿 是怎么整的?
|
78
samuelts 2016-06-13 19:05:45 +08:00
![dns 设置]( )
这样设置之后似乎不能工作,不知道是不是我这样的设置有问题?只有查询类似 abcde 这样的无效域名的时候会加上 n.yiz.me 后缀,正常的域名比如`gist.github.com`似乎不会加上后缀。 |
84
pagxir OP 不需要勾选 在 DNS 中注册此连接地址,就按照你最后一个图设置即可。然后用 nslookup www.youtube.com 试试。
|
86
samuelts 2016-06-14 10:16:52 +08:00
|
87
laincat 2016-06-14 17:52:22 +08:00
这是啥神奇的东西。。。。
|
88
dili 2016-06-16 10:47:58 +08:00
感觉好复杂,以为不知道是不是能解决 DNS 污染问题,也不知道会不会因为加了改变了后缀解析结果,就测了一下 google.com.n.yiz.me 和 qq.com.n.yiz.me 的解析效果,结果真的是忽略了 n.yiz.me ,返回真实域名的解析结果
1.google.com.n.yiz.me 解析结果 http://www.wangsutong.com/wstCeba/dns/dns-test!result.action?id=9511243565e34174928b85db3144d69d 2.qq.com.n.yiz.me 解析 结果 http://www.wangsutong.com/wstCeba/dns/dns-test!result.action?id=2983c70a7c4144c5b1481682ee3ef80f |
90
pagxir OP 如果不行,只能跑个 client 端:
https://github.com/pagxir/libtx/releases |
91
2001225354 2016-06-17 23:55:34 +08:00
黑科技,特来感谢
|
92
Ephzent 2016-07-13 17:41:44 +08:00
黑科技,但是我这样设置并不行 0.0 |
94
QK8wAUi0yXBY1pT7 2016-07-25 11:49:31 +08:00
同求搭建教程
|
95
forgetandnew 2016-08-05 23:17:57 +08:00
好像已经挂了
|
96
pagxir OP @forgetandnew 需要自己编译 client ,后缀改为 p.yiz.me
可以编译 openwrt 版本放倒板子上跑: https://github.com/pagxir/libtx/tree/txrelay |
97
leafleave 2016-12-05 08:32:43 +08:00 via Android
|