摘要

  • RFC 1788 用 ICMP 类型 37 和 38 逐一查询单播地址，希望把地址到名称的回答交给被查询端点，而不再只依赖反向 DNS 的委派树。
  • 源地址、标识符、序列号、TTL 和“没有名字”的明确回复只能界定一次应答，不能自动证明所有权、个人身份、路由授权或机构归属。
  • RFC 6918 在 2013 年记录这些报文从未被广泛实现或部署并将其废弃；真正决定标准命运的是运行中的代码，而不是规范里的普遍 MUST。

两棵树没有沿着同一条边界生长

正向 DNS 的名称按照域名管理关系委派，反向 DNS 则沿地址空间的分配关系委派。两者可以由不同的人、不同的流程、不同的时间表维护。CIDR 出现后，地址块边界与普通域名树之间的错位更加明显。

RFC 1788 直面的是一个实际痛点：IN-ADDR 数据并不总被可靠维护。应用为了界面显示或安全日志查询名称时，可能等上很久，最后仍只得到失败。它没有假定既有系统完美，而是想改变权威回答所在的位置。

方案是向每个单播 IP 地址发送 ICMP Domain Name Request，由地址上的主机或路由器返回 Domain Name Reply。路由负责把问题送到那个地址，于是被描述为数据库的“索引”；名称管理也可以跟随地址分配，不必等待另一棵反向树完整同步。

但这只是移动了管理接缝。端点需要知道该报什么名字，厂商需要实现服务器，网络需要允许报文通过，应用还要判断新答案是否可信。路由能够定位一个接收者，却不能把接收者变成天然的身份认证机构。

类型 37 提问，类型 38 回答

协议把 37 分给请求，把 38 分给回复。标识符和序列号会被原样带回，帮助请求方把回答与问题配对；规范也允许它们为零。每个目标 IP 都要单独发送一次请求。

回复的源地址必须等于请求的目的地址。这条规则很重要：问 A 的问题不能由 B 随手代答。日志由此可以记录“发往 A 的第 N 个问题，收到了来自 A 的第 N 个回答”。

然而，这条等式只约束报文。它没有证明谁合法拥有 A，没有证明到 A 的路由授权，也没有证明哪一个人或公司控制那台机器。它更没有自动完成正向名称回指或 DNSSEC 验证。把源地址相等写成“身份已经核实”，就是把一个可观测字段抬高成了字段从未承诺的制度结论。

RFC 1788 自己指出，路由不是安全机制。它设想可以用 IPsec 保护交换，也可以从正向 DNS 取得密码签名来核验回复。那些建议不是基础报文已经具备的属性，反而说明了基础报文缺少什么。

“不知道名字”也必须发回去

回复可携带零个、一个或多个完全限定域名。如果端点不知道任何名字，它仍然必须回答。RFC 把这种空回复称为“权威地表明不知道名称”。

这里的“权威”范围很窄。它让应用区分“对方明确说不知道”与“包可能丢了”。它不是 DNSSEC 的否定证明，不是资产权属文件，也不是永久事实。它只代表这个应答者在这个时点、这个协议里的知识边界。

知道多个名字时，规范说应当全部列出。但名字若塞不进回复的 MTU，就会被省略。因此，即使发送方遵守规则，线上收到的列表仍可能因包长而不完整。传输约束也是证据的一部分。

回复还带 TTL，而且由于历史原因采用有符号二进制补码。TTL 告诉缓存多久可以复用这次名称信息；它不证明名称语义正确，也不保证机器、路径或机构关系会持续同样长。

群组查询必须保持沉默

请求若发往广播或组播目的地，接收者必须静默丢弃。原因很直接：如果“每台主机和路由器都要回答”与群组投递叠加，一个问题就可能触发应答风暴。

这说明普遍义务从来不是无边界义务。安全的最小触发条件是单播：一个具体地址、一个问题、一条返回路径。直接发现机制一旦允许扇出，就会把便利变成放大器。

即便保持单播，采用面仍然巨大。操作系统、路由器、嵌入式设备、防火墙、诊断工具和应用接口都要协同。RFC 还建议主机向应用提供诊断接口。报文头很短，但社会化部署合同覆盖了几乎整个端点生态。

ICMP 的沉默从来不是单义事实

RFC 792 对 ICMP 的能力边界说得很清楚：它为通信问题提供反馈，却不会让 IP 变得可靠；原始数据报或控制报文都不保证到达。

因此，一次超时不能证明目标没有实现 RFC 1788。可能是丢包、过滤、策略拒绝、路由变化，也可能确实没有服务器。同样，一次格式正确的回复也只证明当前路径上的某个实现完成了这次交换。

严肃的证据记录至少要分开：正向名字、明确的空回复、无回复、管理性过滤和认证失败。如果把它们都压成“名称未知”，协议本来想消除的不确定性又被日志重新制造出来。

Heng Lu 关于现实层的分析在这里尤其适用。包是可观察事实；“这个机构拥有这个地址”是更高层结论。结论可以成立，但需要别的收据。符号系统若把一次响应包装成完整身份，就会让标签比底层现实更强。

规范要求了所有节点，网络没有照办

RFC 1788 使用的是最强的普遍措辞：每台主机和路由器都必须实现服务器功能。它也建议提供面向诊断程序的接口。作者设想的不是少数设备间的私有扩展，而是共同基础设施。

2013 年的 RFC 6918 记录了相反的运行结果：类型 37 和 38 从未被广泛实现或部署。它正式废弃这两个消息，并让 RFC 1788 过时。今天的 IANA ICMP 参数表也把两者标成 Deprecated。

这个结论必须准确复述。“从未广泛”不等于“世界上从未有过任何实现”。官方资料也没有把失败归结为一个单一原因。可以确定的是，应答者没有达到足以让一般应用依赖的密度。

其中存在明显的启动困境。应用若总遇到沉默，就不会采用；厂商若看不到应用，就缺少实现动力。中间设备可能过滤陌生 ICMP 类型。DNS 接口已经普遍存在。与此同时，端点直接公开名称又引入隐私、认证和多名称一致性问题。

RFC 6918 还说，废弃状态可以支持过滤决策。标准记录一旦承认非采用，运营者更容易关闭剩余入口。后来的规范既描述现实，也把现实固化下来。

IPv6 的后续实验缩小了野心

RFC 4620 后来定义了实验性的 IPv6 Node Information Queries，并提到早期 IPv4 方案。但它明确把用途限制在诊断、调试和网络管理，全球名称权威仍属于 DNS。

它使用随机或伪随机 nonce，限制默认查询范围，讨论隐私和限速，并警告未经额外认证学到的数据不应支撑安全决策。节点名称回复的 TTL 必须为零。

这不是 RFC 1788 换号复活，也不能证明新的机制广泛部署。它显示的是另一种设计姿态：直接端点信息仍可用于诊断，但必须缩小用途，增加约束，避免把节点自述变成全球身份系统。

运行代码才完成了投票

Heng Lu 的 Running-Code Primacy 提供了恰当的当代解释。互联网标准的操作权威来自独立系统的自愿采用与持续互通。RFC 可以规定“凡是实现本协议就必须怎样做”，却不能靠措辞把代码装进各自受控的机器。

RFC 1788 的符号层非常完整：编号、分配的类型、报文图、普遍强制词。它缺少的是运行层：足够多、足够可达、足够可信的实际应答者。十八年后，符号层被修改，承认运行层从未形成。

Minimum Initial Specification、Localized Future Decision 与 Voluntary Adoption 又揭示一个反差。线上的格式虽小，采用的决定却不小。它要在几乎每台主机、路由器、过滤策略和应用里重复发生。短报文不等于低协调成本。

这是今天的分析框架，不是对 1995 年作者主观动机的证明，也不是反对规范使用 MUST。一个已经采用的协议必须用强词保证互通。错误只在于把强词本身当成采用已经发生的证据。

RFC 1788 希望让地址直接说出自己的名字，甚至把“不知道”也变成明确答案。它为一次交换画出了清楚边界，却无法替全球独立系统作出采用决定。规范说每个节点都应回答；运行中的互联网用长久的沉默给出了另一种答案。

来源