我所理解的 DNSSEC

为什么会有 DNSSEC

起初，DNS (Domain Name System) 在设计上面并没有过多的去考虑安全的问题，也没有去考虑解析结果会不会被挟持的问题。当时的网络环境比较良好、安全，况且能接入互联网的人数并不多。但是随着科技的日益发展，接入互联网的人数也越来越多，网络环境也开始变得复杂起来，一些不怀好意的人出于经济目的抑或是政治目的，对互联网实施各种的挟持攻击，其中就包括了 DNS 的挟持。

众所周知，通用情况下用户与 DNS 服务器之间采用 UDP (用户数据报协议) 进行通讯。 UDP 并不像 TCP 那样有三次握手，也没有结束时候的握手，这在一定程度上面给解析带来的效率，但是这却留下了安全隐患。DNS 通讯时使用明文通讯，这就意味着中间设备都可以轻松地抓到你的 DNS 请求以及回复，也可以轻松地对此进行修改，伪造一份来自 DNS 服务器的查询结果（因为 UDP 协议的天性），并且将正确结果的包给 DROP 掉，这样用户就到达不了他真正想去的网站了。

拿 www.youtube.com 为例子，这在中国大陆遭到了 DNS 的挟持。

; <<>> DiG 9.10.3-P4 <<>> www.youtube.com @114.114.114.114
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60093
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.youtube.com.               IN      A

;; ANSWER SECTION:
www.youtube.com.        3600    IN      CNAME   youtube-ui.l.google.com.
youtube-ui.l.google.com. 3600   IN      CNAME   youtube-ui-china.l.google.com.
youtube-ui-china.l.google.com. 3600 IN  A       37.61.54.158

;; AUTHORITY SECTION:
google.com.             156232  IN      NS      ns4.google.com.
google.com.             156232  IN      NS      ns1.google.com.
google.com.             156232  IN      NS      ns3.google.com.
google.com.             156232  IN      NS      ns2.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.         239134  IN      A       216.239.32.10
ns2.google.com.         332181  IN      A       216.239.34.10
ns3.google.com.         156232  IN      A       216.239.36.10
ns4.google.com.         341604  IN      A       216.239.38.10

;; Query time: 3 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Mon Mar 28 01:10:54 CST 2016
;; MSG SIZE  rcvd: 250

可以看到我们这里选取的 DNS 服务器 114.114.114.114 给我们返回的结果是 37.61.54.158 。而这个 IP 地址，并不属于谷歌公司，而且我们也打不开这个 IP，所以我们保持这个 DNS 不变的情况下就是永远也打不开 www.youtube.com

而正确的解析结果是这样的，我这里使用了 dnscrypt

; <<>> DiG 9.10.3-P4 <<>> www.youtube.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32584
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.youtube.com.               IN      A

;; ANSWER SECTION:
www.youtube.com.        21593   IN      CNAME   youtube-ui.l.google.com.
youtube-ui.l.google.com. 293    IN      A       216.58.197.110

;; Query time: 123 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Mar 28 01:25:30 CST 2016
;; MSG SIZE  rcvd: 94

而这里的 216.58.197.110 才是我们真正想要的地址

DNSSEC 简介

域名系统安全扩展（英语：Domain Name System Security Extensions，缩写为 DNSSEC）是 Internet 工程任务组 （IETF）的对确保由域名系统 （DNS）中提供的关于互联网协议 （IP）网络使用特定类型的信息规格套件。它是对 DNS 提供给 DNS 客户端（解析器）的 DNS 数据来源进行认证，并验证不存在性和校验数据完整性验证，但不提供或机密性和可用性。—— 域名系统安全扩展 - 维基百科，自由的百科全书

简单来说，DNSSEC 就是一个对现有 DNS 协议进行安全完善的拓展。他在现有的 DNS 协议的基础上，增加了几个新的资源记录来达到这个目的。

DNSSEC 正式来说最早可以追溯到 RFC 2535，1999 年 3 月来自 IBM 的工程师 D. Eastlake 提出了这个提案，不过要说到真正的实施部署，也是最近几年才开始的。2010 年 7 月 18 日，根域名解析服务器才完成了 DNSSEC 的部署。

DNSSEC 新增的资源记录

这里所指的资源记录类似于我们现有的 A记录、CNAME记录以及TXT记录。

RRSIG (Resource Record Signature)

资源记录签名

该记录用于存放我们当前域名每一条记录的 DNSSEC 签名

格式

例子

imlonghao.com.          3599    IN      RRSIG   A 14 2 3600 20160407000000 20160317000000 2339 imlonghao.com. R3vssiq95v4oBlgj3SU2X8tBV1OMVezc+zRnxpxcJDzZ9mJ9DYCZYrUd Y/I+0vBnJAXJeLnv+GwrLxDHADRrhofpwXfiVwv/Tvu5H+/k1yg0CPut 2ivTU++y40IznBXB

DNSKEY (DNS Public Key)

该记录用于存放我们用于检查 DNSSEC 签名的公钥

格式

例子

imlonghao.com.          3599    IN      DNSKEY  256 3 14 aSBB9KXOnB0j/mzhRW4l0U77yOTHFDnV9LI+0vlf8w/PJLx2VIgcXp5H JMQjxJNfCvoOSt9YiyBxnsznmN5wcDO4tX2403mQ7Noub0Jdr0iP+0wP WZUjJ3rZzTcdWavB

DS (Delegation Signer)

该记录用于存放 DNSSEC 公钥的散列值

格式

例子

imlonghao.com.          21599   IN      DS      239 14 2 8E680C746C5EC9504ED9EF1AB49C6733A8335DCB6415D7BEBB7E415B AA0CD2BB

NSEC (Next Secure)

用于验证不存在的资源记录

DNSSEC 的签名过程

假如我要请求 imlonghao.com 所对应的 IP 地址，那么我肯定就是先会去向 DNS 服务器发出我的请求，我用 dig 命令模拟了一次请求。

; <<>> DiG 9.10.3-P4 <<>> imlonghao.com +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55040
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;imlonghao.com.                 IN      A

;; ANSWER SECTION:
imlonghao.com.          3599    IN      A       103.200.115.121
imlonghao.com.          3599    IN      RRSIG   A 14 2 3600 20160407000000 20160317000000 2339 imlonghao.com. dWYrDxufVpq1Xdx4XK90CXLfgfAPWgJvYq1lL73JLP9yx7XZ9diI+5nr pe6mFN/7soIg/tTiF6R1ciGvs8W3H5+mXq+DLzaJuT2bNQP7lFzNpAbw XCxco6xJqzVFZxDA

;; Query time: 646 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Mar 28 16:31:20 CST 2016
;; MSG SIZE  rcvd: 199

在这次的请求当中，我们可以看到服务器给我们返回了两条记录，一条是 A记录 另一条是 RRSIG 记录。A记录 就是我们想要的结果，而 RRSIG记录 正如上面所讲的，就是 DNS 权威服务器对这个解析结果的一个数字签名。DNS 权威服务器有向对应的私钥，他的作用就是用来对 DNS 请求结果进行数字签名生成数字摘要，然后原先的记录以及这条信息摘要就会一同发送给我们。

那么，如何判断我们拿到的结果并没有被污染呢，我们就可以通过请求 DNSKEY 来获取对应的公开密钥。拿到了公开密钥之后，我们可以用他先来解密 RRSIG 的摘要，然后我们利用相同的散列算法在算一次摘要，然后将 RRSIG 的摘要和自己算出来的摘要进行比对，如果相同的话就说明这次查询结果是可信的。

再那么，你也许会问，为什么挟持者不把 RRSIG 以及 DNSKEY 记录也给污染了呢？这就涉及到了信任的问题。

这里用到的就是上面提到的 DS (Delegation Signer) ，DS 的值是从 imlonghao.com 的上一级 com 利用他的私钥对 imlonghao.com 的 DNSKEY 进行加密之后得到的。如果你有疑惑的话，可以拿 com 的公钥进行解密然后比对。

如果还是不信的话，可以在去上一级根域名去查，然后通过类似的方法，比对 com 的记录是否正确

下图是通过 DNSViz 生成的 DNSSEC 信任链

DNSSEC 的现状及问题

无法保证私密性

DNSSEC 并没有改变 DNS 基于 UDP 的通讯方式，数据流也都是明文传输，他所做的只是加上了一个数字签名，而中间人依然可以看到你请求了什么、结果是什么

挟持发生时不能告诉用户真正的记录

当用户的 DNS 被挟持的时候，用户通过检查 DNSSEC 签名，可以知道自己得到的并不是真正的解析结果，而是得到了一个被伪造的地址。但是，用户并不知道真正的解析结果是什么。

支持 DNSSEC 的递归服务器并不多

就目前国内而言，例如 114.114.114.114 以及 223.5.5.5 都不支持

而国外的话，谷歌在 2013 年 5 月 6 号宣布其公共 DNS 服务器 8.8.8.8 以及 8.8.4.4 支持 DNSSEC。

主流浏览器并没有原生对 DNSSEC 的支持

Chrome

早在 14.0.794.0 的时候，Chrome 默认就启用了 DNSSEC 的检查，当时是这样子的

而后来，因为缺少使用因此该功能被删除

Update: this has been removed from Chrome due to lack of use.

详情请看：DNSSEC authenticated HTTPS in Chrome (16 Jun 2011)

Firefox

目前同样没有原生支持，和 Chrome 需要安装拓展才可以使用。

有兴趣的话可以看这里的讨论：Bug 672600 - Use DNSSEC/DANE chain stapled into TLS handshake in certificate chain validation

更多

Against DNSSEC - Quarrelsome

附录

算法类型列表

摘要类型列表

参考资料

Simple DNS Plus

什么是 DNSSEC？DNSSEC 的概念及作用 - CloudXNS

LifeTyper - DNSSEC 原理简析及其实用性分析