1983年，Paul Mockapetris在RFC 882和883中定义了Domain Name System（DNS）。这个协议的核心目标简单明确：将人类可读的域名映射为机器可读的IP地址。在那个只有几百台联网主机的ARPANET时代，Mockapetris和他的同事们做了一个影响至今的设计决策——DNS查询和响应不需要任何形式的身份验证。

这个决策在1983年是合理的。当时的网络环境是一个"可信社区"，所有参与者都是已知的研究机构。但四十年后，当每天有超过2万亿次DNS查询在全球互联网上执行时，这个"无验证"设计变成了一把悬在互联网头上的达摩克利斯之剑。

信任的代价：DNS协议的根本性缺陷

DNS协议的设计者并非没有考虑过安全问题。但在1980年代，“安全"的含义与今天完全不同。当时的主要威胁是配置错误和网络故障，而非恶意攻击。协议被设计为"尽可能简单”，每个DNS消息只包含三个关键信息：查询名称、查询类型和一个16位的交易ID（Transaction ID）。

这个16位ID是DNS协议中唯一的"安全机制"。当一个解析器发送查询时，它会随机选择一个0到65535之间的数字作为ID，并期望收到的响应携带相同的ID。理论上，攻击者如果不知道这个ID，就无法伪造有效的响应。

但16位只有65536种可能。更糟糕的是，早期DNS实现使用的是简单的递增计数器而非真随机数。这意味着攻击者只需要发送大量伪造的响应，就有很大概率猜中正确的ID——这就是DNS缓存投毒（Cache Poisoning）攻击的核心原理。

一个解析器的困境

当递归解析器（Recursive Resolver）代表客户端查询某个域名时，它会经历一个复杂的过程。以查询www.example.com为例：

  1. 解析器首先向13个根服务器之一查询.com的权威服务器
  2. 根服务器返回.com顶级域的NS记录和胶水记录
  3. 解析器向.com权威服务器查询example.com的权威服务器
  4. .com服务器返回example.com的NS记录
  5. 解析器向example.com权威服务器查询www.example.com的A记录
  6. 权威服务器返回最终答案

每一步都可能成为攻击的切入点。而且，这个过程中的"额外信息"——比如权威服务器在响应中附加的胶水记录——同样会被解析器信任并缓存。如果一个攻击者能在正确答案到达之前注入伪造的响应，解析器就会将错误信息缓存起来，影响所有后续查询该域名的用户。

Kaminsky攻击：一个协议缺陷的完美演绎

2008年，安全研究员Dan Kaminsky发现了一种方法，可以将这个理论风险转化为实际的灾难性攻击。他的创新之处不在于攻击的技术细节，而在于攻击的策略。

传统的缓存投毒攻击需要攻击者知道解析器何时会发起查询。但Kaminsky发现，攻击者可以主动触发查询：只需要让解析器查询一个不存在的子域名（如random123.example.com），解析器就会被迫向example.com的权威服务器发起查询。

在解析器等待权威服务器响应的时间窗口内，攻击者可以疯狂发送伪造的响应。每个伪造响应不仅包含对random123.example.com的回答，还包含额外的"权威"记录——将example.com的NS记录指向攻击者控制的服务器。

这就是Kaminsky攻击的精髓：不是投毒单个记录，而是劫持整个域名的权威性。一旦成功，攻击者就成为了该域名在受害者解析器眼中的"官方来源"，可以返回任何他想返回的IP地址。

16位的数学困境

在Kaminsky攻击公开之前，大多数DNS服务器使用固定的源端口（通常是53）进行所有查询。这意味着攻击者只需要猜测16位的交易ID，大约65536种可能。

Kaminsky本人估计，在一个典型的网络环境下，攻击者可以在大约10秒内成功投毒一个域名。这对于一个精心准备的攻击来说绰绰有余。

作为紧急响应，DNS软件开发商实施了源端口随机化（Source Port Randomization）。解析器现在会为每个查询随机选择一个源端口（约16000个可选端口），将攻击者需要猜测的空间从16位扩展到约32位。这使攻击复杂度从65536次尝试增加到超过40亿次，理论上将攻击时间延长到不切实际的水平。

但"理论上"和"实际上"之间往往存在距离。

SAD DNS：当安全措施成为攻击面

2020年11月，加州大学河滨分校和清华大学的研究人员在ACM CCS会议上发表了一篇论文，展示了如何绕过源端口随机化保护。他们称之为SAD DNS（Side-channel AttackeD DNS）。

攻击的巧妙之处在于利用ICMP速率限制作为侧信道。现代操作系统为了防止ICMP洪水攻击，会对发出的ICMP错误消息进行速率限制——例如Linux默认限制为每秒50个。研究人员发现，这个速率限制可以用来"探测"哪些端口是开放的。

攻击流程如下：

  1. 攻击者发送大量UDP探测包到目标解析器的不同端口，伪造源地址为权威服务器的IP
  2. 如果探测的端口是关闭的，解析器会尝试发送ICMP"端口不可达"消息，但会因速率限制而丢弃部分消息
  3. 如果探测的端口恰好是解析器等待权威响应的开放端口，则不会有ICMP消息，速率限制计数器不会增加
  4. 攻击者通过发送自己的测试包并观察是否收到ICMP响应，来判断速率限制是否被触发
  5. 通过这种二分搜索方法，攻击者可以逐步缩小开放端口的范围

这种方法将32位的搜索空间重新压缩到可操作的范围内。虽然攻击仍然需要相当的资源和时间，但它证明了"隐藏端口号"这种安全措施本质上是"通过隐匿实现安全"（security through obscurity），在没有密码学验证的情况下永远不可能完全可靠。

Sea Turtle：当国家级攻击者盯上DNS

如果说Kaminsky攻击展示了协议缺陷的破坏力，那么2019年曝光的Sea Turtle攻击则展示了DNS漏洞在国家级攻击者手中的战略价值。

Cisco Talos的安全研究人员发现，一个疑似与伊朗有关联的威胁组织从2017年初开始，对中东和北非的政府机构、外交部门、能源组织发动了持续两年的DNS劫持行动。至少40个不同国家的组织受到影响。

Sea Turtle攻击的独特之处在于它的攻击路径：攻击者不是直接攻击目标组织，而是先入侵为这些组织提供服务的DNS注册商和互联网基础设施提供商。通过获得对这些关键中间人的控制，攻击者可以修改受害域名的DNS记录，将流量重定向到攻击者控制的服务器。

DNS Hijacking Methodology

图片来源: 2.bp.blogspot.com

Sea Turtle攻击的DNS劫持方法论（图片来源：Cisco Talos）

攻击者甚至入侵了瑞典的NetNod——一个管理DNS根服务器（i.root-servers.net）的非营利组织。通过这个访问权限，他们能够劫持沙特阿拉伯国家域名（.sa）的DNS记录，潜在影响所有沙特域名。

证书"冒充"技术

Sea Turtle攻击者使用了一种称为"证书冒充"的技术来绕过SSL/TLS保护。当攻击者将域名重定向到自己的服务器时，他们会从Let’s Encrypt、Comodo等证书颁发机构获取该域名的合法证书。

这些证书是完全有效的——浏览器不会显示任何警告。攻击者只需要证明他们"控制"了该域名，而由于他们刚刚劫持了域名的DNS记录，这个验证过程变得轻而易举。

一旦用户被重定向到攻击者的服务器，他们的凭据就会被捕获，然后流量被透明地代理到真正的服务器。用户可能只会注意到轻微的延迟，而不会意识到他们的密码已经被窃取。

DNS放大攻击：安全机制本身成为武器

讽刺的是，DNSSEC——为解决DNS安全问题而设计的扩展——本身也可能被滥用为攻击武器。

DNS放大攻击（Amplification Attack）利用了UDP协议的无状态特性和DNS响应通常比查询大得多的事实。攻击者向开放DNS解析器发送小型查询（通常使用ANY类型请求所有记录），但将源IP伪造成受害者的IP。解析器会将大型响应发送给受害者，造成带宽淹没。

DNSSEC签名的域名会显著增加响应大小。一个典型的DNSSEC签名响应可能达到4000字节，而对应的查询只有几十字节。这意味着放大倍数可以达到100:1甚至更高。Cloudflare的研究人员指出：“讽刺的是，DNSSEC设计的目的是让DNS系统更安全，但巨大的密钥却使攻击更有效。”

DNSSEC：迟到的验证层

面对这些威胁，互联网工程任务组（IETF）在1997年开始开发DNS Security Extensions（DNSSEC），最终在2005年以RFC 4033-4035系列正式发布。

DNSSEC的核心思想是给DNS数据加上数字签名。但它不是加密DNS流量——用户仍然可以看到查询和响应的内容——而是提供数据来源认证和数据完整性保护。

四种关键记录类型

DNSSEC引入了四种新的DNS记录类型：

DNSKEY（DNS公钥）：存储用于验证签名的公钥。每个DNSSEC-enabled区域至少有一个密钥对。实际上，通常使用两个密钥：Zone Signing Key（ZSK）用于签署区域内的常规记录，Key Signing Key（KSK）用于签署DNSKEY记录本身。这种分离允许频繁轮换ZSK而不需要与父区域协调。

RRSIG（资源记录签名）：存储对RRset（一组相同类型和名称的记录）的数字签名。每个签名包含签名者的密钥标签、签名过期时间、使用的算法，以及实际的签名数据。当解析器请求A记录时，它会同时收到对应的RRSIG记录。

DS（委托签名者）：建立父子区域之间的信任链。DS记录存储的是子区域KSK的哈希值，由父区域签名。例如，.com区域包含example.com的DS记录，该记录由.com的密钥签名。这种机制确保了信任可以从根区域一直延伸到叶子域名。

NSEC/NSEC3（下一个安全记录）：提供"不存在证明"。当查询一个不存在的域名时，权威服务器返回NSEC记录，证明在字母顺序上该域名之前和之后都没有记录。NSEC3使用哈希来防止"区域遍历"攻击，即攻击者通过枚举所有不存在查询来重建整个区域的内容。

信任链的构建

DNSSEC的信任模型是一个从根到叶的层级结构：

DNSSEC Chain of Trust

图片来源: jpmens.net

DNSSEC信任链示意图（图片来源：Jan-Piet Mens）

  1. 信任锚点（Trust Anchor）：根区域的KSK公钥被预装在所有DNSSEC验证解析器中。这个密钥通过ICANN的根密钥签名仪式（Root Key Signing Ceremony）生成和管理。

  2. 根区域签署：根区域的ZSK由KSK签名，而KSK的公钥就是信任锚点。

  3. 顶级域签署：根区域包含每个TLD（如.com、.net）的DS记录，指向该TLD的KSK。验证解析器可以通过根区域的签名验证这些DS记录，然后用它们来验证TLD的DNSKEY。

  4. 二级域名签署：TLD包含每个注册域名的DS记录，延续信任链。

当验证解析器查询www.example.com时，它会从根开始，逐级验证每个签名，直到最终验证example.com返回的A记录签名。如果任何一级验证失败，整个响应都会被标记为不可信。

根密钥签名仪式：互联网的"核按钮"

DNSSEC信任链的顶端是根区域的KSK。这个密钥的私有部分存储在两个安全设施中：一个在美国加利福尼亚州洛杉矶，另一个在弗吉尼亚州库尔佩珀。每个设施都有专门的"仪式室"（Ceremony Room），配备硬件安全模块（HSM）来存储密钥。

每季度，来自世界各地的约50名"可信社区代表"（Trusted Community Representatives）会参与密钥签名仪式。这些人分为三组，每组七人，持有不同的物理密钥或智能卡。要访问HSM并使用根KSK签署新的根区域ZSK，需要多个不同组别的代表同时在场。

整个仪式持续3到8小时，每一步都严格按照脚本执行，全程录像并直播。独立的审计员监督整个过程，确保没有任何密钥被非法复制或使用。

这个复杂的仪式确保了即使单个参与者被收买或设施被入侵，攻击者也无法获得完整的密钥。这可能是互联网上最接近"七个人控制互联网"这种说法的现实存在——尽管实际机制要复杂得多，需要至少十几个人同时在场才能操作。

DNSSEC部署困境：为什么安全机制难以普及

尽管DNSSEC在技术上是解决DNS安全问题的正确方案，但其部署率却低得惊人。根据2024年的统计数据，全球只有约5-6%的域名启用了DNSSEC签名，而.com顶级域的签名率仅为5%左右。

DNSSEC Adoption Statistics

图片来源: pulse.internetsociety.org

DNSSEC验证率和ccTLD注册表部署情况（图片来源：Internet Society）

复杂性障碍

DNSSEC的复杂性是其部署率低的主要原因之一。与简单地将A记录指向一个IP地址不同，启用DNSSEC需要：

  1. 生成密钥对（ZSK和KSK）
  2. 配置权威服务器签署区域
  3. 将DS记录提交给注册商
  4. 建立自动化流程处理密钥轮换和重新签名
  5. 确保所有权威服务器同步

这个过程涉及多个参与方——域名注册人、DNS服务提供商、域名注册商——任何一个环节出错都可能导致域名无法解析。

失败的代价：DNSSEC配置错误的灾难

DNSSEC的一个特点是"失败即拒绝"。如果验证失败，解析器不会返回"不确定"的结果，而是直接返回SERVFAIL错误。这意味着用户根本无法访问该域名——不是被重定向到错误地址，而是完全无法连接。

Ianix维护了一份DNSSEC故障列表，记录了自2009年以来数百起影响重大的DNSSEC故障：

  • 2010年，瑞典（.se）域名因DNSSEC配置问题大规模不可访问
  • 2012年，美国政府域名（.gov）因DNSSEC验证失败而中断
  • 2018年，比利时（.be、.vlaanderen、.brussels）影响1410个域名的DNSSEC故障
  • 2023年，澳大利亚（.au）域名因DNSSEC问题出现服务中断

值得注意的是，列表中DNSSEC故障的中位持续时间是8天。更极端的案例包括某些美国政府域名的DNSSEC故障持续超过1000天（被称为"kiloday"级故障）。

这种高风险使得许多组织对启用DNSSEC持谨慎态度。对于大多数网站来说，DNSSEC提供的额外安全性难以量化，但配置错误导致的停机风险却是真实且可能致命的。

技术债务

DNSSEC的设计始于1990年代，当时的一些假设在今天已经过时：

预签名要求：早期设计认为服务器不够安全，无法存储私钥，因此要求所有记录预先签名。这导致了NSEC/NSEC3机制的复杂性，并阻止了动态签名带来的灵活性。

双密钥层级：KSK/ZSK分离的设计是为了减少与父区域的交互，但这也增加了管理复杂性。随着自动化程度提高，许多运营商现在使用单一密钥（CSK）。

响应大小问题：DNSSEC签名显著增加DNS响应大小。虽然EDNS0扩展允许更大的UDP数据包，但大型响应可能触发IP分片或强制TCP回退，两种情况都可能被中间设备阻止或导致性能问题。

使用RSA-2048密钥的DNSKEY记录约1755字节，加上签名，一个简单的DNS查询响应可能超过4000字节。这比传统DNS的512字节限制大了近8倍，在网络条件不佳时可能导致解析失败。

经济激励错位

DNSSEC的收益和成本分布不均。域名所有者承担了部署和维护DNSSEC的全部成本，包括技术复杂性和故障风险。但安全收益——防止缓存投毒和中间人攻击——主要惠及访问这些域名的用户。

更复杂的是，DNSSEC的收益在应用层几乎是不可见的。当用户访问一个DNSSEC签名的域名时，浏览器不会显示任何安全指示器。即使DNSSEC验证成功阻止了一个中间人攻击，用户也不知道自己刚刚被保护了。

相比之下，HTTPS会在浏览器地址栏显示锁图标，SSL证书错误会显示明确的警告页面。这种可见性为网站所有者提供了启用HTTPS的明确激励，但DNSSEC缺乏类似的反馈机制。

现代DNS安全：多条防线并行

DNSSEC并非DNS安全的唯一解决方案。近年来，几种互补的技术得到了广泛部署：

DNS over TLS (DoT) 和 DNS over HTTPS (DoH)

RFC 7858定义的DoT和RFC 8484定义的DoH为DNS查询提供了传输层加密。DoT使用专用端口853，DoH则复用HTTPS的443端口。

这些技术解决了DNS查询的机密性问题——防止网络上的窃听者看到用户查询了哪些域名。但它们并不验证DNS响应的真实性。攻击者如果控制了用户使用的解析器，仍然可以返回伪造的响应。

DoT/DoH和DNSSEC解决的是不同的问题：前者保护查询在传输过程中不被窃听或篡改，后者验证响应数据本身的真实性。两者是互补的，而非替代关系。

DNS Cookies

RFC 7873定义的DNS Cookies是一种轻量级的事务安全机制。客户端和服务器交换类似HTTP Cookie的令牌，用于验证后续请求的合法性。

与DNSSEC不同，DNS Cookies不验证DNS数据的真实性，而是验证请求/响应对的关联性。这可以有效防止源IP欺骗攻击（如放大攻击），但无法防止恶意权威服务器返回伪造数据。

RPKI和BGP安全

DNS不是唯一被设计为"可信"的互联网基础设施。BGP——互联网的路由协议——同样缺乏内置的验证机制。攻击者可以"劫持"IP前缀，将流量重定向到自己的网络。

资源公钥基础设施（RPKI）为BGP路由通告提供了验证机制。与DNSSEC类似，它使用加密签名来验证路由声明的合法性。虽然RPKI不直接保护DNS，但它可以防止攻击者通过路由劫持来拦截DNS流量。

为什么DNSSEC依然重要

尽管部署困难重重，DNSSEC仍然是解决DNS信任问题的根本方案。其他安全措施——如源端口随机化、DNS Cookies、DoT/DoH——都是在此基础上的补充防御。

DNSSEC提供了其他技术无法替代的能力：

数据来源认证：验证DNS记录确实来自域名的授权所有者，而非某个中间人。

数据完整性保护：确保记录在传输过程中未被篡改。

不存在证明：权威地证明某个域名不存在，防止攻击者伪造不存在的记录。

支持高级应用：DNSSEC为DANE（基于DNS的命名实体认证）提供基础设施，允许域名所有者在DNS中发布TLS证书指纹、SSH公钥、PGP密钥等，无需依赖传统证书颁发机构。

未来的方向

DNSSEC的未来可能在于简化和自动化。几个发展方向值得关注：

单一密钥简化：越来越多的运营商放弃KSK/ZSK分离，使用单一密钥，减少管理复杂性。

CDS/CDNSKEY自动化：RFC 8078定义的机制允许子区域自动向父区域发布DS记录更新，无需人工干预。这消除了DNSSEC密钥轮换中最容易出错的环节。

现代加密算法：从RSA转向ECDSA（椭圆曲线）和Ed25519，可以显著减小密钥和签名大小，降低响应膨胀问题。ECDSA P-256的密钥只有256位，而等效安全强度的RSA需要3072位。

DELEG记录类型：正在开发的新DNS记录类型可能彻底改变区域委托方式，将DNSSEC集成到委托机制本身，并支持加密传输（DoT/DoH）的自动发现。

结语

DNS协议的"无验证"设计是早期互联网信任文化的产物。在那个时代，网络上的每个节点都是已知的研究机构，安全意味着确保消息能够正确传递，而非防止恶意行为。

但这种信任假设在今天的互联网上已经不再成立。当攻击者可以利用DNS协议的缺陷窃取国家机密、劫持银行网站、发动大规模DDoS攻击时，“信任"本身成为了最大的安全漏洞。

DNSSEC不是完美的解决方案。它的复杂性、部署难度和故障风险是真实存在的问题。但在一个攻击者越来越复杂的世界里，密码学验证——尽管复杂——仍然是确保DNS可信的唯一根本方法。

正如安全研究员Thomas Ptacek那句著名的评论所言：“你可以在Pastebin上发布DNSSEC根RSA私钥，互联网上重要的一切都不会崩溃。“这既是批评（因为DNSSEC部署太少，泄露私钥影响有限），也是对现状的无奈——当我们终于有了验证DNS的工具，却选择了不用。

直到DNSSEC成为一种默认而非例外，DNS协议四十年前的设计缺陷将继续困扰互联网的每一天。

参考资料

  1. Mockapetris, P. (1983). Domain Names - Concepts and Facilities. RFC 882.
  2. Kaminsky, D. (2008). Kaminsky DNS Vulnerability. Black Hat USA.
  3. Adamitis, D. et al. (2019). Sea Turtle: A Persistent Cyber Espionage Threat. Cisco Talos.
  4. Houser, R. et al. (2020). SAD DNS: Side-Channel AttackeD DNS. ACM CCS 2020.
  5. Arends, R. et al. (2005). DNS Security Introduction and Requirements. RFC 4033.
  6. Huston, G. (2024). Where Did DNSSEC Go Wrong? Internet Society Pulse.
  7. SIDN Labs. (2025). None of the Biggest Internet Services Are DNSSEC-Enabled.
  8. Whisper Security. (2025). State of DNSSEC 2025.
  9. ICANN. (2023). The Key to the Internet and Key Ceremonies: An Explainer.
  10. Cloudflare. (2020). SAD DNS Explained.
  11. Mandiant. (2019). Global DNS Hijacking Campaign: DNS Record Manipulation at Scale.
  12. Ianix. (2025). Major DNSSEC Outages and Validation Failures.