DNS(三)DNS SEC(域名系统安全扩展)

工作需要今天了解了下DNS SEC,现把相关内容整理如下:

一、DNS SEC 简介

  域名系统安全扩展(英语: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)、DNSKEY (DNS Public Key)、DS (Delegation Signer)详细内容如下

RRSIG (Resource Record Signature)

资源记录签名

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

格式

记录类型

  • 算法类型 (参考附录「算法类型列表」)
  • 标签 (泛解析中原先 RRSIG 记录的名称)
  • 原 TTL 大小
  • 签名失效时间
  • 签名签署时间
  • Key 标签 (一个简短的数值,用来迅速判断应该用那个 DNSKEY 记录来验证)
  • 签名名称 (用于验证该签名的 DNSKEY 名称)
  • 加密签名

 DNS(三)DNS  SEC(域名系统安全扩展)

DNSKEY (DNS Public Key)

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

格式

  • 标识符 (Zone Key (DNSSEC密钥集) 以及 Secure Entry Point (KSK和简单密钥集))
  • 协议 (固定值3 向下兼容)
  • 算法类型 (参考附录「算法类型列表」)
  • 公钥内容

 DNS(三)DNS  SEC(域名系统安全扩展)

DS (Delegation Signer)

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

格式

  • Key 标签 (一个简短的数值,用来迅速判断应该用那个 DNSKEY 记录来验证)
  • 算法类型 (参考附录「算法类型列表」)
  • 摘要类型 (创建摘要值的加密散列算法)(参考附录「摘要类型列表」)
  • Digest: A cryptographic hash value of the referenced DNSKEY-record.

 DNS(三)DNS  SEC(域名系统安全扩展)

NSEC (Next Secure)

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

三、DNS SEC签名过程

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

 DNS(三)DNS  SEC(域名系统安全扩展)

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

 DNS(三)DNS  SEC(域名系统安全扩展)

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

这里用到的就是上面提到的 DS (Delegation Signer) ,DS 的值是从 imlonghao.com 的上一级 com 利用他的私钥对 imlonghao.com 的 DNSKEY 进行加密之后得到的。如果你有疑惑的话,可以拿 com 的公钥进行解密然后比对。如果还是不信的话,可以在去上一级根域名去查,然后通过类似的方法,比对 com 的记录是否正确。查询过程如下图所示:

 DNS(三)DNS  SEC(域名系统安全扩展)

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

 DNS(三)DNS  SEC(域名系统安全扩展)

四、DNSSEC 的现状及问题

无法保证私密性

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

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

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

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

  就目前国内而言,只有 CNNIC 的 4.2.2.4 支持,其他例如 114.114.114.114 以及 223.5.5.5 都不支持

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

附录:

算法类型列表

1: RSA/MD5

2: Diffie-Hellman

3: DSA/SHA-1

4: Elliptic Curve

5: RSA/SHA-1

6: DSA-NSEC3-SHA1

7: RSASHA1-NSEC3-SHA1

8: RSA/SHA-256

10: RSA/SHA-512

12: RSA/SHA-512

13: ECDSA Curve P-256 with SHA-256

14: ECDSA Curve P-384 with SHA-384

252: Indirect

253: Private DNS

254: Private OID

摘要类型列表

1: SHA-1

2: SHA-256

3: GOST R 34.11-94

4: SHA-384

参考:

RFC2535   https://tools.ietf.org/html/rfc2535

我所理解的 DNSSEC  https://imlonghao.com/41.html

DNSSEC原理简析及其实用性分析  https://www.lifetyper.com/2014/07/theory-of-dnssec-and-practical-analyze.html

在线数据包  https://www.cloudshark.org/captures/79e23786259b  

 数据包本地下载

DNS SEC信任链图示svg文件本地下载