摘要

  • RFC 3646 的选项 23 按客户端偏好顺序列出递归服务器，选项 24 提供仅用于 DNS 的搜索列表；两者都不证明主机已经安装或实际采用。
  • 可靠的运行证据必须保留配置来源、手工优先级、原始名称、后缀扩展、实际服务器、响应、验证状态和应用结果之间的连接。

可以把一次名称解析拆成六张独立收据。第一张说明 DHCPv6 消息携带了什么；第二张说明本机策略接受了什么；第三张说明解析器当时安装了什么；第四张说明短名称怎样变成查询名称；第五张说明请求发给谁、得到什么；第六张说明应用是否使用了预期身份。缺少任何一张，都不能让前一张代替后一张。

RFC 3646 定义两个选项。OPTION_DNS_SERVERS 的代码是 23，内容是一个或多个 IPv6 递归服务器地址，并按客户端解析器的使用偏好排列。OPTION_DOMAIN_LIST 的代码是 24，内容是 DNS 主机名解析所用的域搜索列表，不适用于其他名称解析机制。纯文本版本还限定两者只能出现在 Solicit、Advertise、Request、Renew、Rebind、Information-Request 和 Reply 中。

“偏好第一”只描述配置语义，不是可达性检测，也不是实际选择记录。地址可以被收到却未被接受，可以被安装却被另一来源覆盖，也可以先尝试后失败转移。缓存甚至可能让本次调用没有发出网络查询。因此，抓到选项 23 不能直接推出某台服务器处理了某次请求。

选项 24 更进一步改变了被查询的名字。短名称会与一个或多个后缀组合。RFC 1535 与 RFC 1536 解释隐式搜索列表和含点名称的风险。RFC 3646 引用这些纪律，但运行审计还必须记录应用提交的原始字符串、后缀尝试顺序以及最终命中的候选名称。只保存“查询成功”会丢掉最关键的意图证据。

认证也只解决一层。RFC 3646 建议客户端在安装递归服务器列表或接受搜索列表之前要求 DHCP 认证，因为恶意 DHCP 服务器可以把请求引向其控制的解析器或无效域。然而，通过认证的来源仍可能配置错误，服务也可能不可用。RFC 4033 所描述的 DNSSEC 也不能修复名称意图：错误搜索域里的记录完全可能由该域合法签名。签名证明该名称下的数据来源，不证明这个名称是用户原来想找的对象。

标准还给本机控制留出明确位置：已经手工配置的 DNS 服务器或搜索列表不应被 DHCP 覆盖。这意味着线上的 Reply 不是最终状态。要证明安装结果，必须同时看到手工配置是否存在、优先级策略如何执行、自动配置是否被接受，以及解析器随后暴露的有效状态。

来源不只一个。RFC 8106 允许路由器通告递归服务器和搜索域。DHCPv6 与 RA 可能给出相同地址，却拥有不同的来源身份与生命周期。如果配置系统只按值去重，就会把“为什么这个值仍然有效”的答案删除。

规范沿革不能替代现场证据。RFC 3315 是原始 DHCPv6 基础规范，后来由 RFC 8415 取代；RFC 8504 记录 IPv6 节点要求。这些材料能够界定实现义务，却不能证明某个主机在某个时刻的内部状态。

RFC 1034 的 DNS 架构与 RFC 1035 的消息机制说明了解析流程。RFC 3397 提供 DHCPv4 搜索域选项的对照。它们帮助解释机制，但都不能从一条 DHCPv6 日志重建具体查询。

IANA DHCPv6 参数登记表为代码 23 和 24 提供共同词汇。登记只证明编号得到协调，不证明广告、接受、安装或结果。Datatracker 页面、RFC Editor 信息页、勘误记录与文档历史同样只界定规范来源，不是部署遥测。

Lu Heng 关于运行代码优先、最小初始规范和现实分层的论述，为这里提供了一条管理准则：共同标准负责互操作，本机政策保留选择权，实际运行状态约束事实主张。不能因为协议字段统一，就把每一层权力和结果统一解释。

完整证据链应包含接口与网络、DHCP 服务端身份、认证结果、消息和选项字节、手工配置优先级、采纳决定、分来源生命周期、解析器有效状态、应用原始名称、候选名称序列、实际服务器和传输、缓存状态、DNS 响应、DNSSEC 结论以及应用观察。不能连接的部分必须保留为不确定性。