摘要

  • RFC 9704 允许客户端把本地收到的子域声明，与公共父区中的核验值对照；证明内网解析器获得授权，不必在公共 DNS 中列出全部内部名称。
  • 解析器自身的认证域名仍会出现在公开记录的名称里。把业务秘密写进这个名字，不能靠隐藏子域清单补救。
  • 把内部服务集中在一个子区，可以减少公开记录的变更次数，但也把更多未来命名决定交给了子区的管理者。

假如一个尚未公开的项目，被谨慎地藏在内网域名之下，负责它的解析器却直接以项目命名，那么一份用于说明解析权限的公开记录，就可能把项目线索留在外面。这是一个说明设计取舍的假设，不是本文发现的泄露事件。

这个例子有意思的地方，在于并不需要密码学失效。子域清单可以没有进入公共 DNS，核验过程也可以完全正确；真正多说了一句话的，是公开记录必须携带的另一个名称。对保密边界的误解，发生在设计时，而不是攻击时。

RFC 9704 把这类问题变得具体。企业希望部分名称只在内部得到特定答案，客户端又可能已经为日常查询选择外部加密解析服务。为了打开少数内部服务，就把所有查询改交本地处理，是一种范围较大的解决办法。反过来，完全不接受内网的解析安排，也会丢掉那些服务需要的特殊视图。

如何只接受有依据的例外，又不把内部目录公开，才是这项规范值得讨论的地方。

一份声明，面向两种读者

2025 年 1 月发布的 RFC 9704 是标准轨文档，针对能够组合不同解析方式的客户端。它要求名称扎根于全球 DNS，解析器使用经过认证的加密连接，并由相应父区参与授权。它不适用于用同样办法证明某个网络独占 local. 等特殊用途名称，也不赋予网络过滤别人的域名的权限。

网络把声明交给客户端，说明哪一个解析器、在哪一个父区之下、准备为哪些子域提供本地权威答案。父区认可后，公开的是经过规范化处理的子域集合与随机盐值所对应的哈希核验值，而不必公开那张子域清单。客户端已经在本地拿到声明，可以计算预期结果，再查证父区中的记录。

这里的哈希不是“加密后的内部通讯录”，盐值也不是向接收声明的客户端保密的密码。它解决的是公开 DNS 需要披露多少内容，而不是承诺所有参与者都不知道内部名称。

因此，两个看似冲突的目标可以拆开：外部可核验的批准，与内部才能获得的具体目录，不一定要用同一种公开程度。要求对一项权限负责，并不天然要求把所有相关数据放到同一个开放页面。

不过，公开记录省略了清单，不代表机构内部也可以不留清单。若内部审计只保存一个核验值，而没有对应的解析器、范围、用途和批准人，以后就很难说明当时到底同意了什么。向外少披露，不能以向内失去记忆为代价。

IANA 的配置域登记表 已列出 splitDnsClaims 及解析器、父区、子域、算法和盐值五个字段。这说明交换声明有共同词汇，却不能说明某一型号客户端已经实现，也不能证明某一家企业真的按这个过程部署。字段登记与实际运行，仍是两种证据。

清单可以藏，代表它的名字未必能藏

公开 TXT 记录的名称包含解析器的认证域名，以及固定的核验标记和父区名称。RFC 9704 的安全讨论明确提醒，这会暴露获准解析器的名字；如果名字本身带有敏感业务含义，泄露就从这里发生。

所以，命名不是最后交给运维补齐的一项格式工作。公开可见的解析器身份，应当经过专门的披露审查。即使没有直接写出项目名称，一串看似无意义的内部代号，也可能被熟悉机构命名习惯的人识别。

这一点不意味着必须让基础设施彻底隐形。更可执行的目标是：承认哪些身份信息需要公开，刻意避免把无关业务细节附带公开，并清楚知道哪些参与者仍会看到内部声明。

对服务商的安排尤其如此。加密查询只保护传输路径，并不会让解析器看不见自己处理的查询。RFC 9463 在讨论加密 DNS 的隐私时明确保留了这个限制。若把内部视图提供给外部服务商，就应当讨论对方能看到什么、为何需要看到，以及如何使用这些信息，而不能只展示一项“传输已加密”的状态。

ASD 的 ACSC 在网关技术指引中也要求机构在向外部服务商暴露内部视图之前考虑信任与威胁模型，并提醒不要把依据 IP 地址选择答案的分视图 DNS 当成安全机制。该指引引用 RFC 9704，说明这种设计进入了官方技术建议的讨论；它不是对任何现成设备支持率或实际安全效果的证明。

知道内部名称和取得应用权限，同样不能合并。一个服务的地址能够解析，不等于访问者已经通过登录、身份验证或业务授权。反过来，名字没有在公共区域中列出，也不能替代服务本身的访问控制。

不让声明者包办证明

一份公开批准要有意义，客户端核验时就不能让本地网络随意改写所依据的答案。RFC 9704 提供两条路径：沿用事先配置的外部加密解析服务，或者在本地完整验证核验记录的 DNSSEC 保护。

第一条路径不能为这次核验降低平常的接受条件。外部服务在合理时间内没有响应，意味着核验失败，不意味着本地声明自动有效。第二条路径也区分不同状态：安全验证成功才可使用，伪造或无法判定的结果被拒绝；遇到未签名状态，可以按规范尝试另一条核验路径，若不重试则视为失败。

这不是为一个内部网站设置多余障碍，而是避免网络以“只有我能告诉你”为理由，独自证明自己应当掌握哪些名字。服务确实需要访问，不能成为放弃确定权限来源的理由。

发现解析器和确认域名范围仍各有职责。RFC 9463 提供认证域名、地址与服务参数，其证书检查回答的是连接对象是否匹配所提供的名称，不是网络配置来源是否可信。RFC 9704 所增加的，是父区对于指定解析范围的许可。一个证书有效的解析器，不会因此自动得到整个企业域名空间。

少改几次记录，意味着多批多少范围？

把内部服务集中在一个子区之下，可以让新服务在既定范围内增加，而不必每次都改变公共父区中的核验记录。RFC 9704 推荐这种组织方式，是为了降低更新频率；它同时说明，这不是避免内部名称泄露的必要条件。

这里有一项值得管理者直接判断的取舍。逐个批准名称，可以收紧范围，却可能让每次业务调整都需要跨团队协调。批准一个稳定子树，能把日常命名工作交给内部运营团队，但也给了这个团队在既定范围内增加未来名称的空间。

如果审查只看眼前已经存在的几个服务，就容易忽略后一个决定。子树批准并不只覆盖审批表截图里的那一刻。它还影响以后哪些变更不再需要回到父区重新取得批准。

合理范围取决于组织分工，而不是越小或越大越先进。用途明确、权限敏感的服务，可能值得更细的批准；由同一团队持续运营的内部平台，可能更适合稳定子区。直接覆盖整个父区，则需要对更广的委托作出解释，不能只以减少工单作为理由。

更新也不是一次保存就同步结束。规范要求先增加新的公开核验记录，再更新对应本地声明；旧记录还要保留到相关 DHCP 租期或配置域附加信息到期。客户端会在核验记录接近有效期终点时重新检查。RFC 8801 另行规定配置域信息的有效期、序号变化和重新获取行为。公共批准与本地声明走的是不同分发路径，需要协调，而不是被一个界面按钮合并成同一时刻。

本文没有运行实现测试，也没有给出设备普及率、泄露统计或节约成本的估计。可以从文档中得出的实际启示是：要让例外长期保持狭窄，就必须给维护这项例外的人留出协调能力。否则，最容易出现的“优化”，不是更好的工具，而是悄悄把一次批准的范围扩大。

可核验与有保留地披露，并非只能二选一。关键在于公开哪项承诺、保留哪些细节，以及谁有权把今天的例外变成明天的常态。