作者 主题: 怎么现在自由门没有域名解析的功能了,强烈要求恢复  (阅读 6166 次)

fuck墙

  • 访客
怎么现在自由门没有域名解析的功能了,强烈要求恢复

离线 卡啦一定OK

  • 自由发言用户
  • 注册用户
  • **
  • 帖子: 94
是啊,这样一来太不方便了!

希望能恢复一下!

离线 路人一

  • 注册用户
  • *
  • 帖子: 56
其实不用翻墙就可用正确解析出域名的,使用如下命令即可:
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服务器查询就行


离线 ComeTrue

  • 自由发言用户
  • 注册用户
  • **
  • 帖子: 351
其实不用翻墙就可用正确解析出域名的,使用如下命令即可:
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服务器查询就行

这个可以被截获的,而且可以被监听并记录下来

离线 路人一

  • 注册用户
  • *
  • 帖子: 56
这个可以被截获的,而且可以被监听并记录下来

别吓我,我胆子小
可以为你所说的“可以被截获的,而且可以被监听并记录下来”找到相应的事实做为依据吗?
因为知道这个避开gfw的DNS污染的方法的人不少,但从没听到类似的说法,你的说法有点过于耸人听闻了

离线 temp

  • 注册用户
  • *
  • 帖子: 28
别吓我,我胆子小
可以为你所说的“可以被截获的,而且可以被监听并记录下来”找到相应的事实做为依据吗?
因为知道这个避开gfw的DNS污染的方法的人不少,但从没听到类似的说法,你的说法有点过于耸人听闻了


對於TCP的確可以監聽內容,
牆的深度關鍵字檢測就對TCP有效。

离线 路人一

  • 注册用户
  • *
  • 帖子: 56
楼上的扯远了
针对用 nslookup 命令来解析域名而言,不加-vc参数时默认使用udp协议,此时不管你用的哪儿的DNS,都会被污染,导致敏感域名无法正确解析;
而使用tcp协议 外加境外的DNS来解析,则不受GFW的DNS污染的干扰,可以正确解析任何域名。
这事本来就这么简单,简洁实用的有效方法,老少皆宜
因为3楼来一句“这个可以被截获的,而且可以被监听并记录下来”,把本来很单纯的一件事搞得无比复杂,让人觉得你用tcp解析一下域名就是个危险万分的事了?又是“被截获”又是被“监听”,让人啼笑皆非。打一个比方吧,这就好比是说,你上网了,就会被人监视,你浏览哪个网页了,会被人监听、记录一个道理,你不但上网了,你还翻墙了,那更是被记录了,那你还上网不?还翻墙不?
要有安全意识没错,但是走向另一个极端,草木皆兵就不对了,还会误导很多人

离线 temp

  • 注册用户
  • *
  • 帖子: 28
楼上的扯远了
针对用 nslookup 命令来解析域名而言,不加-vc参数时默认使用udp协议,此时不管你用的哪儿的DNS,都会被污染,导致敏感域名无法正确解析;
而使用tcp协议 外加境外的DNS来解析,则不受GFW的DNS污染的干扰,可以正确解析任何域名。
这事本来就这么简单,简洁实用的有效方法,老少皆宜
因为3楼来一句“这个可以被截获的,而且可以被监听并记录下来”,把本来很单纯的一件事搞得无比复杂,让人觉得你用tcp解析一下域名就是个危险万分的事了?又是“被截获”又是被“监听”,让人啼笑皆非。打一个比方吧,这就好比是说,你上网了,就会被人监视,你浏览哪个网页了,会被人监听、记录一个道理,你不但上网了,你还翻墙了,那更是被记录了,那你还上网不?还翻墙不?
要有安全意识没错,但是走向另一个极端,草木皆兵就不对了,还会误导很多人


沒扯遠。
8.8.8.8是海外IP,
連海外IP就必然會受到關鍵字檢測。
對於敏感人士,
牆的確可以做到監控並記錄。
但對於成千上萬的一般翻牆者,
是不存在這種“特殊照顧”的,
用TCP解析的確不是危險的事。
這些都是事實,
都不衝突的。
« 最后编辑时间: 一月 21, 2012, 09:20:47 am 作者 temp »

离线 la7la8

  • 注册用户
  • *
  • 帖子: 79
需要使用域名解析功能时

我是打开  fg721x   或者  fu24 请保存好这两个就解决问题了

离线 路人一

  • 注册用户
  • *
  • 帖子: 56
为了不误导人,来做个简单的测试:
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不拦截、是故意放你一马、是引蛇出洞,到时候再来统计看看你都解析了哪些敏感网址,找你算总账,那我就无话可说了。
不过如果你真的这么想,离直接拔了网线也差不远了。。。。。。

离线 temp

  • 注册用户
  • *
  • 帖子: 28
为了不误导人,来做个简单的测试:
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的帖子。
« 最后编辑时间: 一月 24, 2012, 10:20:42 pm 作者 temp »

离线 路人一

  • 注册用户
  • *
  • 帖子: 56
  哈,楼上受累了,抱歉
  略过前面一大段(看了晕。。。),直接跳到你的总结附近,我发现其实我们在某些地方看法是一致的。
我们都认为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

  • 注册用户
  • *
  • 帖子: 28
  哈,楼上受累了,抱歉
  略过前面一大段(看了晕。。。),直接跳到你的总结附近,我发现其实我们在某些地方看法是一致的。
我们都认为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。
« 最后编辑时间: 一月 24, 2012, 10:24:39 pm 作者 temp »

离线 nxzgs

  • 注册用户
  • *
  • 帖子: 26
通过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

  • 注册用户
  • *
  • 帖子: 28
通过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包卻被我過濾了
(低級錯誤啊慘),
所以做了錯誤的結論。
本來說不再回复,
但既然說錯了,
也一定要把錯的地方指出來,
否則誤導就不好了。

最後感謝樓上這位仁兄指出這個受到“特級待遇”的域名。。
« 最后编辑时间: 一月 24, 2012, 10:22:18 pm 作者 temp »