DNSSEC

上回书说到我最近在整理DNS的配置，其实当时这么做最早的诉求是把用来做ACME DNS-01验证（RFC 8555第8.4节）的域名单独拆出来，以改善其更新响应速度（因为大部分情况下权威DNS记录并不需要经常更新，我们更关注的是响应性能和可用性，而DNS-01验证则对更新时效性有比较高的要求）。

不过既然来都来了，索性把证书也顺手更新一下，从RSA换成ECC。由于我2015年就启用了DANE和TLSA，因此这意味着需要重新生成所有的TLSA记录；另外我也顺便给一些跑了SSH服务的域名补上了SSHFP记录。

这里记录一下所用的命令，供未来参考。

我的权威DNS跑在BIND 9上，采用Hidden Master架构，并开启了DNSSEC的inline-signing。

家里用不同的VLAN和网段做了隔离。早期规划时，我简单地把网段和子域做了一对一映射，每个子域都是一个独立的zone：

flowchart LR
    root["example.net
（主域名）"]
    sjc["sjc.example.net"]
    
    root --> sjc
    sjc --> guest["guest.sjc.example.net"]
    sjc --> iot["iot.sjc.example.net"]
    sjc --> tiot["tiot.sjc.example.net"]
    sjc --> t["t.sjc.example.net"]
    sjc --> ut["ut.sjc.example.net"]

这些子域基本都由内网的DHCP服务器通过动态更新（RFC 2136）维护。这样，在内网访问某台机器时，不必去查它拿到了什么IP地址，直接用主机名加上所在的VLAN就行。不过时间长了，这套配置带来了很多不必要的维护负担：

1. 每个zone都有自己的一套DNSSEC密钥。我配置的dnssec-policy为每个zone生成一把Ed25519（RFC 8080）CSK，对应K*.key、K*.private、K*.state三个文件，目录里还堆满了各种.signed、.jnl和临时的.jbk文件。
2. 每多委派一个签名子zone，父zone就得多维护一组NS和DS记录。密钥轮换时，如果旧DS还在缓存里，对应的DNSKEY却已经撤下，验证就会失败，客户端看到的就是SERVFAIL。
3. named.conf里写满了大同小异的zone声明和ACL，Hidden Master后面的每台辅DNS服务器上，也都得再为它们各配一遍。

这些子域都由同一台DHCP服务器、用同一把TSIG密钥更新，拆成独立的zone在安全性方面没有必要。

今天花了些时间撤销这5个子域的独立zone和委派，把记录并进sjc.example.net。主机名不变，例如myhost.iot.sjc.example.net依然按原样解析，只是不再单独维护iot.sjc这个zone。

前几天刚刚写了一篇《别了，SMTP mTLS》，其中一件让人哭笑不得的往事，是DigiCert在2024年因域名控制权验证（DCV）出现漏洞，本应按规定在24小时内吊销受影响的证书，却因为顾忌大企业客户的内部业务中断而未能及时执行。公共证书一旦兼作内部基础设施的凭据，紧急吊销就会遇到这样的阻力。Chrome后来在根证书策略中要求逐步分离客户端认证（clientAuth）用途；其中，2027年3月15日及以后签发的终端证书必须只包含serverAuth。邮件服务器之间原本相安无事的mTLS双向认证，就这么稀里糊涂地成了商业CA合规翻车的牺牲品。

正如周师傅说的：「这个世界不会再好了」。本周，在PHP、Node.js、Linux纷纷爆出重大漏洞之余，eMudhra和GoDaddy这两家CA也跟着爆雷了。

这些事背后是同一个问题：支撑整个互联网的Web PKI，远没有我们希望的那般严谨，更像是由一群水平参差不齐的商业机构靠各方妥协拼凑起来的「草台班子」。

目的

在本地的局域网上建立 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 的某处断言令其退出。