摘要

  • RFC 2010 要求每台根服务器留下多种彼此独立的证据：及时更新的软件、UDP 校验和、至少两个经过认证的时间源、单一对外接口、受控机房、冗余电力与网络、容量余量、安全日志、受限区域传送、关闭递归和明确的联络与停机报告。
  • 它明确不处理站点与管理员如何产生，也不规定不合规后怎样处置；所以机器符合清单，不等于任命正当、根区内容正确、全球都能访问或违规一定受到处理。

一台机器显示两个准确时钟，能证明什么？RFC 2010 的回答很克制：至少说明运营者没有把整个运行历史押在单一时间来源上。文件要求根服务器从不少于两个经过认证的 NTP 服务器取得时间；它还要求保留安全相关日志。时间与日志合在一起，使“发生过什么、何时发生”第一次更像可复核的运行记录，而不只是管理员事后的回忆。

1996 年的背景仍是由高能力志愿者提供服务、由 Network Information Center 松散协调的共同体。RFC 2010 并没有消除这种人际结构。它做的是把“相信这位管理员”拆开。文件所称的 zone master——当时写作 IANA——选择服务器软件，并可要求运营者在 96 小时内更新。所有响应要带 UDP 校验和；服务器应使用专用主机，不运行无关服务，远程管理应加密；对外只广告一个网络接口，即使内部存在多个物理接口。

从一台机器分离出的证据层

机房访问要受控，电力和网络连接要有冗余，安全事件要写入日志。服务器应能以平均每秒 1200 个查询、低于五毫秒响应的历史指标运行，每秒 2000 个被列为理想值。这个数字不能挪作今天的容量标准，却揭示了当时的治理方法：把“足够可靠”变成可以压测、可以留下余量的命题。

区域传送也被分层。AXFR 只应向获准对象开放，同时保留通过 FTP 取得完整区域，并支持 NOTIFY 与 IXFR。递归通常必须关闭，只有缺失 glue 的窄例外。普通邮件应在 24 小时内答复；非计划停机或提前不足 24 小时的停机还要电话通知。计划停机、紧急事件与恢复结果不是同一条记录。

这些证据不能互相冒充。UDP 校验和描述一次响应，不证明根区内容正确；两个时间源描述时钟，不证明每个用户都能到达；双路电源描述设施，不证明两路没有共同故障点；停机邮件证明通知发出，不证明服务恢复。RFC 2010 的价值恰恰在于把根服务拆成多层现实，而不是制造一枚“合规”印章。

清单尽头仍有权威空白

文件明确排除站点与管理员的选择，也不规定违规处理程序。因此，运行清单能约束某台服务器该提供什么证据，却不能回答谁有资格运行它、谁有权裁定失败、如何执行制裁。一台机器可以技术上合规而任命逻辑仍受质疑；也可能技术上不合规，而文件本身不给出处置机关。

RFC Editor 记录也限定了历史结论：RFC 2010 是 Informational，现列为 Legacy，并非 IETF 背书的建议，后来被 RFC 2870 取代；RFC 7720 再描述更晚的根名称服务要求。继承关系证明文本演化，不证明 1996 年清单当时全面落地。

Lu Heng 的三个视角把结论压回证据。运行代码优先要求观察配置、日志与结果；最小初始规范把共同清单看作协调起点，而非自动生效的中央命令；现实分层则禁止把文本、部署与用户体验合并。RFC 2010 的历史转折不是权力集中，而是把个人声望转换成可被证伪的运行回执。

来源