RFC 5223：DHCP 给出的 LoST 域名不是权威证明

Summary

RFC 5223 定义 DHCPv4 选项 137 与 DHCPv6 选项 51，用来交付一个以根标签结束的 LoST 服务器 FQDN。这个名称只是 DNS/U-NAPTR 发现过程的输入，不是服务器地址、权威身份、映射答案或应急服务完成凭证。
管理层需要一张发现链收据，分别记录 DHCP 来源、选项解析、FQDN、解析视图、U-NAPTR 结果、选中服务、LoST 安全、映射以及下游结果。

终端接入网络，向 DHCP 请求 LoST 选项。返回值长度正确，标签能够解码，最后只有一个根标签，配置代理把域名保存下来。从 DHCP 系统的角度看，这次操作成功了。

但成功交付的只是一个名称。它没有说明谁有权为这台终端选择 LoST 发现命名空间，也没有说明 DNS 和 U-NAPTR 会返回什么，更没有证明解析出的服务是真实权威、映射仍然有效，或应急请求最终有人回应。

RFC 5223 的约束非常具体：IPv4 使用选项 137，IPv6 使用选项 51；载荷只有一个完全限定域名。客户端把它交给 LoST 所采用的 DNS/U-NAPTR 解析过程。标准并没有把后续每一步折叠进“已发现”。

因此，接入网络提供的是入口，不是整条链的担保。

域名使用 RFC 1035 标签编码，每个标签前有长度字节，整体不超过 255 字节，选项必须包含且只包含一个以根标签结束的域名。这些规则让实现能够拒绝畸形载荷。

然而，语法无法证明来源。客户端还要知道哪个 DHCP 交换交付了这个值、哪个管理主体被授权这样做。随后，FQDN 进入 DNS/U-NAPTR；解析结果会随时间、递归解析器视图和接入网络而变化。最终 URI 或地址又指向另一个运行主体，其身份与 LoST 安全仍需验证。

再下一步才是 RFC 5222 的映射过程：提交位置、映射来源、过期时间、边界和服务目的地都属于另一组证据。即使映射给出 URI，也不能证明应答者接起请求。每层输出是下一层输入，却不是下一层结论。

RFC 5223 允许接入网络提供自己运营的 LoST 服务器域名，或提供它所知道的第三方域名。这很实用，也意味着接入网络影响客户端进入哪个发现命名空间。

运营 DHCP 的主体不一定运营 DNS；DNS 主体可能把 U-NAPTR 记录委托给另一方；解析出的 LoST 服务又可能属于第三方；应急服务端点还在更远处。若把 DHCP 运营者当作全链担保者，实际控制边界就消失了。

有效记录应回答：谁批准 DHCP 选项，谁拥有域名，谁控制相关 DNS 记录，预期的 LoST 身份是什么，谁能撤销错误委托，同一接入类别为何突然收到不同域名。没有这些信息，“本地”只是拓扑描述，不是问责关系。

RFC 5223 明确指出，攻击者若能修改 DHCP 响应或插入自己的响应，就可能让客户端联系受其控制的恶意 LoST 服务器，或获得无效地址。错误发生在 LoST 请求之前。DNS 解析器完全正常，也无法修复一开始就由恶意响应选择的域名。

反过来，真实 DHCP 响应也不能自动保障后续解析。DHCP 来源、DNS 一致性、U-NAPTR 解释、服务器认证、LoST 协议保护、映射新鲜度与下游可达性各自回答不同问题。

失败状态也必须分开：没有选项不同于选项畸形；合法 FQDN 没有可用 NAPTR 结果，不同于结果指向未认证服务；安全服务没有映射，又不同于映射目的地不可达。只有保留这些差异，运营人员才能定位责任。

RFC 5223 认为 LoST 服务器靠近终端是可取的，并指出在灾害导致网络间歇连接时可能带来韧性收益。这是设计理由，不是某个现网的延迟、可用性或应急表现测量。

拓扑更近也不等于由接入商控制，不等于对所有位置具有权威，不等于故障后仍可达，更不等于与其他映射系统同步。韧性必须沿实际依赖链观察：DHCP 更新、解析器可用性、记录新鲜度、服务认证、映射响应和后续通信。

因此，“发现了本地服务器”不能直接成为韧性指标。组织应公开依赖图，并测试设计声称能够承受的故障组合。

这些标准没有证明选项 137 或 51 的当前部署，没有指出被入侵的 DHCP 服务器、恶意 LoST 服务、失败的应急请求或厂商缺陷。RFC 3315 是 RFC 5223 使用的历史 DHCPv6 依据，后来由 RFC 8415 取代；这一本身不能证明 LoST 选项今天是否被使用。

本文也止于已经另文覆盖的 RFC 5222 边界之前，不重复映射正确性与服务送达。结论更早也更窄：DHCP 域名只是发现输入，其后的权威与结果必须逐层证明。

每次发现应记录接入网络、DHCP 版本、可获得的服务器身份或来源、选项代码、原始载荷哈希、解析结果、FQDN 与根标签有效性、租约或观察时间、解析器视图、U-NAPTR 记录、TTL、选中 URI 和地址、服务身份验证、LoST 请求/响应标识、映射年龄、下游尝试与应用结果。

负面证据也要保留：缺失选项、竞争响应、畸形标签、意外域名变化、NAPTR 处理失败、解析器视图不一致、过期记录、认证失败、退回手工配置和服务不可达，共同定义真实发现面。

按照 Lu Heng 对运行事实与可归责主体的强调，接入网络只能证明自己的 DHCP 配置，域名运营者证明 DNS 委托，LoST 运营者证明服务行为，应用证明下游结果。管理层应要求完整链条，不能让一个主体的回执替其他主体发言。