delphij's Chaos

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

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

• example.net.（主域名）
• sjc.example.net.
  • guest.sjc.example.net.
  • iot.sjc.example.net.
  • tiot.sjc.example.net.
  • t.sjc.example.net.
  • 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，行文措辞也显得颇为得体客气。

最近给 blog 增加了一个自定义的 404 错误页面。像 Hugo 这样的静态网站生成器在构建时，默认会把渲染好的 404 页面直接输出在网站根目录下，即 /404.html。

针对这类页面，我们通常希望：

1. 当访客访问不存在的网址时，服务器呈现该页面的内容，并且 HTTP 状态码必须是 404。
2. 当有人（或爬虫）直接在浏览器中访问 /404.html 时，同样呈现其内容，但返回的 HTTP 状态码依然必须是 404，而不是 200 OK。

今天收到家里的消息，北京时间2026年8月19日22时11分，姥姥在睡梦中平静地走了。