DNSSEC

目的

在本地的局域网上建立 DNS 解析服务可以显著地改善 DNS 的安全性：所有的 DNS 查询将由可以信任的本地 DNS 解析服务进行验证，而不是简单地相信一台不受控的远程服务器通过 UDP 提供的应答。因此，这些年来我自己的网络包括机房的网络都是自己运行一组 DNS解析服务的。

TL;DR：我的观点是现时 (2023) 大多数人都不应该自建 DNS，而应该找一家比较可靠的供应商。

下面说说我的理由。

近期由于一些众所周知的原因，我做了一系列域名转移的操作。和 2006 年的这篇相比，这些年我也经历了不少域名注册服务提供商，并且积累了不少经验，是时候更新一下了。

域名服务是一项互联网基础服务，它提供了容易被人记忆和识别的在线地址。对于个人和企业来说，拥有自己的域名最大的好处在于能够掌握随时换一家供应商的议价权。集中式的平台，包括 YouTube、Twitter、GitHub，也包括新兴的平台如 TikTok、或是来自中国的小红书、喜马拉雅、B站等等，尽管也都是很好的产品，有些甚至可以为内容作者带来丰厚的回报，但是其上的个人或是企业无法很容易地离开这些平台。依赖这些平台，意味着在它们选择对内容作者采取某些行动，或是退出某项生意的时候，当事人可能没有任何其他选择，而必须在极短的时间内通知自己的受众去其他平台，这有时是很困难甚至不可能的。

对个人来说，邮件服务的运行成本是很高的（这里需要考虑的不仅是服务器本身的成本和运行费用，也包括需要投入的时间精力）。但即使不自己去运行邮件服务，也仍然有许多支持独立域名的邮件服务提供商，例如 Google Workspace、Microsoft 365、Zoho Workplace等等。与单纯使用 Gmail 或 outlook.com 等等相比，拥有独立的域名意味着可以在这些服务之间随时进行转移，而无需逐个通知亲朋好友。

DNSSEC 是一组针对 DNS 协议的扩展，其主要目的是为数据的权威性（或者说DNS数据确实来自于有权发布这些数据的人）提供一套验证机制。DNSSEC并不改善私密性，所有的查询依然是明文的。

目前最新的 DNSSEC 最佳实践指南是 BCP 237 (RFC 9364)。值得说明的是，如果没有特别的需要，使用 DNS 服务业者的 DNSSEC 实现可以避免踩很多的坑，尽管这样一来安全方面就完全要仰赖这些业者了，但对普通的域名所有这来说这些服务要比他们自己去架设和管理要可靠不少。本文并不打算深入介绍 DNSSEC 及其部署，而只是关注于在进行域名转移时需要注意的问题，以备我个人未来进行参考。

📜 历史文件已不具备现实意义

我认为不再需要收集更多数据了。

这个 blog 的首页底部增加了两个图，用来测试访客是否启用了 DNSsec 验证。这项服务是由 Matthäus Wander 和 Torben Weis 提供的，点击这个连接可以检查自己的 DNS 缓存服务器是否会进行 DNSsec 验证。如果没有，可以参考我的这张 作弊条 来自行配置。

DNSSEC 是一种验证域名信息真实性的协议扩展。个人之前一直觉得这事相当的蛋疼：DNS协议本身是不安全的，而DNSSEC无非是增加了数字签名验证，而这验证还依赖于相当复杂的密钥更新和分发机制，这一切都给它的推广带来了困难。

这次休假前头一天晚上收到了 ISC 发来的安全公告 CVE-2011-1910。我起草完 FreeBSD 安全公告 FreeBSD-SA-11:02.bind.asc 之后就去休假了，这里补上这个漏洞的说明。

无论你是否使用 DNSsec，只要用 BIND 9.x 来做 DNS 缓存解析服务（而不仅仅做Authoritive DNS服务），就有可能受到这个漏洞的影响。而攻击的方法也相当简单，攻击者只要建立一个 DNS 域，令在回应域名不存在的同时发回一个大的 RRSIG RRset，即可触发 BIND 的某处断言令其退出。

DNS是目前互联网上使用最为普遍，同时也是漏洞很多的一个协议。DNS投毒攻击（Poisoning）是一种比较常见的攻击手法，具体而言，通常一台 DNS 缓存服务器能够影响大量的客户机，通过投毒攻击，能够使得大量用户访问某个具体域名时得到不正确的结果（例如，钓鱼网站，等等）。

最近炒的比较火的一个漏洞是 DNS 协议本身发现的一个严重问题（CERT VU#800113）。国内媒体对此的报道多数都语焉不详，因此我想有必要说说这个漏洞到底是怎么回事。