2007年7月27日星期五
塔利班处死韩国人质
http://news.qq.com/zt/2007/tlbhrz/
看到这个报道很震惊,塔利班将境内所有外国人作为绑架对象。
看到这个报道很震惊,塔利班将境内所有外国人作为绑架对象。
中国日报网环球在线消息：塔利班发言人艾哈迈迪7月25日称，由于阿富汗政府拒绝释放塔利班囚犯，塔利班当天已“处死”一名男性韩国人质。
据英国媒体报道，艾哈迈迪通过电话告诉记者：“由于阿富汗政府不听从我们的要求释放塔利班囚犯，塔利班已开枪打死了一名男性韩国人质。”他补充说，如果塔利班的要求得不到满足，他们将处死更多人质。
当天早些时候，艾哈迈迪透露，有关23名韩国人质的谈判已经中断，他们准备杀死“一些”人质。(李卉）阿富汗政府当天晚些时候也证实了塔利班处死人质的声明，并称在穆穑崎地区发现了这名被害人质的尸体。
2007年7月26日星期四
2007年7月25日星期三
证实收到'aaazzzaaazzzaaazzzaaazzzaaazzz'的真实原因
(注：域名和IP信息有修改)从sales2@test.com（在大陆）发给construction@recipient.com（在香港,我们分公司）,在发件人服务器查到如下日志：
Oct 12 10:43:37 localhost postfix/smtpd[30005]: E50DD4187A5: client=unknown[125.0.0.1], sasl_method=LOGIN, sasl_username=sales2@test.comOct 12 10:43:43 localhost postfix/cleanup[28691]: E50DD4187A5: message-id=<20061012024337.E50DD4187A5@slave.mail51.cn4e.com>Oct 12 10:43:44 localhost postfix/qmgr[17170]: E50DD4187A5: from=<sales2@test.com>, size=36652, nrcpt=2 (queue active)Oct 12 10:48:53 localhost postfix/smtp[1140]: E50DD4187A5: to=<construction@recipient.com>, relay=202.67.0.1[202.67.0.1], delay=316, status=deferred (conversation with 202.67.0.1[202.67.0.1] timed out while sending MAIL FROM)Oct 12 11:43:20 localhost postfix/qmgr[17170]: E50DD4187A5: from=<sales2@test.com>, size=36652, nrcpt=2 (queue active)Oct 12 11:43:30 localhost postfix/smtp[28474]: E50DD4187A5: to=<construction@recipient.com>, relay=202.67.0.1[202.67.0.1], delay=3593, status=deferred (lost connection with 202.67.0.1[202.67.0.1] while sending message body)Oct 12 13:43:20 localhost postfix/qmgr[17170]: E50DD4187A5: from=<sales2@test.com>, size=36652, nrcpt=2 (queue active)Oct 12 13:43:22 localhost postfix/smtp[5424]: E50DD4187A5: to=<construction@recipient.com>, relay=202.67.0.1[202.67.0.1], delay=10785, status=bounced (host 202.67.0.1[202.67.0.1] said: 500 error (in reply to MAIL FROM command))Oct 12 13:45:22 localhost postfix/qmgr[17170]: E50DD4187A5: removed
发件人sales2@test.com收到退信
<construction@recipient.com>: host 202.67.0.1[202.67.0.1] said: 500 error (in reply to MAIL FROM command)
在香港的分公司查到如下日志：
Oct 12 10:44:45 hk postfix/smtpd[21468]: 3BCDC2B000F: client=unknown[218.85.0.1]Oct 12 10:44:45 hk postfix/cleanup[22131]: 3BCDC2B000F: message-id=<20061012020145.3BCDC2B000F@hk.com>Oct 12 10:44:45 hk postfix/qmgr[25450]: 3BCDC2B000F: from=<sales2@test.com>, size=475, nrcpt=2 (queue active)Oct 12 10:44:53 hk postfix/smtp[22352]: 3BCDC2B000F: to=<construction@recipient.com>, relay=maildrop, delay=8, status=sent (recipient.com)Oct 12 10:44:53 hk postfix/qmgr[25450]: 3BCDC2B000F: removed
说明这封信已经成功发过去了，但是为什么发件人会收到退信呢？退信是从那来的呢？对比一下这两条日志：
Oct 12 10:43:44 localhost postfix/qmgr[17170]: E50DD4187A5: from=<sales2@test.com>, size=36652, nrcpt=2 (queue active) (在发件人服务器上的日志）Oct 12 10:44:45 hk postfix/qmgr[25450]: 3BCDC2B000F: from=<sales2@test.com>, size=475, nrcpt=2 (queue active) (香港收件服务器上的日志）
发件人发送的时候size=36652,而到了香港却被变成了size=475??再看一下construction@recipient.com收到的这封信的内容，如下，竟然是aaazzzaaazzzaaazzzaaazzzaaazzz：Return-Path: <sales2@test.com>Delivered-To: construction@recipient.comReceived: by mail.hk.com (202.67.0.1) (Postfix, from userid 12346) id 3BCDC2B000F; Thu, 12 Oct 2006 10:44:53 +0800 (CST)X-filter: PassedReceived: from unkoown (218.85.0.1) by mail.test.com (Postfix) with ESMTP id E50DD4187A5 for <construction@recipient.com>; Thu, 12 Oct 2006 10:43:56 +0800 (CST)Message-Id: <20061012020145.3BCDC2B000F@hk.com>Date: Thu, 12 Oct 2006 10:44:45 +0800 (HKT)From: sales2@test.comTo: undisclosed-recipients:;aaazzzaaazzzaaazzzaaazzzaaazzz看到这里相信大家也都明白了，在发件人发给香港的时候，被某一“东东”终止了，返回给发件人500 error，同时其把内容更改后发给了收件人，于是就出现发件人收到500 error ，而收件人收到aaazzzaaazzzaaazzzaaazzzaaazzz的奇怪事情。这个“东东”就是GFW了（中国网络防火墙）,也证实了前面贴子大家讨论得出的结论都是正确的。
Oct 12 10:43:37 localhost postfix/smtpd[30005]: E50DD4187A5: client=unknown[125.0.0.1], sasl_method=LOGIN, sasl_username=sales2@test.comOct 12 10:43:43 localhost postfix/cleanup[28691]: E50DD4187A5: message-id=<20061012024337.E50DD4187A5@slave.mail51.cn4e.com>Oct 12 10:43:44 localhost postfix/qmgr[17170]: E50DD4187A5: from=<sales2@test.com>, size=36652, nrcpt=2 (queue active)Oct 12 10:48:53 localhost postfix/smtp[1140]: E50DD4187A5: to=<construction@recipient.com>, relay=202.67.0.1[202.67.0.1], delay=316, status=deferred (conversation with 202.67.0.1[202.67.0.1] timed out while sending MAIL FROM)Oct 12 11:43:20 localhost postfix/qmgr[17170]: E50DD4187A5: from=<sales2@test.com>, size=36652, nrcpt=2 (queue active)Oct 12 11:43:30 localhost postfix/smtp[28474]: E50DD4187A5: to=<construction@recipient.com>, relay=202.67.0.1[202.67.0.1], delay=3593, status=deferred (lost connection with 202.67.0.1[202.67.0.1] while sending message body)Oct 12 13:43:20 localhost postfix/qmgr[17170]: E50DD4187A5: from=<sales2@test.com>, size=36652, nrcpt=2 (queue active)Oct 12 13:43:22 localhost postfix/smtp[5424]: E50DD4187A5: to=<construction@recipient.com>, relay=202.67.0.1[202.67.0.1], delay=10785, status=bounced (host 202.67.0.1[202.67.0.1] said: 500 error (in reply to MAIL FROM command))Oct 12 13:45:22 localhost postfix/qmgr[17170]: E50DD4187A5: removed
发件人sales2@test.com收到退信
<construction@recipient.com>: host 202.67.0.1[202.67.0.1] said: 500 error (in reply to MAIL FROM command)
在香港的分公司查到如下日志：
Oct 12 10:44:45 hk postfix/smtpd[21468]: 3BCDC2B000F: client=unknown[218.85.0.1]Oct 12 10:44:45 hk postfix/cleanup[22131]: 3BCDC2B000F: message-id=<20061012020145.3BCDC2B000F@hk.com>Oct 12 10:44:45 hk postfix/qmgr[25450]: 3BCDC2B000F: from=<sales2@test.com>, size=475, nrcpt=2 (queue active)Oct 12 10:44:53 hk postfix/smtp[22352]: 3BCDC2B000F: to=<construction@recipient.com>, relay=maildrop, delay=8, status=sent (recipient.com)Oct 12 10:44:53 hk postfix/qmgr[25450]: 3BCDC2B000F: removed
说明这封信已经成功发过去了，但是为什么发件人会收到退信呢？退信是从那来的呢？对比一下这两条日志：
Oct 12 10:43:44 localhost postfix/qmgr[17170]: E50DD4187A5: from=<sales2@test.com>, size=36652, nrcpt=2 (queue active) (在发件人服务器上的日志）Oct 12 10:44:45 hk postfix/qmgr[25450]: 3BCDC2B000F: from=<sales2@test.com>, size=475, nrcpt=2 (queue active) (香港收件服务器上的日志）
发件人发送的时候size=36652,而到了香港却被变成了size=475??再看一下construction@recipient.com收到的这封信的内容，如下，竟然是aaazzzaaazzzaaazzzaaazzzaaazzz：Return-Path: <sales2@test.com>Delivered-To: construction@recipient.comReceived: by mail.hk.com (202.67.0.1) (Postfix, from userid 12346) id 3BCDC2B000F; Thu, 12 Oct 2006 10:44:53 +0800 (CST)X-filter: PassedReceived: from unkoown (218.85.0.1) by mail.test.com (Postfix) with ESMTP id E50DD4187A5 for <construction@recipient.com>; Thu, 12 Oct 2006 10:43:56 +0800 (CST)Message-Id: <20061012020145.3BCDC2B000F@hk.com>Date: Thu, 12 Oct 2006 10:44:45 +0800 (HKT)From: sales2@test.comTo: undisclosed-recipients:;aaazzzaaazzzaaazzzaaazzzaaazzz看到这里相信大家也都明白了，在发件人发给香港的时候，被某一“东东”终止了，返回给发件人500 error，同时其把内容更改后发给了收件人，于是就出现发件人收到500 error ，而收件人收到aaazzzaaazzzaaazzzaaazzzaaazzz的奇怪事情。这个“东东”就是GFW了（中国网络防火墙）,也证实了前面贴子大家讨论得出的结论都是正确的。
伟大的GFW,它不是一个人
伟大的GFW,它不是一个人
（from：http://sunbotu.com/post/290.html）
继前段时间的河蟹外国网站之后，我们伟大的防火墙终于再次为我们带来的激动人心的暑假资料片―邮箱封锁战！
国内的邮箱几乎全部出现了被退信的情况，并经过一些分析，是被某些东西给堵住了。当我们还为Google Mail里插入广告的问题而担心隐私的时候，我们伟大的祖国
却监视着每一封出入这个国家的电子邮件。是不是以后电子邮件首发也要备案了？独裁啊，专治啊！！哦，我的天。现在我终于知道加密的重要性了，OpenBSD，我来
了！以后坚决使用带Secrue的东西，ssh啊，https啊，不带坚决不能用了！！
（from：http://sunbotu.com/post/290.html）
继前段时间的河蟹外国网站之后，我们伟大的防火墙终于再次为我们带来的激动人心的暑假资料片―邮箱封锁战！
国内的邮箱几乎全部出现了被退信的情况，并经过一些分析，是被某些东西给堵住了。当我们还为Google Mail里插入广告的问题而担心隐私的时候，我们伟大的祖国
却监视着每一封出入这个国家的电子邮件。是不是以后电子邮件首发也要备案了？独裁啊，专治啊！！哦，我的天。现在我终于知道加密的重要性了，OpenBSD，我来
了！以后坚决使用带Secrue的东西，ssh啊，https啊，不带坚决不能用了！！
国内的邮箱啊？～
虽然没有指名说是GFW问题,但这次退信事件和长城防火一定有关
联合通告 :)
http://blog.cybersome.com/2007/07/mails-blocked/
新浪关于海外邮件通信问题的说明
http://vip.sina.com.cn/loginbefore/news-maintext070717.html
网易关于海外邮件通信问题的说明
http://vip.163.com/vip/notice.html
万网关于海外邮件通信问题的说明
http://www.net.cn/service/a/zytz/200707/2312.html
新网关于与海外邮件通信问题的说明
http://bulletin.xinnet.com/News/200771710226.html
中国频道关于与海外收发邮件的特殊问题
http://www.china-channel.com/hot_news.asp?ID=737
中资源关于海外邮件通信问题的说明
http://www.zzy.cn/file/07-07-17.htm
35互联关于与海外收发邮件的特殊问题
http://www.35.com/xinwenzx/xinwenzx_news.asp?ID=516
263关于与海外收发邮件的特殊问题
http://gmail.263.net/news1-0.html
尚易关于与海外收发邮件的特殊问题
http://www.corpease.net/service_12_87.htm
联合通告 :)
http://blog.cybersome.com/2007/07/mails-blocked/
新浪关于海外邮件通信问题的说明
http://vip.sina.com.cn/loginbefore/news-maintext070717.html
网易关于海外邮件通信问题的说明
http://vip.163.com/vip/notice.html
万网关于海外邮件通信问题的说明
http://www.net.cn/service/a/zytz/200707/2312.html
新网关于与海外邮件通信问题的说明
http://bulletin.xinnet.com/News/200771710226.html
中国频道关于与海外收发邮件的特殊问题
http://www.china-channel.com/hot_news.asp?ID=737
中资源关于海外邮件通信问题的说明
http://www.zzy.cn/file/07-07-17.htm
35互联关于与海外收发邮件的特殊问题
http://www.35.com/xinwenzx/xinwenzx_news.asp?ID=516
263关于与海外收发邮件的特殊问题
http://gmail.263.net/news1-0.html
尚易关于与海外收发邮件的特殊问题
http://www.corpease.net/service_12_87.htm
2007年7月24日星期二
Comsenz 核心产品 Discuz! 6.0.0 RC1 发布免费下载
Discuz! 6.0.0 RC1 今天终于出来了,但是目前还不打算升级自己的论坛先测试一段时间
概述
经过数月的开发，一个多月的测试 Discuz! 6.0.0 RC1 开源版本正式提供下载使用。
●
全新改写的模板采用XHTML 1.0，完全符合W3C国际标准，页面更清爽、打开速度更快。
●
增加了时下热门的分类信息，使论坛里海量的信息更容易浏览和管理。
● 主题标签功能（TAG），让帖子之间关联更加紧密。
●
火爆的论坛辩论主题，增加用户的参与感、社区的趣味性，最终提升社区黏性。
● 全面升级了电子商务功能，轻松实现个人店铺功能。
●
版块聚合功能帮助管理人员迅速提取整合版面精华加以展现。
● 和Insenz社区营销进行紧密整合，迅速帮助各位站长找到一条社区盈利之路。
同时对5.5.0出现的问题进行了修正，并对100余处功能在易用性、功能性上做了调整和加强，力求让用户用起来更简单更方便。除了上述所说，还有更多细节调整，大家慢慢体会这里就不一一例举了。
自官方升级 6.0 以来，截至 7月24日晚 “Discuz!6.0.0专区”共收到反馈意见 3000
余篇，感谢为我们提出意见并帮我们寻找问题的朋友们，我们会以更优秀的程序回报大家。
根据 RC1
版本大家测试的反馈意见，我们还会在正式版发布前，对论坛功能和界面做进一步的调整。
升级
● 备份论坛当前数据库。
● 上传除config.inc.php和install.php以及install目录之外的全部 Discuz! 6.0.0 文件，上传到服务器覆盖原
Discuz! 5.5.0 文件。
● 上传 ./utilities/upgrade9.php
到论坛程序根目录下运行，按照操作提示，直至全部升级完毕（默认情况下无需人工干预） 删除服务器上的升级程序 upgrade9.php。
●
风格升级：http://www.discuz.net/thread-687251-1-1.html
● 升级完成。
下载
Discuz! 6.0.0 RC1 提供 4 种
编码版本供用户下载使用，请根据需要选择适当的版本，各版本除语言编码具有差异以外，其他功能完全一样。注意： RC1 版本中，不提供“英文版”语言包。
Discuz! 6.0.0 RC1 GBK 简体中文版(推荐)
http://download.discuz.net/6.0.0/Discuz!_6.0.0RC1_SC_GBK.zip
电信下载：
http://download2.discuz.net/6.0.0/Discuz!_6.0.0RC1_SC_GBK.zip
Discuz! 6.0.0 RC1 UTF-8 简体中文版
http://download.discuz.net/6.0.0/Discuz!_6.0.0RC1_SC_UTF8.zip
电信下载：
http://download.discuz.net/6.0.0/Discuz!_6.0.0RC1_SC_UTF8.zip
Discuz! 6.0.0 RC1 BIG5 繁体中文版(推荐)
http://download.discuz.net/6.0.0/Discuz!_6.0.0RC1_TC_BIG5.zip
电信下载：
http://download.discuz.net/6.0.0/Discuz!_6.0.0RC1_TC_BIG5.zip
Discuz! 6.0.0 RC1 UTF-8 繁体中文版
http://download.discuz.net/6.0.0/Discuz!_6.0.0RC1_TC_UTF8.zip
电信下载：
http://download.discuz.net/6.0.0/Discuz!_6.0.0RC1_TC_UTF8.zip
上海电信DNS劫持事件
使用上海电信宽带接入的朋友可能最近也经常像我一样在浏览网站时莫名其妙地输入网址后转向了114查询的页面，此类事故在以前曾听过有类似的传言，而以前我个人并未碰到，所以并不在意，但如今我是天天被114这个破烂页面骚扰，于是也不得不仔细找找原因了。
首先解释一下什么是DNS劫持。严格来说上海电信的这种行为不能算是DNS劫持，但似乎除了这个名词也没有更适合的词来形容这种行为了，所以就需要解释一下DNS劫持的来龙去脉，免得有人说我误导初学者。
DNS劫持是网络安全界常见的一个名词，意思是通过某些手段取得某一目标域名的解析记录控制权，进而修改此域名的解析结果，通过此修改将对此域名的访问由原先的IP地址转入到自己指定的IP，从而实现窃取资料或者破坏原有正常服务的目的。举个例子，例如www.sohu.com原指向1.1.1.1，这个IP是sohu正常服务的服务器IP。而某黑人拿到了修改sohu.com域名解析的权利，将其解析记录修改为2.2.2.2，则修改后对于www.sohu.com的访问都会指向2.2.2.2这个IP。此黑人在2.2.2.2这个他自己所有的IP上放了一个完全仿冒的sohu主页，只是将登陆sohu邮箱的这个界面改为把客户填写的邮箱名和密码记录下来。这样普通客户访问www.sohu.com时看到的是表面为sohu主页，而实际为假冒页面的李鬼了。此时客户如果继续登陆其sohu邮箱，则其帐户就被黑人拿到了。
回到主题—有关上海电信的DNS劫持行为。在我发现近期浏览网页出现异常的这段时间里，我注意搜索了一下关于这方面的讨论，发现上海电信的这种不道德行为确实是存在的，只是我以前恰好没有入套而已。根据我搜索来的资料，在06年下半年的时间里，上海电信实现了通过IE浏览器搜索功能来推送电信的114搜索。其具体原理是与IE本身的实现相关。简单来说，IE对于输入的网址，如果无法正常解析其域名或者输入的根本就不是域名的话，会调用它自身定义的搜索引擎来搜索这个地址。这个搜索引擎，默认是MSN（在之前是3721，但06年微软终止了与3721的合同，所以是MSN）。所以此时地址会转向http://auto.search.msn.com。上海电信为了将这部分流量导入自己的怀里，做了2种小动作：
•第一是在他们的星空XX拨号软件里，只要安装这个软件，就会修改注册表将IE的搜索引擎改为http://search.114.vnet.cn，于是这些流量被导入到114，此做法尚可忍受，因为毕竟软件是可以选择的，而修改也是可以改回来的。
•第二就是DNS劫持了，这就是公然违反网络标准以及违反互联网道德的行为了。具体细节就是在上海电信的几个DNS服务器中作手脚，将对auto.search.msn.com这个域名解析的应答篡改为他们自己的IP地址，这是很容易查出来的：
首先看由Root服务器下来的权威结果，我们用DNSStuff这个在线网站测试，URL为http://www.dnsstuff.com/tools/lookup.ch?name=auto.search.msn.com&type=A，可以看到如下结果：
Response:
Domain Type Class TTL Answer
a134.g.akamai.net.6528acf.1.cn.akamaitech.net. A IN 20 67.130.109.38
a134.g.akamai.net.6528acf.1.cn.akamaitech.net. A IN 20 67.130.109.16
NOTE: One or more CNAMEs were encountered. auto.search.msn.com is really a134.g.akamai.net.6528acf.1.cn.akamaitech.net. [auto.search.msn.com->sea.search.msn.com->sea.search.msn.com.nsatc.net->search.msn.com.edgesuite.net->a134.g.akamai.net->a134.g.akamai.net.6528acf.1.cn.akamaitech.net]
再来看我们使用了上海热线DNS所解析出来的结果，我这里用BIND提供的dig工具来取结果：
# dig @202.96.209.5 A auto.search.msn.com
; <<>> DiG 9.2.4 <<>> @202.96.209.5 A auto.search.msn.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18248
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4
;; QUESTION SECTION:
;auto.search.msn.com. IN A
;; ANSWER SECTION:
auto.search.msn.com. 86400 IN A 218.30.64.194
;; AUTHORITY SECTION:
auto.search.msn.com. 86400 IN NS ns-puxi.online.sh.cn.
auto.search.msn.com. 86400 IN NS ns-pudong.online.sh.cn.
auto.search.msn.com. 86400 IN NS ns-pd.online.sh.cn.
auto.search.msn.com. 86400 IN NS ns-px.online.sh.cn.
auto.search.msn.com. 86400 IN NS ns-px2.online.sh.cn.
;; ADDITIONAL SECTION:
ns-pd.online.sh.cn. 86400 IN A 202.96.209.133
ns-px.online.sh.cn. 86400 IN A 202.96.209.5
ns-puxi.online.sh.cn. 86400 IN A 202.96.209.5
ns-pudong.online.sh.cn. 86400 IN A 202.96.209.133
;; Query time: 23 msec
;; SERVER: 202.96.209.5#53(202.96.209.5)
;; WHEN: Wed Mar 14 14:51:08 2007
;; MSG SIZE rcvd: 236
可以看到auto.search.msn.com被解析到了218.30.64.194这个IP，这显然是不对的，而本应属于微软的msn域名的NS记录竟然为5个上海热线的域名服务器，很明显猫腻就在这里了。
那我们就顺便查查218.30.64.194这个IP的所有，通过IP whois信息库，查询方法也是通过方便至极的DNSStuff，URL如下：http://www.dnsstuff.com/tools/whois.ch?ip=218.30.64.194，摘录一下结果：
WHOIS results for 218.30.64.194
Generated by www.DNSstuff.com
Location: China [City: Shenzhen, Guangdong]
ARIN says that this IP belongs to APNIC; I’m looking it up there.
% [whois.apnic.net node-2]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 218.30.64.0 - 218.30.64.255
netname: CHINANET-CN
country: CN
descr: Chinavnet
descr: No.31 ,jingrong street,beijing
admin-c: CH93-AP
tech-c: CH93-AP
status: ALLOCATED NON-PORTABLE
changed: *****@chinatelecom.com.cn 20051026
mnt-by: MAINT-CHINANET
source: APNIC
person: Chinanet Hostmaster
nic-hdl: CH93-AP
e-mail: *********@ns.chinanet.cn.net
address: No.31 ,jingrong street,beijing
address: 100032
phone: +86-10-58501724
fax-no: +86-10-58501724
country: CN
changed: *****@chinatelecom.com.cn 20051212
mnt-by: MAINT-CHINANET
source: APNIC
很明显这个IP是中国电信的，而msn的域名就是这样被强奸到了中国电信的IP。
以上就是06年中上海电信所做的手脚了，其实对于如此行为我个人还是可以忍受的，因为第一我不会去装什么星空XXX，即使装了我也有办法不用你的东西。第二我不用MSN的搜索，你劫持了它对我没什么影响。然而，从最近一段时间的异常来看，事情显然已经不只是这个地步了，因为我在用各种浏览器各种搜索引擎的时候都碰到了被转向了114的情况，再加上我个人工作所维护的一些邮件服务器最近发现的怪异情况，我有理由怀疑上海电信在DNS上做了更令人不齿的行为。很不幸，我只是简单测试了一下，就发现确实如此，这次的行为可谓明刀明枪的抢劫了：
C:\>ping notpresentxxxxxxxxxx.cn
Pinging notpresentxxxxxxxxxx.cn [218.83.175.154] with 32 bytes of data:
Reply from 218.83.175.154: bytes=32 time=124ms TTL=242
Reply from 218.83.175.154: bytes=32 time=122ms TTL=242
Reply from 218.83.175.154: bytes=32 time=134ms TTL=242
Reply from 218.83.175.154: bytes=32 time=134ms TTL=242
Ping statistics for 218.83.175.154:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 122ms, Maximum = 134ms, Average = 128ms
C:\>ping dsfsdofhetfowefuwdf.com
Pinging dsfsdofhetfowefuwdf.com [218.83.175.154] with 32 bytes of data:
Reply from 218.83.175.154: bytes=32 time=126ms TTL=242
Reply from 218.83.175.154: bytes=32 time=125ms TTL=242
Reply from 218.83.175.154: bytes=32 time=116ms TTL=242
Reply from 218.83.175.154: bytes=32 time=118ms TTL=242
Ping statistics for 218.83.175.154:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 116ms, Maximum = 126ms, Average = 121ms
C:\>ping gherogfhgnewlffefh.com
Pinging gherogfhgnewlffefh.com [218.83.175.154] with 32 bytes of data:
Reply from 218.83.175.154: bytes=32 time=674ms TTL=242
Reply from 218.83.175.154: bytes=32 time=1007ms TTL=242
Reply from 218.83.175.154: bytes=32 time=1002ms TTL=242
Reply from 218.83.175.154: bytes=32 time=812ms TTL=242
Ping statistics for 218.83.175.154:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 674ms, Maximum = 1007ms, Average = 873ms
相信会用ping命令的网友们自然能看得懂这段输出的意思，简单来说，我ping了3个根本不存在的域名，本应出现找不到域名错误(hostname not found)，然而这显然不存在的3个域名竟然能得到解析结果，而无一例外的指向同一个IP—-218.83.175.154。这个IP是什么我想大家应该也会非常有兴趣知道，点一下看看吧http://218.83.175.154。照样不能忘记把这个IP的whois信息拿出来作证据：http://www.dnsstuff.com/tools/whois.ch?ip=218.83.175.154，顺便贴出来：
WHOIS results for 218.83.175.154
Generated by www.DNSstuff.com
Location: China [City: Shanghai, Shandong]
ARIN says that this IP belongs to APNIC; I’m looking it up there.
% [whois.apnic.net node-1]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 218.78.0.0 - 218.83.255.255
netname: CHINANET-SH
descr: CHINANET Shanghai province network
descr: Data Communication Division
descr: China Telecom
country: CN
admin-c: CH93-AP
tech-c: XI5-AP
mnt-by: APNIC-HM
mnt-lower: MAINT-CHINANET-SH
mnt-routes: MAINT-CHINANET-SH
status: ALLOCATED PORTABLE
changed: **********@apnic.net 20060427
source: APNIC
person: Chinanet Hostmaster
nic-hdl: CH93-AP
e-mail: *********@ns.chinanet.cn.net
address: No.31 ,jingrong street,beijing
address: 100032
phone: +86-10-58501724
fax-no: +86-10-58501724
country: CN
changed: *****@chinatelecom.com.cn 20051212
mnt-by: MAINT-CHINANET
source: APNIC
person: Wu Xiao Li
address: Room 805,61 North Si Chuan Road,Shanghai,200085,PRC
country: CN
phone: +86-21-63630562
fax-no: +86-21-63630566
e-mail: ********@mail.online.sh.cn
nic-hdl: XI5-AP
mnt-by: MAINT-CHINANET-SH
changed: ********@mail.online.sh.cn 20010510
source: APNIC
铁证如山，看你上海电信还如何抵赖，目前我自己发现的出现问题的DNS服务器有202.96.209.5，202.96.209.6，202.96.209.133，202.96.209.134，都为上海电信ADSL的DHCP默认指派的DNS，应该还有数个服务器应该也是类似，只是我没有去求证。
做为中国最大的ISP，发布广告无可厚非，但却打着官方的旗号公然破坏互联网基础设施，公然违反互联网RFC，真可谓给国内各大企业带了个好头，再加上CNNIC的流氓行为，中国互联网还有什么前途？！我作为IT网络业界的一个普通技术人员，对此现状真的感到深深的悲哀。
现在唯一还能让我高兴起来的事情，就是似乎这个转入到114查询的关键字似乎是随机选取的，经常会出现让人哭笑不得的结果，莫非电信的技术们也开始学习玩无厘头风格了？
首先解释一下什么是DNS劫持。严格来说上海电信的这种行为不能算是DNS劫持，但似乎除了这个名词也没有更适合的词来形容这种行为了，所以就需要解释一下DNS劫持的来龙去脉，免得有人说我误导初学者。
DNS劫持是网络安全界常见的一个名词，意思是通过某些手段取得某一目标域名的解析记录控制权，进而修改此域名的解析结果，通过此修改将对此域名的访问由原先的IP地址转入到自己指定的IP，从而实现窃取资料或者破坏原有正常服务的目的。举个例子，例如www.sohu.com原指向1.1.1.1，这个IP是sohu正常服务的服务器IP。而某黑人拿到了修改sohu.com域名解析的权利，将其解析记录修改为2.2.2.2，则修改后对于www.sohu.com的访问都会指向2.2.2.2这个IP。此黑人在2.2.2.2这个他自己所有的IP上放了一个完全仿冒的sohu主页，只是将登陆sohu邮箱的这个界面改为把客户填写的邮箱名和密码记录下来。这样普通客户访问www.sohu.com时看到的是表面为sohu主页，而实际为假冒页面的李鬼了。此时客户如果继续登陆其sohu邮箱，则其帐户就被黑人拿到了。
回到主题—有关上海电信的DNS劫持行为。在我发现近期浏览网页出现异常的这段时间里，我注意搜索了一下关于这方面的讨论，发现上海电信的这种不道德行为确实是存在的，只是我以前恰好没有入套而已。根据我搜索来的资料，在06年下半年的时间里，上海电信实现了通过IE浏览器搜索功能来推送电信的114搜索。其具体原理是与IE本身的实现相关。简单来说，IE对于输入的网址，如果无法正常解析其域名或者输入的根本就不是域名的话，会调用它自身定义的搜索引擎来搜索这个地址。这个搜索引擎，默认是MSN（在之前是3721，但06年微软终止了与3721的合同，所以是MSN）。所以此时地址会转向http://auto.search.msn.com。上海电信为了将这部分流量导入自己的怀里，做了2种小动作：
•第一是在他们的星空XX拨号软件里，只要安装这个软件，就会修改注册表将IE的搜索引擎改为http://search.114.vnet.cn，于是这些流量被导入到114，此做法尚可忍受，因为毕竟软件是可以选择的，而修改也是可以改回来的。
•第二就是DNS劫持了，这就是公然违反网络标准以及违反互联网道德的行为了。具体细节就是在上海电信的几个DNS服务器中作手脚，将对auto.search.msn.com这个域名解析的应答篡改为他们自己的IP地址，这是很容易查出来的：
首先看由Root服务器下来的权威结果，我们用DNSStuff这个在线网站测试，URL为http://www.dnsstuff.com/tools/lookup.ch?name=auto.search.msn.com&type=A，可以看到如下结果：
Response:
Domain Type Class TTL Answer
a134.g.akamai.net.6528acf.1.cn.akamaitech.net. A IN 20 67.130.109.38
a134.g.akamai.net.6528acf.1.cn.akamaitech.net. A IN 20 67.130.109.16
NOTE: One or more CNAMEs were encountered. auto.search.msn.com is really a134.g.akamai.net.6528acf.1.cn.akamaitech.net. [auto.search.msn.com->sea.search.msn.com->sea.search.msn.com.nsatc.net->search.msn.com.edgesuite.net->a134.g.akamai.net->a134.g.akamai.net.6528acf.1.cn.akamaitech.net]
再来看我们使用了上海热线DNS所解析出来的结果，我这里用BIND提供的dig工具来取结果：
# dig @202.96.209.5 A auto.search.msn.com
; <<>> DiG 9.2.4 <<>> @202.96.209.5 A auto.search.msn.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18248
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4
;; QUESTION SECTION:
;auto.search.msn.com. IN A
;; ANSWER SECTION:
auto.search.msn.com. 86400 IN A 218.30.64.194
;; AUTHORITY SECTION:
auto.search.msn.com. 86400 IN NS ns-puxi.online.sh.cn.
auto.search.msn.com. 86400 IN NS ns-pudong.online.sh.cn.
auto.search.msn.com. 86400 IN NS ns-pd.online.sh.cn.
auto.search.msn.com. 86400 IN NS ns-px.online.sh.cn.
auto.search.msn.com. 86400 IN NS ns-px2.online.sh.cn.
;; ADDITIONAL SECTION:
ns-pd.online.sh.cn. 86400 IN A 202.96.209.133
ns-px.online.sh.cn. 86400 IN A 202.96.209.5
ns-puxi.online.sh.cn. 86400 IN A 202.96.209.5
ns-pudong.online.sh.cn. 86400 IN A 202.96.209.133
;; Query time: 23 msec
;; SERVER: 202.96.209.5#53(202.96.209.5)
;; WHEN: Wed Mar 14 14:51:08 2007
;; MSG SIZE rcvd: 236
可以看到auto.search.msn.com被解析到了218.30.64.194这个IP，这显然是不对的，而本应属于微软的msn域名的NS记录竟然为5个上海热线的域名服务器，很明显猫腻就在这里了。
那我们就顺便查查218.30.64.194这个IP的所有，通过IP whois信息库，查询方法也是通过方便至极的DNSStuff，URL如下：http://www.dnsstuff.com/tools/whois.ch?ip=218.30.64.194，摘录一下结果：
WHOIS results for 218.30.64.194
Generated by www.DNSstuff.com
Location: China [City: Shenzhen, Guangdong]
ARIN says that this IP belongs to APNIC; I’m looking it up there.
% [whois.apnic.net node-2]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 218.30.64.0 - 218.30.64.255
netname: CHINANET-CN
country: CN
descr: Chinavnet
descr: No.31 ,jingrong street,beijing
admin-c: CH93-AP
tech-c: CH93-AP
status: ALLOCATED NON-PORTABLE
changed: *****@chinatelecom.com.cn 20051026
mnt-by: MAINT-CHINANET
source: APNIC
person: Chinanet Hostmaster
nic-hdl: CH93-AP
e-mail: *********@ns.chinanet.cn.net
address: No.31 ,jingrong street,beijing
address: 100032
phone: +86-10-58501724
fax-no: +86-10-58501724
country: CN
changed: *****@chinatelecom.com.cn 20051212
mnt-by: MAINT-CHINANET
source: APNIC
很明显这个IP是中国电信的，而msn的域名就是这样被强奸到了中国电信的IP。
以上就是06年中上海电信所做的手脚了，其实对于如此行为我个人还是可以忍受的，因为第一我不会去装什么星空XXX，即使装了我也有办法不用你的东西。第二我不用MSN的搜索，你劫持了它对我没什么影响。然而，从最近一段时间的异常来看，事情显然已经不只是这个地步了，因为我在用各种浏览器各种搜索引擎的时候都碰到了被转向了114的情况，再加上我个人工作所维护的一些邮件服务器最近发现的怪异情况，我有理由怀疑上海电信在DNS上做了更令人不齿的行为。很不幸，我只是简单测试了一下，就发现确实如此，这次的行为可谓明刀明枪的抢劫了：
C:\>ping notpresentxxxxxxxxxx.cn
Pinging notpresentxxxxxxxxxx.cn [218.83.175.154] with 32 bytes of data:
Reply from 218.83.175.154: bytes=32 time=124ms TTL=242
Reply from 218.83.175.154: bytes=32 time=122ms TTL=242
Reply from 218.83.175.154: bytes=32 time=134ms TTL=242
Reply from 218.83.175.154: bytes=32 time=134ms TTL=242
Ping statistics for 218.83.175.154:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 122ms, Maximum = 134ms, Average = 128ms
C:\>ping dsfsdofhetfowefuwdf.com
Pinging dsfsdofhetfowefuwdf.com [218.83.175.154] with 32 bytes of data:
Reply from 218.83.175.154: bytes=32 time=126ms TTL=242
Reply from 218.83.175.154: bytes=32 time=125ms TTL=242
Reply from 218.83.175.154: bytes=32 time=116ms TTL=242
Reply from 218.83.175.154: bytes=32 time=118ms TTL=242
Ping statistics for 218.83.175.154:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 116ms, Maximum = 126ms, Average = 121ms
C:\>ping gherogfhgnewlffefh.com
Pinging gherogfhgnewlffefh.com [218.83.175.154] with 32 bytes of data:
Reply from 218.83.175.154: bytes=32 time=674ms TTL=242
Reply from 218.83.175.154: bytes=32 time=1007ms TTL=242
Reply from 218.83.175.154: bytes=32 time=1002ms TTL=242
Reply from 218.83.175.154: bytes=32 time=812ms TTL=242
Ping statistics for 218.83.175.154:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 674ms, Maximum = 1007ms, Average = 873ms
相信会用ping命令的网友们自然能看得懂这段输出的意思，简单来说，我ping了3个根本不存在的域名，本应出现找不到域名错误(hostname not found)，然而这显然不存在的3个域名竟然能得到解析结果，而无一例外的指向同一个IP—-218.83.175.154。这个IP是什么我想大家应该也会非常有兴趣知道，点一下看看吧http://218.83.175.154。照样不能忘记把这个IP的whois信息拿出来作证据：http://www.dnsstuff.com/tools/whois.ch?ip=218.83.175.154，顺便贴出来：
WHOIS results for 218.83.175.154
Generated by www.DNSstuff.com
Location: China [City: Shanghai, Shandong]
ARIN says that this IP belongs to APNIC; I’m looking it up there.
% [whois.apnic.net node-1]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 218.78.0.0 - 218.83.255.255
netname: CHINANET-SH
descr: CHINANET Shanghai province network
descr: Data Communication Division
descr: China Telecom
country: CN
admin-c: CH93-AP
tech-c: XI5-AP
mnt-by: APNIC-HM
mnt-lower: MAINT-CHINANET-SH
mnt-routes: MAINT-CHINANET-SH
status: ALLOCATED PORTABLE
changed: **********@apnic.net 20060427
source: APNIC
person: Chinanet Hostmaster
nic-hdl: CH93-AP
e-mail: *********@ns.chinanet.cn.net
address: No.31 ,jingrong street,beijing
address: 100032
phone: +86-10-58501724
fax-no: +86-10-58501724
country: CN
changed: *****@chinatelecom.com.cn 20051212
mnt-by: MAINT-CHINANET
source: APNIC
person: Wu Xiao Li
address: Room 805,61 North Si Chuan Road,Shanghai,200085,PRC
country: CN
phone: +86-21-63630562
fax-no: +86-21-63630566
e-mail: ********@mail.online.sh.cn
nic-hdl: XI5-AP
mnt-by: MAINT-CHINANET-SH
changed: ********@mail.online.sh.cn 20010510
source: APNIC
铁证如山，看你上海电信还如何抵赖，目前我自己发现的出现问题的DNS服务器有202.96.209.5，202.96.209.6，202.96.209.133，202.96.209.134，都为上海电信ADSL的DHCP默认指派的DNS，应该还有数个服务器应该也是类似，只是我没有去求证。
做为中国最大的ISP，发布广告无可厚非，但却打着官方的旗号公然破坏互联网基础设施，公然违反互联网RFC，真可谓给国内各大企业带了个好头，再加上CNNIC的流氓行为，中国互联网还有什么前途？！我作为IT网络业界的一个普通技术人员，对此现状真的感到深深的悲哀。
现在唯一还能让我高兴起来的事情，就是似乎这个转入到114查询的关键字似乎是随机选取的，经常会出现让人哭笑不得的结果，莫非电信的技术们也开始学习玩无厘头风格了？
订阅：
博文 (Atom)
