启迪云-高级开发工程师 王文翔 | 文

背景

域名系统(DNS)是一个为连接到互联网或者私有网路的计算机，服务或者其它资源提供命名服务的层级化的分散式系统。自从1985年以来，DNS做为互联网中一个重要组成部分，已经被广泛被使用，同时DNS做为一种标准协议，处于TCP/IP的应用层。当前全球域名由ICANN统一进行协调，国家或者域名提供商从ICANN申请到顶级域名后，再面向企事业，个人或组织开放注册。

DNS在当前互联网大环境中无处不在，网页浏览，电子邮件，手机APP应用以及域名系统本身，几乎所有互联网应用和服务通信都离不开域名系统。当你打开浏览器访问网页或者开发客户端程序调用如gethostbyname()之类的函数时，就会由操作系统中解析器(Resolver)进行递归解析，解析器通常先去查找系统中的hosts文件；如果没有命中，则会根据系统默认DNS配置(如Linux下的resolv.conf文件)，向指定的ISP发送DNS查询请求，由ISP的解析器进行递归解析，如此递归下去，最终由域名系统中某个Authoritative Server再原路返回DNS应答。当然主流的浏览器如Chrome和Firefox都已自己实现了Resolver功能，实现对DNS协议更多的控制。

DNS简介

域名服务提供了一种易于记住的名字而非一串IP地址来定位伺服器和网路资源，同时在域名之后可以绑定多个IP地址来进行资源均衡，而且当你通过域名提供服务时，可以随时更新已绑定的IP地址(当然没事不会更改IP地址，而且域名还有TTL时效) ，而不用动应用服务。

根域名

DNS是一种分层结构，在整个互联网中组成一个树状系统，顶层是系统的根域名，下层为TLD以及二级域名，叶子就构成了所谓的FQDN（Fully Qualified Domain Names），根域名通常使用"."来表示，其实际上也是由域名组成，全世界目前有13组域名根节点，由少数几个国家进行管理，而国内仅有几台根节点镜像。

root伺服器列表

DNS三种查询类型

1. Recursive：仅返回应答，DNS Server可以不用支持Recursive查询模式。

2. Iterative：返回完整应答或者将请求引到其它DNS，所有DNS server都支持Iterative查询模式。

3. Inverse：通过Resource记录查找域名，已经被弃用(RFC 3425)；

DNS迭代模式

实现迭代模式的DNS解析器过程如下图所示。

  • DNS Iterator收到查询域名wikipedia.org的请求，向13个根域名中的一个发送FQDN查询请求，Root伺服器不能解析FQDN，但是知道org.域名所在域名伺服器，所以让DNS Iterator向org.域名伺服器发送FQDN请求；
  • org.域名伺服器知道FQDN所在域名伺服器，所以再次让DNS Iterator向wikipedia.org.所在域名伺服器发送FQDN请求；
  • 最后wikipedia.org.域名伺服器收到FQDN查询请求，将wikipedia.org对应的A记录返回给DNS Iterator；

DNSSec

DNS做为互联网早期产物，使用无连接的UDP协议虽然降低了开销也保证了高效的通信，但是没有考虑安全问题。由于DNS使用目的埠为53的UDP明文进行通信，DNS解析器识别是自己发出的数据包的唯一标准就是随机的源埠号，如果埠号匹配则认为是正确回复，而不会验证来源。所以也带来了许多DNS安全问题，如DNS欺骗，DNS Cache污染，DNS放大攻击等。

针对DNS安全问题，业界提出了DNSSec(Domain Name System Security Extensions，也叫"DNS安全扩展")机制，使用密码学方法解决DNS安全问题，让客户端对域名来源身份进行验证，并且检查来自DNS域名伺服器应答记录的完整性，以及验证是否在传输过程中被篡改过，但不保障DNS数据加密性和可用性。

DNSSec依赖公私钥认证和数字签名体系，主要解决如下问题：

1. 身份来源验证：验证DNS应答是由真正的DNS server返回。

2. 完整性验证：保证DNS应答的完整性，在网路传输中没有被篡改和丢失。

3. 否定存在验证：如果DNS返回域名不存在的响应状态，此响应可以被证实是来自Authoritative Server；

DNSSec使用

如果你的DNS Server使用的是bind软体搭建，设置DNSSec只需要简单几步配置即可。

1. 启用dnssec和验证

dnssec-enable yes;

dnssec-validation yes;

dnssec-lookaside auto;

2. 生成密钥

dnssec-keygen -a RSASHA1 -r /dev/urandom -b 1024-n ZONE dnssec.

dnssec-keygen -f KSK -a RSASHA1 -r /dev/urandom -b 1024-n ZONE dnssec.

执行完成后生成4个密钥：

Kdnssec.+005+35877.key

Kdnssec.+005+35877.private

Kdnssec.+005+56527.key

Kdnssec.+005+56527.private

3.签名

* 首先将生成的2个公钥添加到时区域文件末尾

$INCLUDE "/var/named/dnssec/Kdnssec.+005+35877.key"

$INCLUDE "/var/named/dnssec/Kdnssec.+005+56527.key"

* 其次对区域文件签名：

dnssec-signzone -o dnnsec. dnssec.zone

* 将签名生成的.signed文件替换原始zone file:

zone "dnssec" IN {

type master;

//file "dnssec.zone";

file "dnssec.zone.signed";

};

4.生成信任锚

将之前生成的两个公钥复制到trust-anchors.conf文件中：

trusted-keys {

dnnsec. 257 3 5 "AwEAAb1Fwju0TbhQmKfeXNyrP5Ly1Irf1PLOiQf98YPIchBCQFB4muL7 IN8rJCvTClo1Ubr/XC8eurA/PE1hZ8hGw3E=";

dnssec. 256 3 5 "AwEAAdxfMpf3/rPbOyRxQZOGeCe98THhR28Ro369mjqVeGvzHQU6aHX8 Pt03rZiRhYHt/aCzHHwYCUH7Gv7OKp+xvts=";

};

同时将文件包含到named.conf中：

include "/etc/named.trust-anchors.conf";

DNSSec验证流程

  • 普通DNS查询过程：

客户端发送域名verisign.com的查询请求，ISP或者Recursive DNS伺服器收到客户端发送的查询请求，检查本地Cache中是否存在verisign.com的A Record，如果域名没有被查询过或者到达TTL时间，就向任意一个root伺服器发送请示，root节点中只保存了TLD的zone，所以root将.com域名的NS记录返回给ISP，让ISP去.com的域名伺服器去查询，ISP则再次向TLD所在域名伺服器发送verisign.com的查询请求，此时.com域名伺服器会查询所有zone记录，如果查找到verisign.com，就向ISP返回所有verisign.com的A Record，而verisign.com作为一条CNAME Record也会一起返回，ISP收到应答后，将verisign.com的应答结果缓存在Cache，同时将结果返回给客户端，客户端也会缓存TTL时间。

  • DNSSec验证过程

当打开DNSSec验证后，验证解析器(validating resolver)在DNS查询时附带额外查询记录，让远程权威伺服器返回更多响应，如果验证解析器收到带有DNSSec的应答，则会执行签名验证和结果完整性，甚至向父域名伺服器发送验证请求。经过反复执行获取public key，签名验证，请求父节点，直至得到一个可信密钥(root key)。

1. 验证解析器收到客户端查询isc.org的DNS查询请求，通过上面的迭代过程由isc.org域名伺服器返回isc.org的A记录。如果验证解析器DNSSec功能是打开著，则希望收到DNSSec的应答；

2.如果isc.org域名伺服器打开DNSSec，响应的结果中除了A记录，还会有签名信息，否则后续不进行DNSSec验证；

3. 验证解析器此时需要验证数据签名，需要一个key，所以会向isc.org域名伺服器询问key；

4.isc.org域名伺服器返回key后，验证解析器使用key验证步骤2中返回的签名信息；

5.验证解析器询问父域名伺服器(.org)关于子域名(isc.org)的验证信息；

6.父域名伺服器(.org)返回验证信息后，验证解析器比较步骤4的结果，验证isc.org的真实性；

7.验证解析器询问.org域名伺服器的key，用来验证步骤6的应答结果；

8..org域名伺服器返回key和签名，验证解析器就可以验证步骤6的应答结果；

9.验证解析器询问父域名伺服器(root)关于子域名(.org)的验证信息；

10.Root域名伺服器返回存储.org的验证信息，验证解析器使用root返回的验证信息验证步骤8的应答结果；

11.验证解析器询问root域名伺服器的key，用来验证步骤10的应答信息；

12.Root域名伺服器返回key，验证解析器就可以验证步骤10的应答结果；

DNSSec验证方式

要想使用DNSSec，必须满足域名和解析伺服器同时支持DNSSec，否则不会返回签名信息，请求端也就不会进行验证。

1. 基于web的工具

通过一些提供DNS验证的网站，可以很简单的检查递归域名伺服器是否支持DNSSec。

en.conn.internet.nl/con

2. dig工具来

dig是一个非常丰富的DNS查询工具，通过+dnssec参数可以验证域名伺服器和域名是否支持DNSSec。

使用国外的DNS解析，如：8.8.8.8/8.8.4.4，查询域名cam.ac.uk是否支持DNSSec。由于8.8.8.8/8.8.4.4域名伺服器和域名cam.ac.uk都已经支持了DNSSec，所以返回的结果中会带有DNSSec的签名记录RRSIG。

```

$ dig @8.8.8.8 cam.ac.uk A +dnssec

; <<>> DiG 9.10.6 <<>> @8.8.8.8 cam.ac.uk A +dnssec

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43832

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags: do; udp: 512

;; QUESTION SECTION:

;www.cam.ac.uk. IN A

;; ANSWER SECTION:

www.cam.ac.uk. 921 IN A 128.232.132.8

www.cam.ac.uk. 921 IN RRSIG A 5 4 3600 20181228064308 20181218055055 17997 cam.ac.uk. evjK2FsLnhLetuWcJFXqZzNuYRFeFo5+I0SzYD3htuWDpkMwfPlG4T+3

osufjdlV6ROZfqlOCRt2nUtwDaVNp9q1M/gGQpJUDlSry1vcdBmRr0Cp BXw8pPM+7oxDCvwsr+4640Ln+oValPfw+yb7PqneAuZ1RA==

;; Query time: 64 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)

;; WHEN: Tue Dec 18 21:13:07 CST 2018

;; MSG SIZE rcvd: 217

```

使用国内DNS解析，如114.114.114.114/114.114.115.115，同样查询域名cam.ac.uk是否支持DNSSec。由于114.114.114.114/114.114.115.115域名伺服器不支持DNSSec，所以查询cam.ac.uk返回的结果中没有DNSSec的签名记录RRSIG。

```

$ dig @114.114.114.114 cam.ac.uk A +dnssec

; <<>> DiG 9.10.6 <<>> @114.114.114.114 cam.ac.uk A +dnssec

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18840

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;www.cam.ac.uk. IN A

;; ANSWER SECTION:

www.cam.ac.uk. 500 IN A 128.232.132.8

;; Query time: 29 msec

;; SERVER: 114.28.232.132.8

114.114.114#53(114.114.114.114)

;; WHEN: Tue Dec 18 21:33:06 CST 2018

;; MSG SIZE rcvd: 58

```

此外，可以继续测试使用支持DNSSec的DNS解析不支持DNSSec的域名，结果也是不返回签名信息。

3. Wireshark抓包工具

EDNS

普通的DNS响应数据包通常较小(小于512 bytes)，非常适用UDP进行传输。而ENDS(Extension Mechanisms for DNS)则允许通过UDP传输DNS大包，不过为了支持EDNS，DNS Server和防火墙需要支持大数据包的传输和数据包分片。如果DNS Server不支持传输UDP大包，也可以通过TCP进行转发或者丢弃UDP大包。大多数DNS提供商或者开源DNS系统都默认开始了EDNS。

小结

DNSSec为域名系统提供了一种安全增强方式，对域名来源身份，完整性以及是否在传输过程中被篡改过提供验证机制，但不保障DNS数据加密性和可用性。与此同时，虽然DNSSec提供了可信的安全DNS通信，但是DNSSec还是没有被整个域名体系完全支持，主要原因是域名系统过于庞大，从根到TLD，再到子域名，不能保证所有节点都支持DNSSec，所以DNSSec实现兼容现有域名系统，在DNS不支持DNSSec时会自动跳过DNSSec请求和验证。


推荐阅读：
相关文章