摘要

  • RFC 1183 提议用 RP 记录给具体 DNS 名称标出故障联系人。这个人可以不属于管理该区域的机构，也不必是设备的 POSTMASTER。
  • RP 存储一个邮箱名称和一个指向 TXT 说明的名称。DNS 能返回这两个指针，却不能证明邮件送达、有人接手或设备恢复。

先看一场普通故障：网关没有响应，DNS 仍然正常。运维人员从 SOA 找到区域管理员，把告警发过去。对方能改区域文件，却可能根本不懂网关；发给网关的 POSTMASTER 也未必奏效，因为网关可能不收邮件。1990 年 10 月的 RFC 1183 正是从这个尴尬处下手。名字的管理权和机器的维修能力，不是同一回事。

它提出 Responsible Person，缩写 RP，资源记录类型代码为 17。文中的例子很锋利：ISI.EDU 名下的网关，可以把故障联系人指向 BBN.COM 的热线。区域仍归原机构管理；真正能接电话的人却在另一家机构。RP 没有替外部团队取得改动 DNS 的权力，只把求助路径写成了可查询的数据。

记录里有两个必填字段。第一项是按 DNS 邮箱约定编码的地址，与 SOA 联系人的写法相同；第二项是存放人类可读说明的 TXT 名称。查询 RP 后，读者可能还得单独查询 TXT。多个设备可以共用一份说明，不用逐台复制电话号码和操作提示。代价也随之出现：这份共享说明一旦过期，所有指向它的设备都会把人带错地方。

RFC 允许用根节点的一个点「.」表示没有邮箱，或者没有相应的 TXT 说明。一个名称还可以有多条 RP，文档建议这些记录使用相同的缓存寿命。例子里的同一台主机列出数位联系人。值班、设备维护、邮件管理和区域管理可能分属不同的人；把所有责任塞进一个 SOA 邮箱，省了表格，却未必省得了故障时间。

RP 可以挂在 DNS 层级的任意节点，而不只是某个区域的顶端。这样，查询者能对着出问题的名称找人。但记录是否仍有用，取决于热线换班、外包结束或人员离职时是否同步更新。DNS 正确回答一条旧记录，仍可能把告警送进无人阅读的邮箱。RFC 1183 的状态是 Experimental；它定义了表达方式，没有给出部署量，也没有证明哪些故障因此得到修复。

这份小记录留下的真正问题是：谁负责名字，谁负责设备，谁负责确保这两份责任名单一致？如果最后一个问题没人接，RP 只是把“找错人”自动化。

资料：RFC 1183《New DNS RR Definitions》第 2 至 2.2 节；RFC Editor 文档页。