delphij's Chaos

我平时会写不少技术文档。其中的示范代码，特别是涉及命令行操作的部分，往往包含一些需要临时填写并在后文重复使用的参数，读者不能直接照搬例子去运行，而是需要先做一些修改才能使用。

前几天在写生成SSHFP和TLSA记录这篇作弊条的时候，我顺手给本站使用的Chaos主题加上了一个可交互的示例参数功能，并把之前合并BIND 9子域等几篇旧文也一并改了过来。

从减少重复手工操作、避免忙中出错的角度来说，许多时候（尤其是对于「作弊条」这类题材的内容），比较理想的文档形式应该是一个可以填写、填完就能直接复制的模板。这是因为在这些操作里，变量（或者说需要读者填写的内容）通常是主机名、IP地址，或是本地某条命令的输出结果（例如公钥的hash值），而其余参数则应与原文保持严格一致，且同一组参数往往会贯穿全文。

例如在TLSA和SSHFP那篇里，域名example.net、邮件服务器mx1、SSH主机beastie，以及前一步刚用OpenSSL算出来的公钥SHA-256和SHA-512散列值，会在后面的命令行和BIND区域文件模板里反复出现。假如完全靠手工在各个代码块之间来回查找替换，不仅繁琐，而且漏改或是贴错一段，还很容易导致一些其他问题。

在一些文档系统的DSL中，有一种用<var>标签标记的可编辑占位符：在渲染出来的页面上填入新值之后，整篇文档里的示例命令就会跟着一起变，点复制按钮拿到的也是替换好的命令。我认为这种交互非常适合类似作弊条这样的内容，于是用Antigravity给Chaos主题也做了一套类似的实现。这里记录一下它在实际文章中的写法，以及在迭代过程中考虑的一些细节。

上回书说到我最近在整理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<br/>（主域名）"]
    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，远没有我们希望的那般严谨，更像是由一群水平参差不齐的商业机构靠各方妥协拼凑起来的「草台班子」。

最近在整理一些以前写的东西，这里把一些关于全盘加密的想法记录一下。

在构建存储系统时，数据加密往往是一个常见需求，但「加密」本身并不是目的。脱离了具体的威胁模型去讨论加密算法或配置参数，往往容易陷入过度设计，或者在真正需要防御的地方留下盲区。结合FreeBSD下的geli(8) 与ZFS存储栈，我在这里重点梳理一下离线威胁边界、反容量分析的抹盘策略、机械硬盘与闪存缓存的差异化处理、块设备加密与文件系统原生加密的架构取舍，以及数据完整性校验的去重考量。

最近在查看一封邮件的原始信头时，其中一段Received:记录引起了我的注意：

1
2
3
4
5
6
7
8

Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange x25519 server-signature RSA-PSS (4096 bits)
	 server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mx2.freebsd.org", Issuer "YR1" (not verified))
	by anubis.delphij.net (Postfix) with ESMTPS id B904024CDA
	for <delphij@delphij.net>; Wed, 14 Oct 2026 12:46:42 -0700 (PDT)

注意其中的(Client CN "mx2.freebsd.org", Issuer "YR1" (not verified))。这个(not verified)对我来说有些意外，翻看我自己邮件服务器上的日志发现，对于来自mx2.freebsd.org和其他一些邮件服务的投递，都记录了类似的状态：

1
2
3
4
5

Oct 14 12:46:42 anubis postfix/smtpd[90904]: Untrusted TLS connection
  established from mx2.freebsd.org[96.47.72.81]: TLSv1.3 with cipher
  TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519
  server-signature RSA-PSS (4096 bits) server-digest SHA256
  client-signature RSA-PSS (4096 bits) client-digest SHA256

QA工程师走进酒吧，要了一杯啤酒，要了0杯啤酒，要了999999999杯啤酒，要了一只蜥蜴，要了-1杯啤酒，要了一个sfdeljknesv，酒保从容应对，QA工程师很满意。接下来，一名顾客来到了同一个酒吧，问厕所在哪，酒吧顿时起了大火，然后整个建筑坍塌了。

最近给本站正在使用的Chaos主题 增加并逐步完善了一套在客户端进行的全文检索功能。

早年本站使用的是Google站内搜索，不过换成Hugo以后模板中的这个搜索框也就去掉了，毕竟现在也没什么人看blog了，写下去除了给自己留点记录之外，或多或少其实是一种行为艺术，而本站的读者基本上也都知道如何使用搜索引擎。

不过，有时我自己也会希望在blog里找一些以前的文章，虽然本站在Google搜索中的覆盖率还相当高，但有些时候新的文章会搜索不到，或是其实内容已经过时但仍然被索引。虽然在大语言模型的帮助下我整体重建了分类和标签的标注，但这些对于定位有时还是不太方便。

Hugo作为一个静态站点生成器，其实已经有了不少成熟的本地搜索方案。不过，今年都已经2026年了，vibe一个本地搜索并不困难。这里记录一下这个本地搜索的演化过程，以及在这个过程中的一些工程取舍。

我给本站的 RSS 和 Atom feed 加了一个纯 JavaScript 实现的 XSLT 处理器，为浏览器移除内建 XSLT 支持做准备。

本站在2021年2月5日为RSS feed和sitemap添加了XSLT样式，后来重新设计本站主题 chaos-theme 时也沿用了这一做法。

这些 XML 文档便于程序读取，但直接给人看就不太直观；XSLT 可以把它们转换成 HTML，让同一份内容同时服务于程序和人类读者。

前几天我收到了一封措辞颇为客气的邮件：

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.org

The 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，行文措辞也显得颇为得体客气。