Summary

  • RFC 1383 设想用反向 DNS 中的 RX 网关信息，寻找多宿主边缘网络入口，而不向全球路由表公布该网络的每条内部路由。
  • 文中实验软件监听 ICMP“目的地不可达”，收到后才查 DNS。作者明确指出首包可能因此丢失；DNS 列出的网关也未必此刻可达。

数据包出发，路由器说找不到目的网络。一个管理程序听见这声失败，才去 DNS 查询哪座网关能带路。Christian Huitema 在 1992 年 12 月的 RFC 1383 中把失败当成发现路由的触发器。这样能绕开改写普通 IP 路由代码的麻烦，却可能牺牲第一包。

当时的账本正在膨胀。该文记载 NSFNET 路由表里已有超过 5000 个网络，EBONE 超过 7000 个；这是 1992 年文本中的数字。新增网络公告会占用中转路由器内存，扩大协议交换，还让运营者面对新的策略选择。按层级分配并聚合地址是主要解法，可是一个连接多家提供商、希望换接入而保留地址的客户，不愿把身份绑死在一家地址空间里。

Huitema 借了邮件 MX 记录的形状，换成 IP 包的去路。边缘域 D 有 I1、I2 两座对外可见的网关；它们知道 D 的内部路由，却不把每个内部网络都公告给全球。源端对目的地址发起 in-addr.arpa 反向 DNS 查询，取得实验性 RX 列表，选一座网关，再用源路由把包送过去。早期实验并无正式 RX 记录类型，而是在 TXT 记录里写入 RX、偏好值和网关 IP 地址。

为什么要源端一次选定？若沿途每台路由器都查 DNS，改造范围会扩大；前后两台可能分别选 I1、I2，让包绕路甚至成环。一次决策再保持路线一致，避免把目录查询分散到每个中转节点。两座网关也比一座更能抵御单点故障与提供商锁定。

目录却不是链路健康监控。源端必须排除已知不可达的网关，何时发现故障、何时刷新缓存，仍是实验要解决的操作问题。D 的 RX 信息还得复制到从互联网核心可访问的 DNS 服务器上。若唯一的说明书锁在已经失联的域里，别人连查路的入口都找不到。

软件分成内核实时转发器和 DNS 查询管理器。原型监听 ICMP 不可达消息，随后把新包导向转发器并查询 RX；等待中的包会继续衰老、到期就丢。没有查到网关，程序将目的地标为不可达，并清掉队列。RFC 说得很清楚：如果可以直接改 IP 路由代码，那样做更好，因为不必先丢一个包来获得 ICMP 线索。RFC 官方记录把它列为实验性协议；结论说 INRIA 的代码仍在开发中。

这还是一场议价实验。Huitema 推想，骨干网若按单独公告的网络收费，客户可能被迫改用提供商地址；RX 是减轻路由表负担、又保留多宿主选择的一条备选路。全球表少承担状态，源端却多承担查找、判断与恢复。DNS 能写下门牌，门是否开着，要靠真正送达来回答。

Sources