摘要

  • DNSKEY 的 SEP 位表达密钥的预期运维用途，可帮助工具准备 DS 或管理密钥；它不是凭证，不能证明密钥身份或建立信任链。
  • RFC 4034 与 RFC 4035 明确限制验证器：不能因为第 15 位被置位而改变签名验证行为。SEP 密钥仍需 Zone Key 位，才能验证资源记录集签名。
  • Edward Lewis 是 RFC 3757 的三位共同作者之一。公开记录支持这一项标准贡献，但不足以证明他单独设计了 SEP、实现了某个产品或目前受雇于某机构。

一个位的权限止于何处

DNSSEC 的交接发生在子区与父区之间。子区发布 DNSKEY；父区可以发布 DS，把委派与相应密钥联系起来。这里有一个容易被忽略的区别：运维者想让工具如何处理密钥，是一种意图；验证器依据协议确认签名与密钥关系，则是另一种判断。Secure Entry Point（SEP）只属于前者。

2004 年 4 月发布的 RFC 3757 由 Olaf Kolkman、Jakob Schlyter 和 Edward Lewis 共同署名。它把 SEP 加入 DNSKEY 标志字段，用来表示某些密钥拟作为安全入口点。规范举出的用途包括辅助生成 DS，以及识别计划静态配置的密钥。文中也明确指出，DNS 验证协议不会使用 SEP。因而这个名称描述的是工具或管理员可参考的标记，而不是密钥可信的证明。

例如，一套签名工具可以在子区公布的 DNSKEY 中优先选取 SEP 密钥，用它生成待提交给父区的 DS。接下来仍须核对生成值是否对应正确的密钥，父区也必须独立处理并公布 DS。子区上的一个位无法证明父区接受了记录，更不能替代对父区实际发布内容的检查。网络上的验证器随后按 DNSSEC 规则判断，不应把这项本地意图升级成信任依据。

RFC 4034 和 RFC 4035 于 2005 年取代 RFC 3757，同时保留了 SEP。前者把它描述为签名或调试软件可用的提示；后者给验证行为划出硬边界：不得仅因 SEP 被置位就改变验证。两个标志也不能互相替代。标记 SEP 的 DNSKEY 仍要带有 Zone Key 位，才具备验证资源记录集签名的资格。简言之，SEP回答“运维者希望工具如何对待这把钥匙”，Zone Key回答“它是否符合协议中的签名验证角色”。

RFC 6781解释了为什么运维侧仍需要这个提示。常见约定是给参与父区交接的 KSK 置 SEP，而不给 ZSK 置位。但有些部署采用单一密钥类型，让原本由 KSK、ZSK 分担的职责由同一类型承担。假设所有环境都严格分成两类的工具，可能会误选或误显示密钥。RFC 提醒某些工具可能因此困惑；这能支持一次针对具体工具的检查，却不能推导出某处已经发生错误验证。

SEP 也不是 RFC 5011 中的 REVOKE 位。RFC 5011定义自动更新信任锚的状态机制，并以另一个DNSKEY标志表示撤销状态。二者处在不同的流程里；把 SEP 当成撤销信号或信任锚更新指令，会混淆规范给出的职责。

Lewis 在这段历史中的位置也应按证据限定。RFC 3757将他列为三位作者之一；IETF Datatracker 个人页记录了这份 RFC，Internet Society Pulse 的作者页面提供有限的职业背景。这些页面不支持把他称为 SEP 的唯一设计者，也不证明某一套 DNSSEC 软件由他实现。RFC 中出现的 ARIN 是历史署名信息，不代表现职。规范能够说明位的语义和验证规则，却没有统计采用率、工具错误率或事故数。能从记录得出的结论是：SEP 可表达运维意图；信任仍要由父区交接与协议验证建立。

来源