共49篇文章。
上回书说到我最近在整理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就行。不过时间长了，这套配置带来了很多不必要的维护负担：
dnssec-policy为每个zone生成一把Ed25519（RFC 8080）CSK，对应K*.key、K*.private、K*.state三个文件，目录里还堆满了各种.signed、.jnl和临时的.jbk文件。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，远没有我们希望的那般严谨，更像是由一群水平参差不齐的商业机构靠各方妥协拼凑起来的「草台班子」。
前几天我收到了一封措辞颇为客气的邮件：
Subject: Urgent Link Update – Prevent Misinformation
Dear partner delphij.net,
It has come to our attention that your site still contains a hyperlink to our former domain. This domain is no longer managed by our organization and now carries content that could be misconstrued as affiliated with us, potentially leading to misinformation.
Please replace this outdated link with our official and active website:
Old URL: futureofflight. org
New URL: futureofflight.en-html.orgThe old link appears in: https://blog.delphij.net/posts/2009/09/-/
We appreciate your cooperation in promptly correcting this matter to maintain editorial accuracy.
Best regards,
Grace Condie, Web Content Coordinator
Future of Flight Team
This email and its contents are confidential and intended only for the recipient. If you are not the intended recipient, please do not share or use this information and notify the sender.
大意是说，我多年前（2009年）一篇记录去华盛顿州旅行的文章里，链接到了波音飞行博物馆当时使用的域名 futureofflight.org。邮件称该域名已不再由他们维护，并建议我将其替换为「官方且活跃」的所谓新域名：futureofflight.en-html.org。
如你所见，对方还十分贴心地在旧域名中添加了空格，防止我误触；甚至还指出了有问题的 URL，行文措辞也显得颇为得体客气。
这里简单记一笔。我有一个域名使用的是 Google Workspace 的邮件服务。昨天，一位用户使用该域名向中国的 QQ 邮箱用户发送邮件时被退回了。
退信中给出的线索是：
550 DMARC check failed [XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
IP: 2607:f8b0:4864:20::112b]. https://service.mail.qq.com/detail/124/61.腾讯给出的那个链接是一篇关于 DMARC 如何配置的文章。从上下文来看，应该是由于腾讯的服务器认为 Google Workspace 的 IP 地址不在允许发信的范围内。
退信确实是 Google Workspace 的邮件服务生成的，数据来源是和对方(腾讯) MX 之间的 SMTP 会话。
我的这个域名确实启用了 DMARC。我的DMARC记录 (域名下的 _dmarc TXT 记录) 设置如下：
v=DMARC1; p=reject; rua=mailto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX@dmarc-reports.cloudflare.net;
pct=100; adkim=s; aspf=s此配置要求对方检查 DKIM 和 SPF，并拒绝不匹配的邮件。
其 SPF 记录 (域名的 @ 的 TXT 记录) 设置如下。这是 Google 官方文档中推荐的设置：
v=spf1 include:_spf.google.com -all主要的区别是，我使用的是 -all，即拒绝 SPF 不匹配的邮件，而不是更为常见的、表示即使发现 SPF不匹配，也仅仅做标记但允许接收的 ~all。
这里需要说一下背景：在 2004 年左右，一些业内人士认为应该推荐采用~all 而不是 -all，因为当时许多大型邮件系统的架构中存在多层邮件服务器分别进行不同的过滤处理，而在 SMTP 会话阶段直接回一个永久性拒绝 (5XX) 代码可能会让一些不适任的邮件系统管理员如此配置的邮件系统将一些伪造了来源的邮件退到不希望的地方。我并不赞同这样的观点。事实上，在会话阶段进行退信要比在收件方服务器上生成退信并将退信退给发件人或对方域名的 postmaster 要更好：对于垃圾邮件的发送者，这意味着他们的邮件服务器会立即知道自己的行为被直接地丑拒，接收方明确告知他们吞下垃圾邮件，而不是继续发送。对于正常的邮件服务器，这意味着发件人可以立即收到退信从而找到自己的邮件系统管理员，而不是告诉收件人去翻垃圾箱看看是否有自己的邮件。另一方面，回应永久性拒绝并不妨碍收件服务器对邮件内容进行进一步分析：它完全可以在 DATA
阶段结束时再回拒绝，从而将邮件完整地接收下来但不递给收件人。
当然，历史无法假设，并已经无数次地证明人类根本不配拥有美好的事物。
DomainKey 记录 (域名下的 google._domainkey TXT 记录) 由于与此问题无关，故在此处略去。
该域名启用了 DNSSEC。
Ed25519 是一种高性能的公钥签名系统。和 RSA 相比，同等强度的 Ed25519 的密钥长度要比 RSA 短很多，此外，软件实现的 Ed25519的验证速度也比同等强度的 RSA 快很多。
尽管早在2018年 RFC 8463 Section 5就已经将 RFC 6376 Section 3.3 修正为要求验证者必须支持 Ed25519 验证，然而时至今日主要的邮件服务提供商中，包括 Google 的 Gmail 和 Microsoft 的 Outlook.com 以及 Apple 的 iCloud都还不支持验证 Ed25519 DKIM 签名。ProtonMail 支持 Ed25519 的 DKIM 签名，但它并不使用Ed25519 签名向外发出的邮件。
在本地的局域网上建立 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 等等相比，拥有独立的域名意味着可以在这些服务之间随时进行转移，而无需逐个通知亲朋好友。