摘要

  • RFC 8005 的 HIP 资源记录可保存公开的主机身份 HI、其 HIT，以及可选的会合服务器名称；它是发现资料，不是端点存活证明。
  • DNSSEC 验证说明 DNS 数据在既定信任链下成立，TTL 说明缓存何时可以复用。两者都看不到 RVS 中当前的 HIT—地址注册，也看不到私钥此刻能否使用。
  • 可审计的运行结论必须继续连接：选中了哪条 RR、RVS 名称与地址、当前注册、I1 转发、基于 HI 的认证、HIP 关联完成，以及应用结果。

还剩四十八分钟的绿色状态

09:00，解析器取得一个移动端点的 HIP RR。记录包含预期的 HI、HIT 和一个 RVS 名称，DNSSEC 验证成功，TTL 为一小时。保障平台把三个事实压成一句话：“身份已验证，端点可达。”

09:12，端点切换网络。它向 RVS 更新新地址的消息没有成功。DNS 无须因此立刻变化：公开的会合入口仍是同一个名称，RRset 的签名仍然正确，缓存也还没有到期。09:20，发起方把 I1 发给 RVS；RVS 查到旧地址，将包转发到已经没有端点的路径上。

这是分析用的构造情形，不指向任何产品或真实故障。关键在于，DNS 证据没有撒谎。它仍准确回答“这个名称发布了什么，以及这份缓存是否还能用于 DNS 发现”。错误发生在平台把问题换成了“端点此刻能否证明私钥并收到数据”。

两个事实可以同时成立：记录新鲜，路径失效。只有把证据分层保存，系统才能容纳这种现实。

公开材料不是私钥在场证明

RFC 5205 于 2008 年以 Experimental RFC 发布；2016 年的 Standards Track RFC 8005 取代了它。DNS 类型 55 的 HIP RR 可以携带 HI、由 HI 派生的 HIT，以及零个或多个 RVS 域名。

HI 是公私钥对中的公开部分，HIT 是对 HI 的截断散列标识。发起方预先拿到这些材料，可以避免在完全不知道响应方身份的情况下进入机会式交换。但是 DNS 回答没有私钥，也没有一次由端点现场产生的签名。

RFC 8005 因而明确提醒：HIP 端点不应只凭从 DNS 得到的 HIT 对对端进行认证，而应使用基于 HI 的认证。查到标识与对端在当前交换中使用相应密钥，是两个事件。

如果资产平台在解析 HIT 后立即写入 peer_authenticated=true，它删掉的正是协议要求的认证步骤。密钥可能已下线、损坏或不可访问，而公开资料仍按正常的发布周期存在。

DNSSEC 的强度不扩大声明范围

未受保护的 HIP RR 若被篡改，攻击者可以替换公开密钥材料，也可以把 I1 引向别处。RFC 8005 因此建议通过提供数据完整性与真实性的安全通道取得 RR，并把 DNSSEC 作为这一机制。

同一段文字随即限定其权限：DNSSEC 保护的是发布区域的 DNS 服务器到 HIP 节点之间的数据；它不保证区域发布者本身值得信任。HIP RRset 的 RRSIG 不得被解释为把 HI 或 HIT 与所有者名称绑定的证书。

所以 secure 结果很重要，却不万能。它应连同信任锚、算法、验证策略、签名时间和准确字节保存。它没有观察端点电源、私钥存储、RVS 注册表、IP 路由或应用进程。

密码学可以非常可靠地保护一条窄声明。可靠不等于宽泛。把“数据未经篡改”写成“服务正在运行”，既误用 DNSSEC，也会在故障时把排查引向无辜的签名链。

TTL 是缓存边界，不是在线租约

RFC 8005 澄清：自取得 HIP RR 起经过的秒数一旦超过 TTL，取得者必须把记录视为无效并删除；若仍需用它发起通信，就必须重新查询。

这给缓存复用画出清楚边界。TTL 以内可以复用该 DNS 发布；TTL 以外必须重新取得。它没有要求端点在同一时段保持上线，没有为 RVS 预留表项，也没有冻结地址和网络路径。

即使在 TTL 到期后重新查询，也可能得到内容完全相同且再次验证成功的 RR，而 RVS 仍保存旧定位。新的 DNS 收据只能刷新 DNS 层的结论，不能替其他系统续期。

自动化最容易在此犯错，因为 TTL 能本地计算，无须联系服务。cacheAge < ttl 可以推出“允许继续使用这份 DNS 数据”，不能推出 endpointLive=true。后者必须来自新的运行观测。

RVS 名称与 RVS 注册处在两个存储系统

为支持移动性，HIP 节点在 DNS 中发布相对稳定的 RVS 名称，同时通过另外的过程让 RVS 掌握其当前 IP 地址。RFC 8004 描述 RVS 在决定转发 I1 前要检查的当前注册。

因此，RVS 名称解析正确，并不意味着对应 HIT 仍有注册；RVS 服务器在线，也不意味着表项中的定位是新的。注册可能过期，更新可能丢失，重启可能清空状态，旧地址也可能仍然格式正确。

这些不是同一系统的自相矛盾，而是不同权威各自陈述事实。区域发布者对 RRset 负责；解析器对验证与缓存负责；RVS 对注册表和转发决定负责；端点对收包和密钥使用负责。

合理的证据链是：

HIP RR 已发布 → DNSSEC 已验证 → TTL 有效 → 已选 RVS → 注册当前有效 → I1 已转发 → HI 已认证 → 关联完成 → 应用结果已观察。

每个箭头都跨越一个控制面。某一格没有收据时，应写“未知”，不能继承左边的绿色。

多条 RR 要求保留组合关系

RFC 8005 允许同一名称关联多条 HIP RR，并把选择策略留给实现。不同记录的 RVS 信息可以不同；存在多个选择时，主机必须确认所用 RVS 与所用 HI 相关联。

这条要求反对一种常见的数据清洗：把所有 HI 放进一个集合、所有 RVS 放进另一个集合，然后任意组合。数据库可能由此创造区域从未发布过的 HI—RVS 配对。密钥轮换或迁移期间，新旧记录并存，风险尤其高。

运行收据应把每条 RR 当作原子来源，保存其算法、HI、HIT、RVS 列表、TTL、响应指纹和选择理由。否则一次失败可能被错误归咎于协议，实际却是本地投影丢掉了关联。

“当前可达”需要哪些收据

完整记录从查询名称、类型、解析器、权威服务器、时间和报文指纹开始；保存完整 RRset 与逐条关联；记录 DNSSEC 信任锚、策略与结果；记录取得时间、缓存年龄、TTL 和到期后的重新查询。随后还要独立记录 RVS 的 A/AAAA、当前注册 ID、目标 HIT、定位集合、刷新、到期、取消和配置代次。

到运行路径，则需关联 I1 的发送、RVS 接收、表项查询、转发和端点接收；再保存 HIP 认证转录、所选 HI、签名结果与双方关联状态。载荷路径和应用结果仍是下一组收据。

每个团队只需为自己能观察的事实负责。DNS 团队不必假装看见 RVS 表，RVS 不必替端点证明私钥，HIP 关联也不必替应用声明成功。观测停止处明确标记未知，远比一个虚假的全局“正常”更有用。

RFC 8005 增加 ECDSA 支持，澄清 TTL 后重查、多 RR 和多个 RVS 的格式。这些是规范事实，不是部署迁移收据。实际系统仍要给出实现版本、构建、配置和报文证据。

HIP RR 的发现作用并未因边界清晰而减弱。相反，它不再为无法控制的故障背锅。构造情形中，正确界面应显示：“HIP RR 安全；TTL 有效；RVS 注册未确认；端点可达性未知。”这句话不够漂亮，却直接指出下一次测量应发生在哪里。

来源