要約

  • RFC 1183は、DNSの各名前に運用上の連絡先を示すRPレコードを提案した。ゾーンを管理する組織と、障害に対応する組織は別でもよい。
  • RPにはメールボックスとTXT説明への参照が入る。公開された参照は連絡先の提示であり、配達、応答、復旧の記録ではない。

ゲートウェイが止まっても、DNSゾーンの管理者への連絡先は残る。では、その人に電話をすれば装置は動き出すのか。ゾーンのデータを直す仕事と、ゲートウェイを修理する仕事は違う。装置がメールを受け取らなければ、そのPOSTMASTERにも頼れない。1990年10月のRFC 1183は、このずれを出発点にした。

提案されたRPは「Responsible Person」の略で、タイプ番号は17。文書の例では、ISI.EDUのゲートウェイがBBN.COMの相談窓口を指してよい。名前の管理権限はISI側に残ったまま、障害時に連絡すべき相手を別の組織に置ける。組織図の線をきれいに引き直すための記録ではない。故障の現場で、誰に知らせるかを探すための記録だ。

RPのデータには二つの項目が必要だった。最初はDNSの書式で表すメールボックス。次は、詳しい説明を置くTXTレコードの名前である。TXTを見るには追加の問い合わせが要る場合がある。複数の装置が同じ説明先を参照できるので、担当部署の案内を一か所で変えられる。一か所の誤りが、複数の装置に広がる設計でもある。

メールボックスがないとき、またはTXTの説明がないときは、該当する項目にルートを表す「.」を置ける。一つの名前に複数のRPを付けることもでき、文書はその場合のTTLをそろえるよう求める。例に出てくる装置には複数の担当者が付く。DNSの担当者、メールの担当者、機器の担当者を一人に見せかけるより、役割を分けて公開する方が、障害の際には役立つ。

RPはDNS階層のどのノードにも付けられる。問題が起きた名前をそのまま調べられる利点は大きい。ただし、委託先の変更や担当者の退職に合わせて更新されなければ、正しく応答するDNSが古い窓口へ案内してしまう。RFC 1183はExperimentalの文書であり、実際にどれだけ普及したか、何件の故障が直ったかは記していない。

SOAが答えるのは、ゾーンのデータを誰が扱うか。RPが試みたのは、機械に何か起きたとき誰が動くか。その二つを結ぶ更新作業を怠れば、公開された責任者名は、故障を早く直す手掛かりではなく、遠回りの入口になる。

資料：RFC 1183「New DNS RR Definitions」第2節～第2.2節、RFC Editorの記録。