📖 前言：DNS是因特网运行的最重要的基础设施，因此也成为黑客的最主要攻击目标。DNS通信双方由于缺乏数据来源真实性和完整性的认证机制，系统无法确认数据发送方是否是合法的发送方，也无法验证数据报是否被篡改，攻击者很容易实现源地址和数据内容的欺骗，由此引发越来越多的网络安全问题。本篇首先简要介绍DNS的基本内容，然后详细分析DNS面临的安全威胁，最后介绍DNS安全扩展 DNSSEC。
目录
- [🕒 1. DNS面临的安全威胁](#🕒 1. DNS面临的安全威胁)
-
- [🕘 1.1 协议脆弱性](#🕘 1.1 协议脆弱性)
- [🕘 1.2 实现脆弱性](#🕘 1.2 实现脆弱性)
- [🕘 1.3 操作脆弱性](#🕘 1.3 操作脆弱性)
- [🕒 2. DNSSEC](#🕒 2. DNSSEC)
-
- [🕘 2.1 原理](#🕘 2.1 原理)
- [🕘 2.2 资源记录](#🕘 2.2 资源记录)
-
- [🕤 2.2.1 DNSKEY](#🕤 2.2.1 DNSKEY)
- [🕤 2.2.2 RRSIG](#🕤 2.2.2 RRSIG)
- [🕤 2.2.3 NSEC](#🕤 2.2.3 NSEC)
- [🕤 2.2.4 DS](#🕤 2.2.4 DS)
- [🕘 2.3 DNSSEC对DNS协议的修改](#🕘 2.3 DNSSEC对DNS协议的修改)
- [🕘 2.4 DNSSEC递归解析过程](#🕘 2.4 DNSSEC递归解析过程)
- [🕘 2.5 DNSSEC安全性分析](#🕘 2.5 DNSSEC安全性分析)
- [🕒 3. DNSSEC部署](#🕒 3. DNSSEC部署)
🕒 1. DNS面临的安全威胁
预备知识：
🔎 【网络协议详解】------DNS系统协议（学习笔记）
除了域名解析外，现代DNS还具有：
- 应用层路由：DNS把用户的访问指向离用户最近的那个CDN服务器节点，负载均衡；Email服务器利用DNS服务器中的MX记录作为路由，找到企业内部真正的服务器
- DNS作为信任的基础：防伪造邮件、域名作为验证证书申请者身份的信任基础
- DNS作为PKI：防止CA在未经网站所有者授权的前提下签发非法的证书
🕘 1.1 协议脆弱性
域名欺骗：域名系统（包括 DNS 服务器和解析器）接收或使用来自未授权主机的不正确信息，包含事务 ID 欺骗和缓存投毒。
DNS缓存：
网络通信攻击：针对 DNS 的网络通信攻击主要是DDoS攻击、恶意网址重定向和中间人(man-in-the-middle, MITM)攻击
劫持解析路径，并伪装成指定的DNS应答：
🔎 【PPT分享】清华大学刘保君------谁劫持了我的DNS：全球域名解析路径劫持测量与分析
🕘 1.2 实现脆弱性
DNS 软件，BIND 的漏洞和缺陷无疑会给 DNS 系统带来严重的威胁，其缓冲区溢出漏洞一度占据 UNIX 及 Linux 操作系统相关安全隐患的首位。
🔎 国家漏洞库CNNVD：关于Dnsmasq多个缓冲区错误漏洞的通报
🕘 1.3 操作脆弱性
由于人为操作或配置错误所带来的安全隐患：域名配置攻击、域名注册攻击和信息泄漏等
攻击目标网站域名注册服务提供商→修改目标网站域名记录→申请网站证书→伪装成目标网站
🔎 域名注册商GoDaddy客服被钓鱼攻击，多家公司域名解析被篡改
Q：如果美国在根域名服务器上把中国域名给封了，中国会从网络上消失吗？
A：不会。尽管IPv4的根域名服务器中有1个主根和9个副根在美国，但中国已经部署了28个根镜像，这些镜像的功能等同于根服务器，但它们共享13个IP。这意味着，中国境内对根的访问，最终会落到境内的那些根镜像上。因此，即使美国更改了根区的文件，中国仍可以选择不同步关于.cn的修改，这样一来，除了中国人自己，其他国家将无法访问.cn的网站，但中国的网络并不会瘫痪。此外，中国部署了4台IPv6根域名服务器。打破垄断、突破封锁，中国彻底打破了没有根服务器的困境。
🕒 2. DNSSEC
域名欺骗、恶意网址重定向和中间人攻击之所以能够成功，是因为DNS 解析的请求者无法验证它所收到的应答信息的真实性和完整性。为应对上述安全威胁，IETF提出了DNS安全扩展协议（DNSSEC）。
DNSSEC基本思想：
- 依赖于数字签名和公钥系统去保护 DNS 数据的可信性和完整性：权威域名服务器用自身的私钥来签名资源记录，然后解析服务器用权威域名服务器的公钥来认证来自权威域名服务器的数据，如果认证成功，则表明接收到的数据确实来自权威域名服务器，则解析服务器接收数据，如果认证失败，则表明接收到的数据很可能是伪造的，则解析服务器抛弃数据
- 尽管DNSSEC的原理比较简单，但其标准的制定和部署面临着巨大的挑战：域名软件之父保罗·维克多（Paul Vixie）的曲折经历
🔎 【PPT分享】清华大学郑晓峰： 端到端安全协议的威胁、演进和部署
🕘 2.1 原理
DNSSEC可以防止针对DNS系统的缓存投毒，以得到广泛支持的RFC4033-4035版本为例简要介绍DNSSEC的基本内容
- 提供数据来源验证：DNS数据来自正确的域名服务器；
- 提供数据完整性验证：数据在传输过程中没有任何更改；
- 提供否定存在验证：对否定应答报文提供验证信息
🕘 2.2 资源记录
DNSSEC中新增的四种类型的资源记录：DNSKEY (DNS Public Key)、RRSIG（Resource Record Signature）、DS (Delegation Signer)、NSEC (Next Secure)
🕤 2.2.1 DNSKEY
DNSKEY：存储服务器的公开密钥
例子中的前4个文本字段指定记录所有者名称（owner）为exmaple.com，TTL值为86400，DNS记录类别(class)为IN，表示该条记录是Internet类资源记录，资源记录类型（RR Type）此处为DNSKEY。标志字段的值为256，表示区密钥标志位为1。协议字段值是固定的值3。算法字段为5，表示使用的是RSA/SHA-1算法。括号中的字符串是Base64编码的RSA/SHA-1算法公钥
在 DNSSEC的实践中，权威域的管理员通常用两对密钥配合完成对区数据的签名
- 第一对密钥用来对区内的DNS资源记录进行签名，称为区签名密钥（Zone Signing Key, ZSK），由权威认证服务器生成、签名。
- 另一对称为密钥签名密钥（Key Signing Key, KSK）的公私钥对，用来对包含密钥（如 ZSK）的资源记录（DNSKEY）进行签名，并将签名结果放在DNSKEY的RRSIG记录中
DNSSEC信任根信息可以查IANA的网站（https://www.iana.org/dnssec/files）
🕤 2.2.2 RRSIG
域名服务器中的资源记录（Resource Record，RR）包含和域名相关的各项数据，资源记录包含很多种类，但常用的是Internet类（IN类），这种类包含多种不同的数据类型。
| 类型 | 描述 |
|---|---|
| SOA | 开始授权 |
| A | 由域名获得IPv4地址记录 |
| AAAA | 由域名获得IPv6地址记录 |
| MX | 域内邮件服务器地址记录 |
| NS | 域内权威域名服务器地址记录 |
| CNAME | 查询规范名称 |
RRSIG：存储对资源记录集合（RR Sets）的数字签名
例子中的前4个文本字段指定记录所有者名称为host.exmaple.com，TTL值为86400，DNS记录类别(class)为IN，资源记录类型（RR Type）为RSIG。然后是类型覆盖字段，此例为"A"，表示主机IPv4地址资源记录。表示签名算法的字段值等于5。即签名算法为RSA/SHA1。3表示被签名的资源域名记录所有者（host.example.com）中的标签数量，如本例中为3，*.example.com.为2，"."的标签数量为0，签名有效期在 20030220173103和20030322173103之间。密钥标签值为2642。签名者的名字为"example.com"，在其后就是采用RSA/SAH1算法运算得到的签名
🕤 2.2.3 NSEC
NSEC：为了应答那些不存在的资源记录而设计
在区数据签名时，NSEC记录会自动生成。如在vpn.test.net和xyz.test.net之间会插入下面的两条记录
DNSSEC采用的方法如下：将所有者的域名看作是一个个独立的无符号左对齐的8位字节的字符串（unsigned left-justified octet strings）进行按右优先（rightmost）的排序，并将所有大写字母转换成小写字母进行排序，详细的排序方法可参考RFC 4034
🕤 2.2.4 DS
DS ：记录存储DNSKEY的散列值，用于验证DNSKEY的真实性，从而建立一个信任链
例子中的DS记录的前4个文本字段指定记录所有者名称为dskey.exmaple.com，TTL值为86400，DNS记录类别(class)为IN，资源记录类型（RR Type）为DS。DS 之后的字段依次是密钥标签（Key Tag），此处为60485；算法字段，表示所有者（dskey.example.com）用来签名的算法，此例为5, 表示RSA；散列算法字段，此例为1, 表示使用的报文摘要算法为SHA-1。最后括号中是所有者（dskey.example.com）使用散列算法（SHA-1）计算得到的16进制表示的摘要信息。Example.com必须为这个记录进行数字签名，以证实这个DNSKEY的真实性
🕘 2.3 DNSSEC对DNS协议的修改
DNSSEC新增的4种资源记录，这些记录的长度远远超过了最初的DNS协议标准规定的512字节，而要求DNS报文大小必须达到1220字节，甚至是4096字节。因此DNS服务器如果要支持DNSSEC，则首先需要支持扩展DNS机制（Extension Mechanisms for DNS, EDNS）
- 1987年的RFC 1035限制了DNS 报文大小、新功能
- EDNS扩展DNS格式和功能
- IPv6、DNSSEC、ECS等
- 向后兼容的 Workaround尝试
- 服务器不支持或被防火墙过滤
- DNS Flag day: dnsflagday.net
- 2019/2/1日后，对EDNS实现不标准的授权服务器，Google等公共DNS将不再尝试访问，可能导致解析失败
伪资源记录：
为了保持向后兼容性，更改已有的DNS协议格式是不可能的，所以只能在DNS协议的数据部分进行扩展。EDNS中引入了一种新的伪资源记录OPT RR（Pseudo-RR）。之所以称之为伪资源记录是因为它不包含任何DNS数据，并且不能被缓存、不能被转发、不能被存储在区（zone）文件中。OPT被放在DNS通信双方DNS消息的Additional data区域中。
DNSSEC在协议报文头中增加了三个标志位：
DO（DNSSEC OK, 参见RFC3225）标志位：支持DNSSEC标志位AD（Authentic Data）标志位：认证数据标志CD（Checking Disabled）标志： 关闭检查标志位
图示的是报文中的RRSIG记录。RRSIG记录中可以看出签名者的名字是ietf.org，签名算法为RSA/SHA1。同时，在发送RRSIG记录的DNS消息的附加区域有一条OPT记录。
🕘 2.4 DNSSEC递归解析过程
| 步骤 | 查询-响应（Query-response） | 可选的 DNSSEC 数据（Optional DNSSEC data） |
|---|---|---|
| ① | DNS 客户发送 DNS 请求给递归服务器 | DNS 客户将 DO 比特置 1，表示它支持DNSSEC (DNSSEC-aware) |
| ② | 递归服务器收到客户请求后向根和顶级 DNS 服务器 (TLD) 发送 DNS 查询请求 | 递归服务器将 DO 比特置 1, 表示它支持DNSSEC (DNSSEC-aware) |
| ③ | TLD 服务器给递归 DNS 服务器返回 DNS 响应, 包括请求区的权威 DNS 服务器的 IP 地址。 | 父区的权威 DNS 服务器指示子区用 DNSSEC签名, 并且包括一个安全的代理 (DS 记录) |
| ④ | 递归 DNS 服务器发送一个 DNS 查询到该区的权威 DNS 服务器 | 递归服务器将 DO 比特置 1，表示它支持DNSSEC (DNSSEC-aware)；将 CD 比特置1表示其能够验证响应中的签名的资源记录 |
| ⑤ | 权威 DNS 服务器返回一个包含资源记录的 DNS 响应给递归服务器。 | 权威 DNS 服务器在响应中加入 RRSIG 记录格式的 DNSSEC 签名 |
| ⑥ | 递归 DNS 服务器将包含资源记录数据的 DNS 响应发送给 DNS 客户 | 递归服务器用AD标志告知 DNS 客户 DNS 响应是否已验证 |
查看DNSSEC域名解析过程：
支持dig查询的Web网站（https://www.diggui.com/）
在Linux系统中直接用dig查询
🕘 2.5 DNSSEC安全性分析
- DNSSEC的安全性取决于 PKI 所用密钥的安全性
- DNSSEC 选择RSA/SHA-n 加密算法，即首先将要传送的数据通过 SHA-n 算法进行安全散列变换，然后利用RSA 算法生成的私钥进行数字签名
时间 安全强度(bit) 数字签名算法 散列算法 2010 年之前 80 RSA 1024 SHA-1 2010 − 2030 年 112 RSA 2048 SHA-256 2030 年之后 128 RSA 3072 SHA-256/512 \begin{array}{|c|c|c|c|} \hline \text { 时间 } & \text { 安全强度(bit) } & \text { 数字签名算法 } & \text { 散列算法 } \\ \hline 2010 \text { 年之前 } & 80 & \text { RSA 1024 } & \text { SHA-1 } \\ \hline 2010-2030 \text { 年 } & 112 & \text { RSA 2048 } & \text { SHA-256 } \\ \hline 2030 \text { 年之后 } & 128 & \text { RSA 3072 } & \text { SHA-256/512 } \\ \hline \end{array} 时间 2010 年之前 2010−2030 年 2030 年之后 安全强度(bit) 80112128 数字签名算法 RSA 1024 RSA 2048 RSA 3072 散列算法 SHA-1 SHA-256 SHA-256/512
- DNSSEC 选择RSA/SHA-n 加密算法，即首先将要传送的数据通过 SHA-n 算法进行安全散列变换，然后利用RSA 算法生成的私钥进行数字签名
- DNSSEC通过数字签名保证域名信息的真实性和完整性，防止对域名服务信息的伪造、篡改
- DNSSEC并不保证机密性，因为它不对DNS记录进行加密，也解决不了DNS服务器本身的安全问题，如被入侵、存储的Zone数据被篡改、拒绝服务攻击、DNS软件的实现问题等
由于DNSSEC的报文长度增加和解析过程繁复，在面临DDoS攻击时，DNS服务器承受的负担更为严重，抵抗攻击所需的资源要成倍增加
DNS加密（DNSCrypt）
🕒 3. DNSSEC部署
DNSSEC的部署也面临着巨大挑战。1999年RFC 2535发布后的近10年间，DNSSEC受限于技术、成本、网络性能等多方面因素的影响，一直未得到各方面的充分重视，部署进展缓慢。BIND 9的开发主要用于支持 DNSSEC协议。2000年，瑞典在其国家顶级域中首次尝试部署 DNSSEC协议，但发现存在隐私和扩展方面的问题。随后几年，DNSSEC协议修修补补，部署实施进展缓慢。
DNSSEC协议设计时并没有考虑增量式部署 的情况，其安全功能是基于所有DNS服务器全部采用DNSSEC协议这一假设的，在DNSSEC完全部署到位之前，会造成"安全孤岛"现象。
如何判断一个域名服务器是否支持DNSSEC？
🔎 Internet.nl
DNSSEC、DNS Encrypt 就安全了吗？
🔎 Encrypted DNS =⇒ Privacy?
A Traffic Analysis Perspective
域名解析的依赖关系有时并不取决于域名所在的层次，比如CERNET.NET的域名的解析依赖于.CN、.HK和.DE。根据2015年的测试结果，CERNET.NET的域名解析可能依赖于24个域名
🔎 段海新：互联网基础设施安全依赖性研究
OK，以上就是本期知识点"DNS安全"的知识啦~~ ，感谢友友们的阅读。后续还会继续更新，欢迎持续关注哟📌~
💫如果有错误❌，欢迎批评指正呀👀~让我们一起相互进步🚀
🎉如果觉得收获满满，可以点点赞👍支持一下哟~
❗ 转载请注明出处
作者：HinsCoder
博客链接：🔎 作者博客主页