摘要

  • RFC 1535 区分了以根点结尾的绝对域名与未以根点结尾、可能被搜索规则补全的名称。在其示例中，用户输入一个名称，解析器却能按顺序生成四个不同的 DNS 查询。
  • 从 Machine.Tech.ACES.COM 输入 UnivHost.University.EDU 时，第三个候选会落到 EDU.COM. 之下；一旦该公共分支的记录先应答，搜索就可能在真正想查询的 UnivHost.University.EDU. 之前停止。
  • 修正方案没有取消本地简称，而是限制隐式搜索的管理边界、优先把含点名称按根域名尝试，并要求额外候选通过显式配置产生。该文档是 Informational，不能证明受影响规模、实际入侵、当前解析器行为或最终端点身份。

便利账与控制账

在一个校园或企业网络里，用户不必每次输入完整域名，确实是有价值的。printer、mail.lab 一类简称减少输入，也延续了局部网络形成的工作习惯。若只记便利账，搜索列表是一项温和的用户体验功能。

控制账问的是另一件事：缺少的部分由谁补，补到哪里为止，候选按什么顺序竞争，什么回答足以让搜索停止。

RFC 1535 给出的关键场景发生在名为 Machine.Tech.ACES.COM 的机器上。用户输入没有末尾根点的 UnivHost.University.EDU。一些源自 BSD BIND 的解析客户端可能依次尝试：

  1. UnivHost.University.EDU.Tech.ACES.COM.
  2. UnivHost.University.EDU.ACES.COM.
  3. UnivHost.University.EDU.COM.
  4. UnivHost.University.EDU.

屏幕上只有一个输入，网络上却可能出现四个问题。前两个候选仍可理解为组织内部的补全。第三个候选已经进入 EDU.COM. 这个可以由另一方注册、管理的公共分支。第四个才是与用户所写标签最直接对应的根域名。

这意味着“输入是什么”与“DNS 被问了什么”之间存在一段可执行政策。只保留终端记录，会看见用户的字符串；只保留成功查询，会看见解析器生成的名称。两份证据都没有说谎，却都无法单独还原是谁作出了改写决定。

IETF Datatracker 条目与 RFC Editor 资料页确认该文档于 1993 年 10 月以 Informational 发布。纯文本档案可用于交叉核对，勘误页面则把文档订正另行记录。这些资料证明文档与其中的描述存在，并不提供装机量、事故数量或今天的软件结论。

根点限制的是改写权，不是身份风险

在该语法约定中，末尾的点把名称标记为从 DNS 根开始的绝对名称：UnivHost.University.EDU.。没有这个点时，相同标签串仍可能被当作相对名称，交给本地原点或搜索列表补全。

这个点不是密码学证明。它不能证明回答者就是用户想找的机构，不能证明缓存新鲜，不能证明传输连接、证书、主机密钥或应用授权成功。它作出的声明很窄：不要再把这个名称相对于别的后缀解释。

这种相对与绝对的区分并非 RFC 1535 新创。RFC 1034及其 STD 13 资料页已经说明，相对名称可以依照原点或搜索列表解析，也承认用户界面的解释方式随实现而异。RFC 1035与其资料页提供 DNS 消息、资源记录与解析器的配套背景，但并不证明 1993 年所有产品采用同一默认值。

问题因此不是“相对名称一律不安全”。在已知且受控的局部环境里，相对名称是合理工具。问题在于解析器从本机全名推导搜索路径，却不知道同一个管理者的权限在哪一层结束。

字符串可以逐层缩短，管理权不会随之连续

对程序而言，Tech.ACES.COM、ACES.COM、COM 只是每轮删掉一个标签。对现实中的管理关系而言，它们不是同一个机构的三种长度。

ACES.COM 的管理员可以承诺 Tech.ACES.COM 或 ACES.COM 下某些本地补全的含义。它没有权力替 .COM 下所有可注册名称作出承诺。一旦算法删掉 ACES，下一个候选就离开了本地管理范围。

这里发生的不是 DNS 委派规则失效。EDU.COM 的权威服务器若收到 UnivHost.University.EDU.COM. 查询，本来就有权为自己的区域回答。失效的是前一层：解析器让这个合法回答参与了对用户原始意图的竞争。

因此，字符串后缀的包含关系不能证明管理权连续。一个看似机械的循环，实际上每走一步都可能跨越制度边界。若没有“本地管理到此为止”的参数，解析器就会把语法相邻误当成权力相邻。

EDU.COM 让隐藏的越界变成可回答的查询

RFC 1535 报告称，EDU.COM 已被注册，其下存在通配 CNAME，可把形如 *.edu.com 的名称导向一个目标；文档还以 harvard.edu.com 说明可能的冒用场景。

必须严格限定这段证据。它是 1993 年文档记录的配置与风险，不证明今天仍有同样通配记录，不证明发生过已测量的凭据窃取，也不能推导所有 BIND 版本或解析器都有相同行为。

它真正揭示的是停止条件。若第三个候选返回某个资源记录，解析器就可能把搜索视为成功，不再发出第四个根域查询。于是，一个由软件生成、用户从未输入的名称，因“先有答案”而获得了最终解释权。

“解析成功”在这里是危险的压缩词。更准确的说法应是：特定版本的解析器依据特定列表和顺序生成候选，其中一个候选从权威服务器或缓存得到回答，某条停止规则选择了它，随后应用拿到一个地址或规范名。至于是否连接、是否验证端点、是否授权、是否产生用户可见结果，仍需分别证明。

搜索列表是一段程序，不是一列装饰

配置界面常把搜索域展示成若干行文本，但其运行语义至少包含四个决定：

  • 哪些输入可以被扩展；
  • 可追加哪些后缀；
  • 候选以什么顺序尝试；
  • 哪类回答让搜索停止。

同一组后缀换个顺序，可能让不同管理者先回答。同一顺序若改变 NXDOMAIN、CNAME 或记录类型的处理方式，终止点也会变化。缓存若直接提供结果，网络抓包甚至看不到本次决策的查询。

RFC 1123及其主机要求资料页把简称设施视为可选项。它要求提供完整名称的输入约定，并要求把用户输入转换为完整域名的动作在正确上下文中只执行一次，同时允许管理员关闭搜索列表。

这份规范还另行约束根服务器负载：主机在发出非本地查询前，必须采用否定缓存，和/或要求名称至少含有一定数量的内部点。这个门槛管的是查询流量，不是由谁解释用户输入；它只能补充本地管理边界与候选顺序，不能取代二者。

“只执行一次”是责任边界。若应用先补一次、系统库再补一次、代理层又重新解释，最终名称无法说明哪个组件引入了哪段语义。即使碰巧得到正确结果，路径也难以复现。

修正没有禁止简称，而是撤回隐式的普遍授权

RFC 1535 提出的最低修正，是参数化本地管理边界。解析器可以在组织确实控制的后缀内补全，但不应随着本机域名逐级缩短，一直走进公共名称空间。

文档还描述了 BIND 4.9.2 更窄的隐式行为：减少自动尝试的形式；当输入已经包含点时，先把它当作根域名尝试。若组织仍需要多标签本地简称，可以在显式搜索列表中配置。

“含点先按根域名尝试”不是“任何含点字符串都天然完整”。有些局部命名习惯确实需要 service.lab 再追加组织后缀。修正的要点是，这种例外应由本地管理员明确声明，而不是由通用解析器默认推断，更不能自动扩展到管理员不控制的公共分支。

显式配置也可能错。后缀可能过期、排序可能不当、管理范围可能变化。它的优势在于可追责：配置有来源、有版本、有批准者，可以审计与撤销。隐藏启发式只有在外部名称开始回答时，才让人发现它一直拥有如此宽的权力。

“少敲字符”不能替别人承担后果

搜索列表的收益集中在本地：用户输入短、旧脚本继续工作、帮助台少接一些“找不到主机”的请求。风险却分散并延迟出现。

当公共候选开始回答，安全团队可能调查错误端点；应用团队可能面对身份不匹配；外部域名运营者可能收到从未被人有意寻址的流量；最终用户可能只看到一次奇怪的登录界面。保留宽松搜索规则的人，并不一定承担这些成本。

若仪表盘只奖励 DNS 成功率，错误公共分支开始回答会被记作改善。若只奖励低时延，最快的错误候选会被当成最优路径。度量必须加入行政边界和候选来源，否则便利会被优化成越权。

Heng Lu 的最小初始规范、局部未来决定与自愿采用可以作为后来的编辑视角：共享规则保持最小，把局部选择留给局部并保持可逆。这里借用的是分析框架，并非声称 RFC 作者当时采用了这套表述。

文档、实现、回答与结果必须分层

RFC 的 Informational 状态证明它是一份公开技术记录，不证明某个运行系统符合或不符合它。要判断真实行为，需要二进制、库版本、配置来源、进程时期与查询轨迹。

一次 DNS 回答也不等于预期身份。运行代码优先要求把实际执行与制度标签分开；现实层、象征权力与清晰性则提醒我们，不要把用户输入、补全政策、候选查询、DNS 回答、端点认证和应用结果压成一个“已解析”状态。

同年的相邻文档也有各自边界。RFC 1536及其资料页整理流量、重试、递归与缓存相关的实现错误；RFC 1537及其资料页讨论 DNS 数据文件常见问题。它们说明当时正在系统化辨认运行故障，却不能代替 RFC 1535 这条特定的候选生成路径。

真正需要保留的是候选账本

一次可复现的解析记录，应从原始输入开始：完整字符串、是否有末尾根点、调用应用、是否请求搜索扩展、解析库与版本、进程或名称空间时期、配置来源、搜索列表顺序、管理边界与政策版本。

随后逐个保存候选：生成原因、查询时间、传输方式、响应码、权威或缓存来源、回答内容、CNAME 链，以及继续或停止的决定。最后才记录选中的规范端点、传输建立、TLS 或其他认证、应用授权与观察到的结果。

这个账本不应复制密码或秘密材料。对敏感操作，可以保留受限指纹、目的端身份与授权结果。关键是不能让最终 IP 地址覆盖生成它的决策链。

RFC 1535 的长期价值，不是提醒用户记住一个标点符号，而是指出：任何自动补全标识符的软件都在行使解释权。解释权只有在范围属于本地、候选可见、顺序确定、停止条件可审查、结果仍需独立认证时，才是受约束的便利，而不是隐藏的委派。

来源