摘要

  • RFC 3425 永久退役了 DNS 操作码 1 的 IQUERY，并要求名字服务器收到这种请求时返回 Not Implemented；这只说明操作被拒绝，并不说明名字不存在。
  • 反向解析继续通过委派名字空间中的显式 PTR 记录完成。IQUERY 的 NOTIMP、NXDOMAIN、NODATA、PTR 答案和 DNSSEC 验证结果各自拥有不同的证明对象。

错误发生在名字被审理之前

旧工具向服务器发送操作码 1，服务器回复 NOTIMP。如果监控系统把它直接显示成“没有反向名字”，就省略了关键一步：服务器首先拒绝的是查询方法，而不是某个 owner name。

2002 年 11 月发布的 RFC 3425 宣布 IQUERY 完全过时，替换 RFC 1035 第 6.4 节，并规定名字服务器收到 IQUERY 时应返回 Not Implemented。这可以是完全符合标准的回答。服务器不必搜索名字，也没有给出 NXDOMAIN，更没有证明 PTR 不存在。

“没有实现这个动作”和“名字空间中没有这条记录”，必须保留为两个状态。

IQUERY 反转的是一台服务器的数据库

RFC 1035 中的 IQUERY，不是把地址改写成 in-addr.arpa 的 owner name 后查询 PTR。请求者把资源记录的值放在 answer section，请被联系的服务器从本地数据里找出匹配的类型、名字和类，并把这些三元组放进回复的 question section。

这等于要求服务器按“值”反查数据库。一般实现要么遍历全部记录，要么维护一份以值为键的第二索引。RFC 1035 已经承认负担可能很重；RFC 3425 进一步指出，管理数百万名字的服务器可能产生巨大的回复。

文档举例说，若按某个大型 ISP 的 nameserver 值寻找所有委派域名，结果可能达到数万组三元组。一个很小的请求能够触发大规模枚举、消耗资源，并暴露一整批 zone 名字。很少运行的旧代码也更难获得充分测试。

被联系的服务器没有通往全局答案的转介路径

普通 DNS 查询以名字空间为索引。解析器可以沿委派找到负责某个名字的权威服务器。IQUERY 的问题却是“你这台服务器的数据库里，有哪些名字拥有这个值”。答案被锁定在被联系节点的本地内容中。

另一台服务器可能保存相关记录；当前服务器也可能拒绝 IQUERY，却持有普通 RRset。两个节点因数据库不同而返回不同结果，也不构成协议矛盾。IQUERY 无法告诉请求者下一站应去哪里取得完整信息。

所以“反向”这个词隐藏了两种完全不同的权威：一台机器的数据库倒排，与一个经过委派的反向名字空间。

PTR 把反向问题写成显式名字

实际采用的方案，是把反向映射保存为普通 DNS 数据。IPv4 地址按反序写入 in-addr.arpa，客户端对精确 owner name 查询 PTR。RFC 1033、RFC 1034与 RFC 1035 给出这一体系；RFC 2317又说明，小于 /24 的地址块仍需明确的委派安排，不会由“反查”自动产生管理边界。

PTR 没有保证数据完整，也没有保证名字真实代表正在使用该地址的主机。它带来的进步是问题可路由、权威可定位：请求有明确 owner name，回复有权威上下文、TTL，并可在部署 DNSSEC 时保存验证状态。

如果记录不存在，DNS 有自己的否定回答机制；无需从另一个已退役操作的拒绝中猜测。

四种失败不能共用“未找到”

NOTIMP 表示响应者不实现请求的操作。NXDOMAIN 表示相关 DNS 语义下 owner name 不存在。NODATA 表示名字存在但没有所请求的类型。超时只表示观察窗口内没有收到可接受回复。

它们要求不同动作。IQUERY 得到 NOTIMP 后，应构造正确 PTR 查询；NXDOMAIN 要保留权威与负缓存信息；验证失败不能偷偷降级成普通缺失；超时则要保留传输、重试与目标记录。

RFC 8020后来规定解析器如何利用权威 NXDOMAIN，但没有把操作拒绝变成 NXDOMAIN。RFC 8499统一现代 DNS 术语，也提醒我们错误类别不是界面装饰，而是证据类型。

永久退役保留了号码的历史

RFC 3425 把操作码 1 改为“IQUERY（obsolete）”，并要求永久退役。IANA DNS 参数注册表和 RFC 6895保留了这层含义。

退役号码不是可以重新分配的空位。若未来重用，旧报文就会变得含糊：同一位模式究竟表示旧 IQUERY，还是新动作？保留号码是在保护解释器，也是记录一种负能力——后来者不得占用什么。

当然，注册表也不能证明所有旧实现都已消失。规范含义、产品代码、运行配置、收到的字节和实际回复仍是不同现实层。

DNSSEC 认证显式数据，不能挽救任意倒排

RFC 3425 指出，如果保留 IQUERY，要用 DNSSEC 保护其回复会非常困难，除非临时生成数字签名。原因在于 IQUERY 可能现场合成庞大搜索结果，而不是读取某个 owner name 下已有的 RRset。

RFC 4033、RFC 4034与 RFC 4035围绕显式 DNS 数据定义安全架构、记录与验证。经过验证的 PTR 或认证否定，可以支持限定范围内的结论；IQUERY 的 NOTIMP 不会因为装在 DNS 报文里就继承这类结论。

即使 PTR 签名有效，也只证明相关 zone 在对应状态下做过这项断言。它不自动证明地址分配、主机控制、正反向一致、可达性、应用认证或服务成功。

拒绝也可以是正确结果

RFC 3425 没有让反向 DNS 消失。它关闭了一个代价高、权威模糊且难以保护的数据库倒排入口，同时让显式 PTR 名字空间继续承担反向映射。

历史教训不是“错误码也等于答案”，而是错误码有自己的主语。NOTIMP谈操作，NXDOMAIN 谈名字，PTR RRset 谈 owner name 下的数据，DNSSEC 谈这些数据或否定证据的验证。把主语保存下来，系统才不会用一次正确拒绝制造错误缺失。

来源与边界

主记录来自 RFC Editor HTML、纯文本、RFC Editor 信息页、Datatracker 文档页、历史记录、引用关系和 RFC Editor 勘误检索。DNS 背景来自 RFC 1033、RFC 1034、RFC 1035、RFC 2317、RFC 6895、RFC 8499、RFC 4033、RFC 4034、RFC 4035、RFC 8020与 IANA DNS 参数注册表。区分规范符号与运行观察的方法，来自 Heng Lu 关于现实层和运行代码优先的文章。

这些材料支持协议历史和规定语义，不构成当前部署普查、具名漏洞、实测攻击、PTR 完整性、主机身份、可达性、授权或应用结果证据。