May 062010
 

DNS污染作为一个已知的安全问题已经存在了好长时间了。但是一直以来没有十分好的办法来解决这个问题。比较一劳永逸的解决方案是DNSSec,但应用它要求在所有DNS通讯上实现安全协议,实施难度相当于把整个DNS生态重新搭建一遍,因此一直以来没有什么厂商来推动。DNS的安全问题也就一直被睁一只眼闭一只眼地忽略了。

这两天翻文章的时候翻到了ICCAN网站上,发现他们公布的DNSSec实施Timeline已经快到期了:

Planned High Level Timeline

  • December 1, 2009: Root zone signed for internal use by VeriSign and ICANN.  ICANN and VeriSign exercise interaction protocols for signing the ZSK with the KSK.
  • January, 2010: The first root server begins serving the signed root in the form of the DURZ (deliberately unvalidatable root zone). The DURZ contains unusable keys in place of the root KSK and ZSK to prevent these keys being used for validation.
  • Early May, 2010: All root servers are now serving the DURZ.  The effects of the larger responses from the signed root, if any, would now be encountered.
  • May and June, 2010: The deployment results are studied and a final decision to deploy DNSSEC in the root zone is made.
  • July 1, 2010: ICANN publishes the root zone trust anchor and root operators begin to serve the signed root zone with actual keys – The signed root zone is available.

 

根据这个Timeline,在7月1日起,根zone应该就可以承担整个Internet的DNSSec的查询流量。

从今天刚刚发布的这篇文章来看–《Status Update, 2010-05-05》,实施DNSSec的兄弟们已经做好了一个实现准备好的假根Zone — Deliberately Unvalidatable Root Zone (DURZ),然后接下来的时间内观察并研究DNSSec的流量,并决定是否进一步将其推向生产环境。

简单来说,DNSSec已经迫在眉睫了,如果一切顺利的话,我们将在2个月后得到一个安全健壮的DNS系统,届时我们将可以把自己的域名置于安全证书的签名保护下,以免于DNS污染或其他DNS安全问题。讽刺的是,7月1日刚好是某一直致力于阻挠和破坏Internet信息流通的某政党的生日,希望它在当天收到这个礼物的时候表情不会太难看。

Jul 232008
 

这个月出现的一个关于DNS的漏洞已经可以在很多新闻里看到了,然而如以前一样,国内对于类似事件的报道毫无深度,甚至在技术上还存在不少翻译带来的的误读,非常不靠谱。

首先必须要知道的一点是这是DNS解析机制本身的漏洞,并不是单纯某一个产品的问题,因此几乎所有的DNS Server都会受影响。

其次这个漏洞的攻击表现是未经授权地篡改某些DNS解析出来的地址结果,其最终目的是诱使客户在没有意识到的情况下访问到黑客精心布置的页面,从而达到其目的。也就是说此漏洞影响的不仅仅是DNS Server,域名或网站运营者,还有所有的访问互联网的人。

早些时候的讨论,仅仅认为这是个比较难以利用的潜在漏洞,但从这几个月的形式来看,漏洞被成功利用的几率在精心构建的攻击行为下大大增加,甚至就在昨天,被证明是有效的漏洞利用方式的细节已经在小范围内传播了。据发布者预测,应该就在今天,将会有确实的攻击行为出现。对细节感兴趣的可以看这里

即将产生的破坏究竟有多大,是很难估量的,但至少可以确认,将会有很多客户的敏感资料遭受威胁。对于整个互联网DNS体系,从来没有像这样一次如此大规模的影响事件,同时考虑到互联网整体对于DNS安全的重视程度还远远未如Web安全那样高,接下来应该会有比较长时间的动荡期。国内在这方面尤为落后,恐怕会在接近半年的时间内,将会出现很多帐号盗窃,流量注入,甚至域名劫持之类的事件出现。

要将此漏洞完全解决,必须是互联网上所有解析服务器和缓存服务器都做好相应升级之后才可能,对于DNS Server管理员,要做的就是尽快将自己手头的Server补丁打好。而对于普通互联网使用者,在这段期间内所能做的,就是尽量选择可靠的DNS服务器。考虑到国内电信等ISP的技术能力和响应速度,恐怕比较靠谱的临时解决放案是使用本地架设的DNS缓存服务器或者使用已经证实不存在问题的服务器,例如OpenDNS。

这就像是一场瘟疫,光自己做好防护还不够,至少要你周围的人都可信才行。

但愿我过于悲观地预测了这次事故造成的影响。

Sep 062007
 

今天碰到了一个DNS解析记录总是不生效的troubleshooting案例,故障现象很诡异,有部分解析记录是完全没有问题的,而有部分则完全不生效。通过dig诊断来看就好像根本不存在这几条记录一样,而这几条记录又是确确实实地写在了zone file里。

正在莫名其妙的时候,发现log里在加载这个zone的时候有这样一条日志:loading master file /var/named/xxxxxx.zone: CNAME and other data。

还有一条标明了行号,于是检查,发现在此行配置了一条MX记录,同时下面还有一行是同一子域名配置了一条CNAME记录。于是怀疑对于同一子域名不能同时存在这两种记录,删除其MX,reload发现没有日志出现。再dig,发现先前解析不出来的记录都恢复正常。

然后回顾了一下,认为我这个推断是正确的。因为CNAME本身就是将子域名委派至其他DNS服务器解析管理,此时其自身配置的A与MX应当失效,所以不应该存在此类记录才对。BIND在此应该是拒绝zone file里同时写了同一子域名的CNAME与其他记录。

再想了一下,刚才故障中正常的解析都是位于此条之上的记录,失败的都是位于之下,说明BIND在加载zone的时候是按照配置文件逐条读入,碰到失败则放弃之下的所有内容,所以才有此奇特的故障现象。

后经测试,有CNAME存在时,确实A和MX都不能建立,否则报错,NS倒是可以,但是不起作用。

看来有空还是要好好研读RFC,一些细节方面的东西不能忽视。

Jun 012007
 

前几个月,在下穷极无聊写了篇文章《上海电信DNS劫持事件》,本意并未有向电信开炮的意思,怎料文章投递到cnbeta以后,引来无数人响应,一时间貌似全国都有人发现“劫持”,包括网通,铁通等ISP的类似行为都被曝光,甚至某些本来是由于某些低级失误造成的问题都被归于此类,自此大家又多了一条批判运营商的罪状–“劫持”。后经过各大网络媒体大肆炒作,影响甚众,果然现在还是靠骂人出名最快捷,矛头指向垄断企业才是个性,跟专家对着干才叫水平。事事如此,人人如此,也难怪网民们动不动就骂,所有业界文章,如果没有反对意见,那还真是另类了。

Continue reading »

Mar 142007
 

  使用上海电信宽带接入的朋友可能最近也经常像我一样在浏览网站时莫名其妙地输入网址后转向了114查询的页面,此类事故在以前曾听过有类似的传言,而以前我个人并未碰到,所以并不在意,但如今我是天天被114这个破烂页面骚扰,于是也不得不仔细找找原因了。
Continue reading »