要約

  • RFC 1788 は ICMP タイプ37と38を使い、逆引きDNSだけに頼らず各ユニキャストアドレスへ直接ドメイン名を尋ねる仕組みを定めた。
  • 応答元アドレス、識別子、シーケンス、TTL、空の応答は一回の交換を限定するが、所有者、利用者、経路認可、組織の同一性までは証明しない。
  • RFC 6918 は2013年、広く実装も配備もされなかったとして両タイプを廃止した。仕様書の MUST より、実際に動くコードの採用が結末を決めた。

一括探索ではなく、アドレス別の照会

逆引きDNSは、通常のドメイン名を逆方向になぞるだけの仕組みではない。正引きはドメインの管理境界に沿い、逆引きはアドレス空間の割り当てと委任に沿う。CIDR のもとでは、この二つの境界が一致しないことがさらに明瞭になった。

RFC 1788 は、IN-ADDR 情報が必ずしも信頼できる状態で維持されず、表示やセキュリティログのために名前を得ようとするアプリケーションが長く待たされると説明した。そこで別の索引を提案した。経路制御がすでに宛先アドレスを見つけられるなら、そのアドレス自身に名前を聞けばよい。

要求はユニキャストに限定され、IP 宛先ごとに別の Domain Name Request を送る。答えるノードは Domain Name Reply を返す。アドレス割り当てと名前の管理を近づけ、逆引きゾーンの別管理に依存する度合いを下げる設計だった。

ただし、質問を小分けにしたことは採用を小さくしなかった。ほぼすべてのホストとルーターに応答コードが必要で、ファイアウォールは新しい ICMP タイプを通し、アプリケーションは答えを理解しなければならない。線上の交換は一対一でも、実装の協調範囲はインターネット全体だった。

同じアドレスから戻るという境界

要求はタイプ37、応答はタイプ38である。識別子とシーケンス番号は照合のため応答へコピーされ、ゼロでもよいとされた。応答の送信元アドレスは、要求の宛先アドレスと必ず同じでなければならない。

この条件は「A に聞いた内容を B が答える」曖昧さを排除した。観測者は、どの宛先へのどの問い合わせに対して、どの送信元から応答が返ったかを結び付けられる。

しかし等しい二つのアドレス欄は、権利の鎖ではない。A を受け取る経路が正当に認可されているとは限らず、A のインターフェースは人間や法人の本人確認書類ではない。返された名前が正引きDNSで A を指すことも、ソフトウェアが組織を代表して話す権限を持つことも自動では証明されない。

RFC 1788 自身も、ルーティングはセキュリティではないと認めた。IPsec による保護や、正引きDNSから得た暗号署名による応答検証を将来の方法として挙げた。基本メッセージにその保証が含まれていたわけではない。

名前がないことを明示する

応答にはゼロ個以上の完全修飾ドメイン名を入れられた。何も知らない場合も応答は必要で、それが「名前が知られていないことの権威ある表示」とされた。

ここでの権威は限定的である。タイムアウトと明示的な否定を区別できる点に価値があった。DNSSEC の否定証明でも、所有権証明でも、永続する宣言でもない。そのノードが、その瞬間、このプロトコルで示した知識の範囲にすぎない。

複数の名前を知っていれば、すべてを載せるべきだった。ただし応答 MTU に収まらない名前は省略される。受信した一覧が短いとき、送信者の知識が少ないのか、パケットの物理的上限で落ちたのかを区別する必要がある。

応答には TTL もあり、歴史的理由から符号付き二の補数で表現された。TTL はキャッシュ再利用の時間境界であり、名前の正しさ、経路の寿命、機器の存続、組織関係の継続を保証する時計ではない。

マルチキャストでは沈黙が必須だった

ブロードキャストまたはマルチキャスト宛てに要求が届いた場合、ノードは黙って捨てなければならなかった。全ノードがグループ質問に答えれば、一つの要求が応答嵐を作るからである。

「すべてのホストとルーターが実装する」という文は、どんな配送形態にも答えるという意味ではなかった。安全な起動条件は、一つのユニキャスト宛先、一つの要求、一つの応答経路だった。発見を便利にするための扇状送信は、普遍実装と組み合わせると増幅になる。

この制限は、仕様が運用インセンティブを意識していた証拠でもある。単純な応答機能であっても、トラフィック量、攻撃面、情報開示を制御しなければならない。普遍的なサーバーは、無制限のサーバーであってはならなかった。

ICMP の無応答には複数の意味がある

RFC 792 は ICMP を、通信上の問題についてフィードバックする仕組みと位置付けた。IP を信頼できる配送サービスへ変えるものではなく、元のデータグラムも制御メッセージも戻る保証はない。

したがって一回のタイムアウトは「RFC 1788 未実装」の証明にならない。損失、フィルタリング、ポリシー拒否、経路変更の可能性がある。逆に一回の正しい応答は、その時点の経路上で一つの実装が答えた証拠であり、世界的配備の証拠ではない。

記録は、肯定名、明示的な空応答、無応答、管理的拒否、認証失敗を別に保つ必要がある。Heng Lu の Reality Layers の観点では、パケットが観測層、所有者や権限の判断が解釈層である。前者を残さず「本人確認済み」とだけ書けば、記号が現実を上書きする。

最強の義務語でも採用は作れなかった

RFC 1788 はサーバー機能を任意としなかった。すべてのホストとルーターが実装しなければならず、診断用のアプリケーションインターフェースも提供すべきだとした。

それでも RFC 6918 は2013年、タイプ37と38が広く実装も配備もされなかったと記録した。両メッセージを正式に Deprecated とし、RFC 1788 を obsolete にした。現在の IANA レジストリにも同じ状態が残る。

「広くなかった」を「一つも存在しなかった」と言い換えてはいけない。公式記録は単一の原因も示していない。証明されるのは、一般アプリケーションが依存できるほどの応答者集団が形成されなかったという点である。

採用の循環は厳しい。応答がまばらならアプリは使わず、利用者がいなければベンダーは実装しない。未知の ICMP は中間装置で落とされ得る。DNS API はすでに存在する。端点による名前公開にはプライバシーと認証の追加課題もあった。

RFC 6918 は、廃止状態がフィルタリングを支援し得るとも述べた。採用されなかった現実を標準化した後は、残存実装を維持する動機がさらに弱くなる。記録は均衡を説明すると同時に固定した。

IPv6 は用途を診断へ縮めた

RFC 4620 は後に Experimental として IPv6 Node Information Queries を定義し、IPv4 の先行案にも触れた。ただし世界的な名前の権威は DNS に残し、用途を診断、デバッグ、ネットワーク管理に限定した。

nonce、既定スコープ制限、レート制御、プライバシー配慮を加え、追加認証なしに得た情報をセキュリティ判断へ使うべきでないと警告した。ノード名の TTL はゼロでなければならなかった。

これは RFC 1788 の改名復活ではなく、異なる範囲と安全境界を持つ実験である。その文書だけで広い採用も証明できない。比較が示すのは、端点の自己申告を扱うには野心を絞り、証拠の意味をさらに限定する必要があったことだ。

実装するという選択が本当の投票だった

Heng Lu の Running-Code Primacy は、この歴史を標準への反抗ではなく権威の生成過程として読ませる。仕様は参加者の互換動作を厳密にできる。しかし、独立して管理される機器へコードを配る権力は持たない。運用上の権威は、自発的に採用された実装が相互運用を続けることで生まれる。

RFC 1788 には番号、ICMP 割り当て、パケット図、普遍的 MUST があった。記号層は完成していた。欠けたのは、依存を支える密度の運用層だった。十八年後、記号層が運用層へ合わせて修正された。

Minimum Initial Specification、Localized Future Decision、Voluntary Adoption は別の尺度を与える。ワイヤ形式が小さくても、採用判断はほぼ全ホスト、ルーター、フィルター、アプリで繰り返さなければならない。小さい仕様は、必ずしも小さい協調負担ではない。

これは現代の解釈であり、1995年の著者の主観を証明しない。また MUST が無用だという話でもない。採用済みプロトコルの互換性には強い要件が要る。強い語を、採用済みであることの証拠に使ってはいけないだけである。

一つのアドレスに一つの質問を送る設計は慎重だった。だが世界中の一つ一つの機器が答えるという前提は実現しなかった。RFC 1788 が限定できたのは一回の交換であり、限定できなかったのは独立した実装者の選択だった。

出典