从google DNS开始支持DNSSEC说说DNSSEC

Google的公共DNS服务器(IPv4的地址是8.8.8.8/8.8.4.4)开始支持DNSSEC了,给DNSSEC的发展加了一把油。新闻来源在这里

先从简单易上手的说起,为chrome或者firefox下载一个插件,插件的目的首先是发送dnssec的dns请求,最后verify返回的dns地址是否是签名正确的。这里以Chrome为例,插件名为“DNSSEC Validator”,下载地址在这里

插件安装成功以后,要使得dnssec成功被检验,还需要满足2个条件,你访问的域名已经启用了dnssec(注册商和托管解析商都必须支持),你使用的local dns server启用了dnssec。第一个很好满足,第二个可以使用刚才装的插件来简单的解决。

chrome-dnssec-validator-options-1

在插件的option里面,使用第二个或者第三个dns解析,当然现在google的支持了,你选择第四个,填入8.8.8.8也可以。(如果你要去你的网卡属性里面更改dns server设置也没人拦着你,呵呵。)

最后访问一下“http://www.internetsociety.org/deploy360/”试试看。这个域名启用了dnssec。你就会在chrome的地址框右边发现一个绿色的钥匙标记。就表示放心使用dns解析出来的结果把。在DNSSEC Validator的下载页面上还有其他不同颜色标记,红色可是有问题的网站,访问这个“http://www.dnssec-failed.org/”试试看。

chrome-dnssec-validator-success

比较奇怪的是Mac OS下chrome显示有问题,Firefox正常。还没有找到原因,可能是chrome版本问题吧。

好吧,言归正传,讲讲DNS和DNSSEC的原理

DNS查询分递归(recursion)和迭代(iterative)两种,一般来讲client和dns server之间是递归查询,也就是你帮我解析出IP地址;而dns server之间就是迭代查询了,比如root服务器接到local dns server的.com查询,会返回“你去找A服务器”,随后local dns server会找A服务器,然后A返回“litouch.com查询你去找B服务器”。

通常local dns server都enable了递归查询,否则客户端就得自己去一个个迭代了,dns查询量太大。下面是一个完整的没有任何cache情况下的DNS解析示意图。

dns-recrussion

但是由于dns的设计,比如采用UDP协议,导致了很多受攻击的可能,尤其是启用了递归查询的dns解析服务器。常见的攻击包括DNS cache poisoning和DOS。参考这里。下面是一个dns攻击示意图,攻击者冒充权威DNS server返回给local DNS server假的解析IP。

dns attack

为此ICANN针对这些漏洞对DNS在已有协议不影响的情况下做了增强,这就是DNS Security Extensions (DNSSEC)。DNSSEC引入了数字签名。下图看看:

dnssec chain of trust

大概的过程是,根增加KSK(long term key),KSK签名ZSK(short term key),然后ZSK为root下面的所有第一级域名(比如.com)签名,由于.com DS记录包含在.com中,所以也就相当于root给.com的DR签名了。而DS记录对应的是KSK key,于是乎,.com又给litouch.com的DS签名了。这样就形成了一条完整的信任链。

实际操作中,比如我litouch.com是在godaddy.com申请的,但是又另外在dnspod.cn做解析。那么我在dnspod那里配置启用dnssec,生成DS key,然后把这个DS key导入到godaddy的DS记录中。其实也间接说明了,要使DNSSEC工作,每一个DNS工作的环节都必须启用和配置。否则信任链就无法建立。

还需要详细了解的,可以好好看看下面2个地方。

DNSSEC的原理,配置与部署 – 段海新

DNSSEC – A Review By Geoff Huston

发表回复