摘要

  • BIND 10 重写期间，Mark Andrews 与 Evan Hunt 继续共同维护 BIND 9；一个继任者被宣布，并不等于原有生产系统的责任已经消失。
  • BIND 9 后来的深度重构说明，连续运行不等于冻结旧代码。真正需要分别证明的是支持状态、功能覆盖、具体负载的可用性、运营者采用与可回退的迁移。

2013 年 2 月，Internet Systems Consortium 发布 BIND 10 1.0.0。发布公告同时说它“得到完整支持”但“功能尚不完整”，其中 DHCP 部分又被单独界定为实验性工程快照。这几句话并不矛盾；它们只是拒绝把“准备好”压成一个布尔值。

软件可以已有支持渠道，也能为某类任务通过测试，却仍缺少另一类运营者不可缺少的能力。它可以被安装，而未必能够原位替换现有系统。版本号证明一次发布发生了，不能证明用户群已经完成迁移。

Mark Andrews 在一段 bind-users 邮件讨论中把界线说得很清楚：BIND 10 距离成为 BIND 9 的替代者还有一段距离，许多 BIND 9 功能尚未具备。但同一讨论也保留了一个重要限定：如果需求只是权威服务，且不依赖由 BIND 管理的 DNSSEC 签名，那么 BIND 10 当时已经可以用于生产。这不是简单的“能用”或“不能用”，而是对特定工作负载的判断。

ISC 的 BIND 历史让 Andrews 所承担的组织角色更加具体。BIND 10 于 2009 年启动，试图在全新应用框架上从头重写 BIND，并以替代和改进 BIND 9 为目标；资金与技术参与主要来自 ccTLD 社群。在 ISC DNS 团队的大部分成员投入“下一套系统”时，Andrews 与 Evan Hunt 留下来共同维护 BIND 9。

“继续维护”意味着替代叙事里常被省略的工作。现有运营者仍需要漏洞响应、可预测发布、回归控制和技术支持，软件打包者仍需要一个可信上游。新架构之所以能够在另一条线上积累能力，恰恰因为有人没有让生产选择在迁移完成之前塌陷。

这不是孤胆英雄故事。ISC 统计，BIND 9 漫长生命周期中有超过 43 名核心开发者作出重要贡献，旧提交记录还低估了外部贡献。ISC 的 2025 年 BIND 报告列出一个广泛的开发团队与外部合作群体。Andrews 的意义不在于他对 BIND 拥有主权，而在于他与 Hunt 在机构注意力分流时承担了一项可以核验的生产责任。

计划最终没有按最初方向完成。ISC 在 2014 年终止 BIND 10 开发，把投入重新转回 BIND 9。BIND 10 最后一任项目负责人 Shane Kerr 在 RIPE 68 作了《The Decline and Fall of BIND 10》演讲，会议档案保存了演示材料与视频。ISC 自己提醒，把结果仅归因于“第二系统效应”过于简单；资金结构、范围、架构、功能需求和采用过程都在其中。

重新聚焦 BIND 9 也不等于把它封存在原状。ISC 记录了后来对响应策略区的解耦、对核心函数的简化，以及用 libuv 替换自研网络接口。重构前，query_find() 的 McCabe 复杂度据报达到 453。这不是旧代码天然值得保留的证据，而是另一件事的证据：在维持外部服务与升级路径时，内部仍可发生深层改变。

ISC 2024 年工作报告还原了代码周围的运行体系：九名开发者、五名 QA 人员和两名经理，当年发布 25 个开源版本及 12 个支持预览版。BIND 9.20 完成跨多个版本推进的 libuv 事件循环迁移，并针对会阻塞查询处理的长任务设置专用线程池。重写与渐进重构不是道德上的对立面；二者都只能靠测试、观测和恢复路径获得可信度。

ISC 2021 年度报告记载 Andrews 在 ISC 工作满二十年并获任 Distinguished Engineer，也描述了稳定版和扩展支持版之间为平稳迁移保留的支持重叠期。重叠不是日历上的冗余，而是一种治理安排：运营者可以比较、分阶段部署并在必要时回退，而不是把发布日期当成命令。

ISC 当前的团队页面仍把 Andrews 列为 Distinguished Engineer。职衔能够记录机构责任，却不能证明任何一台名称服务器正在运行什么。生产事实仍在下游：软件包、配置、进程状态、查询行为和运营记录之中。

因此，一份可信的替代台账至少应回答六个问题：承诺了什么能力？哪些工作负载现在得到支持？哪些功能仍缺失？过渡期间谁维护现行系统？每个运营者依据什么完成切换？切换后还保留什么回退路径？若这些状态没有被拆开，路线图就会冒充部署，发布公告也会冒充迁移。