摘要

  • DHCPv4 的 LoST 选项代码是 137，DHCPv6 的代码是 51；二者都编码一个而且只有一个 FQDN，不是 IP 地址、URI 或服务器优先级列表。
  • 域名随后要进入 U-NAPTR 与 DNS，再经过地址选择、传输连接、服务身份核验和 LoST 协议交换。前一步成功不会自动替后一步作证。
  • 最危险的不是某一层失败，而是把“选项解析成功”保存成“LoST 已发现”，从而永久丢失谁给了这个名字、系统又验证了什么。

一个过早变绿的仪表盘

下面是一段构造出来的审计时间线，并非真实事故。08:14:00，终端接入网络并请求配置。08:14:01，DHCPACK 携带代码 137 的选项，原始字节可正常解码为 lost.access.example，最后恰好有一个 DNS 根标签。08:14:02，监控把“LoST 发现”标成绿色。

此时没有任何 U-NAPTR 查询结果，没有 DNS 地址，没有验证状态，没有建立连接的对端，没有 TLS 服务身份结果，也没有 LoST XML、映射版本、联系 URI、呼叫尝试或接听记录。解析器完成的是语法工作，仪表盘却替它宣布了权威、可达与业务结果。

RFC 5223 的边界清楚得多。若接入网络自己部署 LoST，或知道由第三方运行的 LoST 服务，它可以把一个域名交给终端。终端再把这个域名交给 LoST 的 DNS 发现过程。RFC 没有让 DHCP 直接返回最终映射，也没有让接入网络凭一个选项代表下游所有系统。

发现是动词链，而不是一个状态：收到、解码、解析、选择、连接、核验、查询、映射。省掉任何一个动词，都会把尚未发生的事实写进已经完成的记录。

标准只给一个名字

IPv4 使用 OPTION_V4_LOST，代码 137；IPv6 使用 OPTION_V6_LOST，代码 51。域名按 DNS 标签格式编码，每个选项必须包含一个完整域名，并以唯一根标签结束。客户端可通过相应的参数请求列表或选项请求机制索取它。

这个“一个”很重要。字段不是服务器清单，不含排序或故障转移规则。它不是最终 IP，不是 LoST URI，也没有替应用规定跨网络移动后的缓存寿命。图注里出现的“List”不能推翻正文明确的单一域名要求。

审计系统至少要保存选项代码、长度、原始字节、解码后的 FQDN、语法检查结果与 DHCP 事务上下文。只存字符串，就看不出错误编码是否被宽松接受；只存 present=true，就无法发现值变化；把后续 DNS 得到的 IP 回填到 DHCP 事件，则会制造一条不存在的来源链。

IANA 代码点也不比这更宽。它协调实现对字段的共同理解，却不担保每个携带该字段的报文都来自合法配置者。共同语法不是共同授权。

“网络提供”必须能回答是哪张网

RFC 2131 规定 DHCPv4 的发现、选择、确认与租约，RFC 8415 给出当前 DHCPv6 基础。这些协议可以证明某次配置交换中，客户端从哪条 DHCP 路径接收了什么。

DHCP 服务器标识属于这次配置交换。它不会自动变成 LoST 服务的运营者身份，更不会证明对端对所有地点拥有映射权威。RFC 3046 的中继代理信息可以帮助定位接入路径，但路径元数据不是服务证书。

移动设备尤其容易暴露错误。终端可能从企业 Wi-Fi 切到移动网络，也可能在休眠后继续使用旧应用状态。一个域名在原接入环境中合理，不代表它在新环境中仍合适。系统必须把 FQDN 与接口、管理域、事务标识、服务器、中继、接收时间和租约状态绑定，并记录何种事件触发重取或失效。

若实现只保留最后一个域名，“网络提供”最终会失去时间和主体。它变成一句无法审计的被动语态。

RFC 明说攻击者可以替换指针

RFC 5223 的安全章节指出，攻击者若能修改 DHCP 响应或插入自己的响应，就可能把客户端引向受其控制的伪造 LoST 服务器，或者给出无效地址。RFC 5069 从应急呼叫标记与映射的角度讨论了这类风险。

RFC 3118 定义 DHCP 报文认证和重放相关保护。它证明“报文来源、完整性与新鲜性”是独立控制面，却不证明现实中的每个网络都部署了这些机制。审计应写“本次是否核验、结果是什么”，不能把可用标准写成已执行事实。

即便 DHCP 响应通过认证，其内容仍可能配置错误或过期。接入运营者有权为本地终端提供配置，不等于它对每个应急服务辖区都有最终决定权。认证能约束说话者，不能把说出的每个值变成永恒真相。

Heng Lu 的运行代码原则要求把权威放回实际决策点：客户端能证明自己消费了哪份配置、进行了哪些校验、暴露了什么状态。它不能替 DNS 解析器、TLS 对端、LoST 权威或接警机构作证。

域名后面还有 DNS 与身份

RFC 5223 把 FQDN 交给 RFC 5222 周边定义的 U-NAPTR/DNS 发现链。系统仍需找到匹配的服务记录、选择目标与传输、解析地址、建立连接，并确认服务身份。

一个格式正确的域名可能没有合适记录；DNS 可以超时；地址可以不可达；对端身份可以与预期不符。RFC 8446 保护 TLS 通道，RFC 9525 处理服务身份。若上游选择已被带偏，成功加密只会安全地连接到错误对象。

因此 DNS 证据不应只写“成功”。它需要保留查询、返回记录、TTL、验证状态（如适用）、候选地址、实际选择与时间。连接证据要保留端点与身份判断。这样，当 DHCP 选项保持绿色而连接失败时，问题才不会被错误归入“LoST 服务不可用”。

RFC 8917 为 LoST 验证服务定义单独的 S-NAPTR 应用服务标签。这说明发现层可以区分角色；标签表明客户端要找哪类功能，却不保证对端把功能执行正确。

找到服务也还没有拿到映射

DNS 与 TLS 都通过之后，客户端才有条件发出 LoST 请求。响应仍可能是错误、警告、重定向或带有独立来源、时效与边界条件的映射。

已经发布的 RFC 5222 文章拥有后半段论题：映射返回 URI，不等于呼叫已建立或有人接听。本篇不重复它。本篇只指出更早的一层：DHCP 给出的 FQDN 也不能预先证明未来映射正确。

RFC 6739 保护 LoST 服务器之间的映射同步与来源。后端签名并不能反向认证终端收到的 DHCP，也不能证明终端看到的 DNS 或连接的对端。两条证据链只有在保留标识与时间后才能真正相接。

RFC 6881 把发现放回应急通信的完整实践。定位、接入配置、发现、映射、信令和服务响应互相依赖，但每个环节都只能为自己观察到的事实负责。

应保存的最小证据链

顺序记录：接入接口与网络；DHCP 事务、服务器和中继；报文保护结果；原始选项与 FQDN；租约和失效决定；U-NAPTR 选择；DNS 结果与 TTL；TLS 服务身份；LoST 请求响应；映射适用性；会话建立；接听与服务结果。

管理层不需要把十二项全部放在首页，却必须确保底层记录没有被一个布尔值覆盖。简洁展示不应以不可恢复的证据损失为代价。

来源

  1. RFC 5223
  2. IETF Datatracker 上的 RFC 5223
  3. RFC 5223 状态
  4. RFC 5223 历史
  5. RFC 5223 勘误
  6. RFC 2131
  7. RFC 2132
  8. RFC 8415
  9. RFC 3118
  10. RFC 3046
  11. RFC 5222
  12. RFC 5069
  13. RFC 6881
  14. RFC 8917
  15. RFC 6739
  16. RFC 8446
  17. RFC 9525
  18. Heng Lu — 运行代码优先
  19. Heng Lu — 最小初始规范、本地未来决策与自愿采用