站内公告:

亲友传真---海外信息直接看 https://qycz.org

Main Menu

回覆帖子

发送站内短信时发生以下错误：
警告: 该贴已经至少 180 天没有更改。
除非你一定要回复，否则也许考虑发一个新贴会更好。
Note: this post will not display until it has been approved by a moderator.
Attachments: (Clear attachments)
限制: 每篇帖子 3 (3 remaining), maximum total size 8.00 MB, maximum individual size 2.00 MB
请将要删除的附件取消勾选
Click or drag files here to attach them.
(Clear attachments)
进阶选项(包含帖子状态和附件)...
验证码:
请将此框留空:
三乘七等于几？（请用阿拉伯数字回答）:
Shortcuts: ALT+S post or ALT+P preview

帖子总览

作者 temp
 - 一月 25, 2012, 04:14:39 上午
引用自: nxzgs 于 一月 23, 2012, 12:55:17 下午
通过nslookup -vc的方式，gfw肯定是有能力检测的，马上可以做个试验：

运行 nslookup -vc www.facebook.com 8.8.8.8
可以正常得到正确的IP

但运行 nslookup -vc www.kanzhongguo.com 8.8.8.8
tcp连接马上会reset，一分钟之内无法再正常连接8.8.8.8

这说明，gfw检测到某敏感域名，可以直接rest连接。

真是神奇，
的確把看中國的域名處理掉了，
為什麼其他的不做這種處理呢？

這種東西我之前從未見過，
也不敢亂說話，
只說說發現。
發完請求後，
連續收到三個RST，
基本上還是能夠獲取正確結果
（但偶然出現連正確都看不到的情形）。
後續查詢的話，
在握手的時候已經被猛轟RST了。

所以，之前說
"
至於90秒繼發RST，
同樣的道理，
牆遲到的RST包根本就沒效果。
"
這裡是我的錯誤。
因為之前做了過濾，
只保留了直接與DNS相關的包，
但握手的TCP包卻被我過濾了
（低級錯誤啊慘），
所以做了錯誤的結論。
本來說不再回复，
但既然說錯了，
也一定要把錯的地方指出來，
否則誤導就不好了。

最後感謝樓上這位仁兄指出這個受到"特級待遇"的域名。。
作者 nxzgs
 - 一月 23, 2012, 12:55:17 下午
通过nslookup -vc的方式，gfw肯定是有能力检测的，马上可以做个试验：

运行 nslookup -vc www.facebook.com 8.8.8.8
可以正常得到正确的IP

但运行 nslookup -vc www.kanzhongguo.com 8.8.8.8
tcp连接马上会reset，一分钟之内无法再正常连接8.8.8.8

这说明，gfw检测到某敏感域名，可以直接rest连接。
作者 temp
 - 一月 23, 2012, 09:53:20 上午
引用自: 路人一 于 一月 23, 2012, 07:28:12 上午
  哈，楼上受累了，抱歉
  略过前面一大段（看了晕。。。），直接跳到你的总结附近，我发现其实我们在某些地方看法是一致的。
我们都认为GFW应该有能力拦截用TCP协议来解析域名的，我说可能是GFW对这块暂时不设防，你也说"當前未有支持TCP做DNS查詢的瀏覽器，牆沒必要浪費這種資源去檢測"，所以最后的结果就是，我们可以使用TCP协议来正确解析域名；

但是，对于这个"结果"的后续判断就有差异了，我认为，既然GFW现在不设防，那就用这个功能，什么问题都不会有，哪天GFW把这个"漏洞"也堵上了，那就用不了，仅此而已。

你一方面认为"你說不危險，是對的"，而另一方面又认为"牆是個複雜的系統，不是說結果沒問題就萬事大吉"，言外之意就是说，虽然现在可以使用TCP协议解析域名，但是还是会被检查域名解析的内容，还是有危险？
那你的结论到底是危险还是不危险？可以安全使用TCP协议解析域名还是觉得这么做不安全所以不该这么做？

再看一个矛盾的表述：针对目前可以使用tcp协议解析域名，你认为"牆沒必要浪費這種資源去檢測"，也就说，你也认为GFW目前没有检测TCP协议域名解析的相关内容，你后续又说"更加不代表它沒有檢查過內容"，那你到底是说GFW检查没检查过？

退一步，如果说墙有能力检测内容、并且有检测内容，那么墙就没有理由不拦截；如果墙出于资源考虑不拦截TCP协议的域名解析，那么它检测内容又有何意义？
借用一下你提到的google的https搜索， 墙暂时对它没招是因为无法得知经过加密的搜索内容，除非墙完全封了google全部ip
顺便说一下，默认使用tcp还是udp协议做域名解析是由系统决定的，不是浏览器或者其他上网程序决定的，具体的，是由system32下的一个dll文件决定的，一高人修改了这个dll，可以让系统默认就使用TCP协议来解析域名，详情自行google

一点感想，其实讨论讨论蛮好的，越讨论，观点就越清晰，还可以锻炼锻炼脑细胞。在自由门板块讨论这个似乎有点离题，都已经讨论这么多了，希望管理员高抬贵手，让我回帖，谢谢！
最后，祝大家新年幸福安康！

一、
"不危險"是客觀事實，
就算你撞牆也沒國安抓你。
對牆的研究一直是黑箱，
"不處理"不等於"不讀取"
（這裡避用"不檢測"，
免得斷章取義），
所以我說"不是說結果沒問題就萬事大吉"。
牆具有查看TCP傳輸內容的能力。
牆不針對你，
但不代表牆不針對敏感人士。

二、
難道牆不讀取包的內容，
就能知道這是DNS的報文？
沒必要去檢測是因為它暫時沒措施，
也因為實際環境導致沒有必要去處理。

三、
你這樣說我就真的要批你了。
你略過歸略過，
上面已經解釋得很清楚的問題你還是拿出來說。
牆本身就不是阻塞型的，
扔RST也僅對keep-alive有效（這句可能不太嚴謹），
<del>像域名查詢那種，
它扔RST也無效。</del>*

四、
系統DLL是有域名解析的API，
gethostbyname什麼的改掉後是可以走TCP，
問題是你改了DLL還得瀏覽器去用。
像chrome就是自己寫的解析，
你搞系統DLL是沒意義的，
它根本就不使用系統API去做解析。
不要提老掉牙的IE6，
那東西早該退休了。

對前兩點的總結，
牆對於TCP的域名查詢，
必然有讀取，不一定有檢測，對於非敏感人士沒採取干擾措施。
不要把"讀取"和"檢測"搞亂了。
被干擾就必然被檢測，
但不被干擾不能確定是否有檢測。

對於第三點，
我在這裡貼一大段文字，
是我確定我可以全面且比較正確地回答問題。
如果你連我上面發的那帖的文字量都受不了，
也從側面表明你對牆相關的文章閱讀不足。
本帖我將不再進行回复，
亦請你不要再回复，
有任何問題請google或wiki。

*該處有誤，詳見#14。
作者 路人一
 - 一月 23, 2012, 07:28:12 上午
  哈，楼上受累了，抱歉
  略过前面一大段（看了晕。。。），直接跳到你的总结附近，我发现其实我们在某些地方看法是一致的。
我们都认为GFW应该有能力拦截用TCP协议来解析域名的，我说可能是GFW对这块暂时不设防，你也说"當前未有支持TCP做DNS查詢的瀏覽器，牆沒必要浪費這種資源去檢測"，所以最后的结果就是，我们可以使用TCP协议来正确解析域名；

但是，对于这个"结果"的后续判断就有差异了，我认为，既然GFW现在不设防，那就用这个功能，什么问题都不会有，哪天GFW把这个"漏洞"也堵上了，那就用不了，仅此而已。

你一方面认为"你說不危險，是對的"，而另一方面又认为"牆是個複雜的系統，不是說結果沒問題就萬事大吉"，言外之意就是说，虽然现在可以使用TCP协议解析域名，但是还是会被检查域名解析的内容，还是有危险？
那你的结论到底是危险还是不危险？可以安全使用TCP协议解析域名还是觉得这么做不安全所以不该这么做？

再看一个矛盾的表述：针对目前可以使用tcp协议解析域名，你认为"牆沒必要浪費這種資源去檢測"，也就说，你也认为GFW目前没有检测TCP协议域名解析的相关内容，你后续又说"更加不代表它沒有檢查過內容"，那你到底是说GFW检查没检查过？

退一步，如果说墙有能力检测内容、并且有检测内容，那么墙就没有理由不拦截；如果墙出于资源考虑不拦截TCP协议的域名解析，那么它检测内容又有何意义？
借用一下你提到的google的https搜索， 墙暂时对它没招是因为无法得知经过加密的搜索内容，除非墙完全封了google全部ip
顺便说一下，默认使用tcp还是udp协议做域名解析是由系统决定的，不是浏览器或者其他上网程序决定的，具体的，是由system32下的一个dll文件决定的，一高人修改了这个dll，可以让系统默认就使用TCP协议来解析域名，详情自行google

一点感想，其实讨论讨论蛮好的，越讨论，观点就越清晰，还可以锻炼锻炼脑细胞。在自由门板块讨论这个似乎有点离题，都已经讨论这么多了，希望管理员高抬贵手，让我回帖，谢谢！
最后，祝大家新年幸福安康！
作者 temp
 - 一月 22, 2012, 04:31:02 下午
引用自: 路人一 于 一月 22, 2012, 04:13:57 上午
为了不误导人，来做个简单的测试：
1，使用 nslookup www.dongtaiwang.com 8.8.8.8 命令尝试使用默认的UDP协议解析www.dongtaiwang.com的ip
2，打开http://www.kloth.net/services/nslookup.php，使用不加密的、在线网站解析www.dongtaiwang.com的IP
3，使用 nslookup -vc www.dongtaiwang.com 8.8.8.8 命令强制使用tcp协议来解析www.dongtaiwang.com的IP
结果如下：
测试1，触发"www.dongtaiwang.com"敏感词，返回假的IP
测试2，触发"www.dongtaiwang.com"敏感词，连接被重置，什么都看不到
测试3，得到正确的IP
结论：
前两种情形，在GFW的防范范围内，不让你正常使用解析功能；
第三种方法，目前不在GFW的防范范围 （不排除将来GFW会补上这个"漏洞"）
当然了，如果你还坚持说第三种情形下还是被监听，只是GFW不拦截、是故意放你一马、是引蛇出洞，到时候再来统计看看你都解析了哪些敏感网址，找你算总账，那我就无话可说了。
不过如果你真的这么想，离直接拔了网线也差不远了。。。。。。

你還是沒明白我的意思。
牆的深度關鍵字檢測，
能檢測內容但不能修改內容。
你的第一個測試，
是因為UDP本身的缺陷，
牆構造假的結果，
偽裝成目標DNS搶先把偽造的結果發到你機器。
這個叫DNS污染，
以域名作為判斷單位，
跟關鍵字檢測不是同一回事。
第二個測試，
是牆的深度關鍵字檢測，
檢測到敏感詞，
立即雙向發送RST包，
所以你看到鏈接被重置。
第三個測試之所以能獲得IP，
原因有點複雜。
首先你要知道，
關鍵字檢測是對副本進行檢測的，
牆本身並不阻塞鏈接，
而且前面已經說過，
牆不能修改內容。
另外，
DNS的報文不像HTML協議，
長內容分多個包發送。
DNS的請求也就一百多字節，
隨便抓個HTML的包都比它長十幾倍。
綜合上面三點可知，
牆即使發送RST包也沒有意義，
因為哪怕發了RST，
機器也都已經拿到想要的結果，
牆再轟RST一點意義都沒。
<del>至於90秒繼發RST，
同樣的道理，
牆遲到的RST包根本就沒效果。</del>*
從這點考慮，
作為牆沒有好的手段，
它是不會採取措施的。
正如當時google出ssl搜索，
牆沒有好方法的時候就不做過濾。
再從另外一個角度考慮，
當前未有支持TCP做DNS查詢的瀏覽器，
牆沒必要浪費這種資源去檢測。
但這並不是說，
它沒有能力查你的內容，
更加不代表它沒有檢查過內容。
因為，
牆至少要讀取包頭才能確定是何種協議，
從這個角度，
哪怕是TCP的域名查詢請求，
一樣會被讀取。
如果不讀取的話，
怎麼發現這個是域名查詢請求呢？
或者說怎麼發現是個不作深度關鍵字檢測的協議呢？
正是牆分析了包的內容，
才不做後續處理。
牆的原理，
網上有很多文章，
光維基百科就已經說得很詳細。
牆是個複雜的系統，
不是說結果沒問題就萬事大吉。

最後總結一下。
你說不危險，是對的；
上面那位說能監聽，也是對的。
我上面都已經說過，
這些不矛盾的。
寫了這麼多，
僅當科普文吧。
我不是科班出身，
對牆的知識也僅源於網上文章。
如果有什麼錯誤，
還請高人指出，
以免誤導他人。
至於上面的討論，
就此結束吧，
再討論真的沒意思。

*該處有誤，詳見#14的帖子。
作者 路人一
 - 一月 22, 2012, 04:13:57 上午
为了不误导人，来做个简单的测试：
1，使用 nslookup www.dongtaiwang.com 8.8.8.8 命令尝试使用默认的UDP协议解析www.dongtaiwang.com的ip
2，打开http://www.kloth.net/services/nslookup.php，使用不加密的、在线网站解析www.dongtaiwang.com的IP
3，使用 nslookup -vc www.dongtaiwang.com 8.8.8.8 命令强制使用tcp协议来解析www.dongtaiwang.com的IP
结果如下：
测试1，触发"www.dongtaiwang.com"敏感词，返回假的IP
测试2，触发"www.dongtaiwang.com"敏感词，连接被重置，什么都看不到
测试3，得到正确的IP
结论：
前两种情形，在GFW的防范范围内，不让你正常使用解析功能；
第三种方法，目前不在GFW的防范范围 （不排除将来GFW会补上这个"漏洞"）
当然了，如果你还坚持说第三种情形下还是被监听，只是GFW不拦截、是故意放你一马、是引蛇出洞，到时候再来统计看看你都解析了哪些敏感网址，找你算总账，那我就无话可说了。
不过如果你真的这么想，离直接拔了网线也差不远了。。。。。。
作者 la7la8
 - 一月 22, 2012, 04:12:53 上午
需要使用域名解析功能时

我是打开  fg721x   或者  fu24 请保存好这两个就解决问题了
作者 temp
 - 一月 21, 2012, 03:10:06 下午
引用自: 路人一 于 一月 20, 2012, 08:06:22 上午
楼上的扯远了
针对用 nslookup 命令来解析域名而言，不加-vc参数时默认使用udp协议，此时不管你用的哪儿的DNS，都会被污染，导致敏感域名无法正确解析；
而使用tcp协议 外加境外的DNS来解析，则不受GFW的DNS污染的干扰，可以正确解析任何域名。
这事本来就这么简单，简洁实用的有效方法，老少皆宜
因为3楼来一句"这个可以被截获的，而且可以被监听并记录下来"，把本来很单纯的一件事搞得无比复杂，让人觉得你用tcp解析一下域名就是个危险万分的事了？又是"被截获"又是被"监听"，让人啼笑皆非。打一个比方吧，这就好比是说，你上网了，就会被人监视，你浏览哪个网页了，会被人监听、记录一个道理，你不但上网了，你还翻墙了，那更是被记录了，那你还上网不？还翻墙不？
要有安全意识没错，但是走向另一个极端，草木皆兵就不对了，还会误导很多人

沒扯遠。
8.8.8.8是海外IP，
連海外IP就必然會受到關鍵字檢測。
對於敏感人士，
牆的確可以做到監控並記錄。
但對於成千上萬的一般翻牆者，
是不存在這種"特殊照顧"的，
用TCP解析的確不是危險的事。
這些都是事實，
都不衝突的。
作者 路人一
 - 一月 20, 2012, 08:06:22 上午
楼上的扯远了
针对用 nslookup 命令来解析域名而言，不加-vc参数时默认使用udp协议，此时不管你用的哪儿的DNS，都会被污染，导致敏感域名无法正确解析；
而使用tcp协议 外加境外的DNS来解析，则不受GFW的DNS污染的干扰，可以正确解析任何域名。
这事本来就这么简单，简洁实用的有效方法，老少皆宜
因为3楼来一句"这个可以被截获的，而且可以被监听并记录下来"，把本来很单纯的一件事搞得无比复杂，让人觉得你用tcp解析一下域名就是个危险万分的事了？又是"被截获"又是被"监听"，让人啼笑皆非。打一个比方吧，这就好比是说，你上网了，就会被人监视，你浏览哪个网页了，会被人监听、记录一个道理，你不但上网了，你还翻墙了，那更是被记录了，那你还上网不？还翻墙不？
要有安全意识没错，但是走向另一个极端，草木皆兵就不对了，还会误导很多人
作者 temp
 - 一月 19, 2012, 10:26:35 上午
引用自: 路人一 于 一月 18, 2012, 01:26:36 下午
别吓我，我胆子小
可以为你所说的"可以被截获的，而且可以被监听并记录下来"找到相应的事实做为依据吗？
因为知道这个避开gfw的DNS污染的方法的人不少，但从没听到类似的说法，你的说法有点过于耸人听闻了

對於TCP的確可以監聽內容，
牆的深度關鍵字檢測就對TCP有效。
作者 路人一
 - 一月 18, 2012, 01:26:36 下午
引用自: ComeTrue 于 一月 18, 2012, 03:34:23 上午
这个可以被截获的，而且可以被监听并记录下来
别吓我，我胆子小
可以为你所说的"可以被截获的，而且可以被监听并记录下来"找到相应的事实做为依据吗？
因为知道这个避开gfw的DNS污染的方法的人不少，但从没听到类似的说法，你的说法有点过于耸人听闻了
作者 ComeTrue
 - 一月 18, 2012, 03:34:23 上午
引用自: 路人一 于 一月 17, 2012, 11:39:27 上午
其实不用翻墙就可用正确解析出域名的，使用如下命令即可：
nslookup -vc www.abc.com 8.8.8.8

1,使用nslookup命令时加上-vc参数就可以强制使用TCP协议而不是UDP协议进行DNS查询，从而避开GFW的DNS污染
2，www.abc.com  ，即是你要查询的任何域名
3，8.8.8.8   指的是你要使用的境外的DNS服务器（这里用的是google的8.8.8.8），你可以使用其他国家和地区的DNS服务器即可，不要使用中国的DNS服务器查询就行
这个可以被截获的，而且可以被监听并记录下来
作者 路人一
 - 一月 17, 2012, 11:39:27 上午
其实不用翻墙就可用正确解析出域名的，使用如下命令即可：
nslookup -vc www.abc.com 8.8.8.8

1,使用nslookup命令时加上-vc参数就可以强制使用TCP协议而不是UDP协议进行DNS查询，从而避开GFW的DNS污染
2，www.abc.com  ，即是你要查询的任何域名
3，8.8.8.8   指的是你要使用的境外的DNS服务器（这里用的是google的8.8.8.8），你可以使用其他国家和地区的DNS服务器即可，不要使用中国的DNS服务器查询就行

作者 卡啦一定OK
 - 一月 16, 2012, 07:39:15 下午
是啊，这样一来太不方便了！

希望能恢复一下！
作者 fuck墙
 - 一月 15, 2012, 10:39:08 上午
怎么现在自由门没有域名解析的功能了，强烈要求恢复