要約

  • RFC 830のSINSは、階層ドメインを終端DNS/AIPのアドレスまで解決する段階と、AIP同士がトランスポート・アプリケーション能力を交渉する段階を分けた。
  • 中間DNSは直属サブドメインだけを保持し、内部データ形式とキャッシュをローカル判断に残した一方、プロセス間のコマンドは共通化した。
  • RFC 882とRFC 883は、型・クラスを持つ資源、権威ゾーン、参照、キャッシュ、更新を標準分散データベースに置いた。検索結果は運用中の能力や許可を保証しない。

二つのアドレスは二つの成功ではない

RFC 830は、複数のネットワークに接続された終端に対し、複数アドレスを返す回答を好ましいとした。送信元に選択肢を与えられるからである。しかし、回答は経路測定でも稼働確認でもない。片方だけが到達可能かもしれず、両方に到達しても要求アプリケーションが同じ状態とは限らない。

この慎重さは、設計全体から生まれる。最初の分散処理が返すのは、要求アプリケーションそのものではなく、宛先ドメインを代表する名前サービス終端のアドレスだった。そこで別の交渉を始め、初めてトランスポート、アプリケーション・プロトコル、サービス種別を照合する。

名前が場所を一意に示せば作業が終わる、という設計ではない。管理境界に到達したことと、その内側で目的の能力が使えることを別の事実として扱っていた。

ドメインは管理の境界だった

RFC 819は、ドメインを名前割当てと変換責任の領域として記述した。ネットワーク・トポロジーと一致する必要はない。親の中で子の単純名が一意なら、ルートまでの連結で絶対名を作れる。

この階層は、内部の多様性を消さずに外部解釈を可能にする。異なる命名方式も一つのドメインとして接続できる。共通化されるのは全組織の内部語彙ではなく、境界を越えて参照するための名前である。

RFC 830のSystem for Internet Name Service、SINSは、その境界ごとに論理的なDNSを置いた。信頼性のため複数サーバで実現してもよいが、設計上はドメインと一つのDNSの対応として考えた。アプリケーションのある終端ドメインにはApplication Interface Process、AIPも置いた。

DNSはドメイン階層を扱い、AIPはその先のアプリケーション依存部分を扱う。役割分担によって、名前階層があらゆるアプリケーションの意味を抱え込むことを避けた。

右端からたどり、責任は送信元に戻す

完全修飾名は、ローカル名の後に具体的なドメインから一般的なドメインへ並ぶ。解決は右端の最上位ドメインから始まった。

送信元終端DNSは最上位DNSの対応を持ち、問い合わせのハブとして動く。最上位DNSは次の直属サブドメインを解決する。中間DNSは、次のDNSアドレスを返すか、一回転送できる。ただし、そのまま新しいハブとして残りの探索を引き受けてはならない。

これにより、各中間データベースの内容は分離できた。自分の直属の子だけを管理すればよい。更新はローカルで済み、全ホスト表の同期は不要になる。送信元は探索の進行を把握し、途中の管理者は自分の委任範囲を越えない。

RFC 830は内部データベース形式の標準化も不要とした。保存方法ではなく、境界で交わす要求と応答を相互運用の対象にした。実装の置換可能性を保つ一方、共通監査の対象はネットワーク上の会話に限られる。

AIPは目的に合う共通点を探した

送信元アプリケーションは、宛先名と希望サービスをローカルAIPに渡す。ドメイン解決の後、送信元AIPは宛先AIPへ要求を送り、トランスポートとアプリケーションの互換性を確認する。

RFC 830の例では、NIFTPによるリモート・ファイル転送を求めたが、宛先にはFTPしかなかった。送信元もFTPを使えるなら、サービス目的を維持したまま別プロトコルを選べる。名前の修正ではなく、能力集合の交点を探す処理である。

肯定応答はサービスとアドレスを返した。TCPの例ではIPアドレス、プロトコル番号、ポートが含まれる。不互換応答は代替サービスとアドレス、または該当サービスがないことを返せた。名前解決失敗は、解決できなかった名前部分と説明を返せた。

それぞれの否定は意味が違う。未知のドメイン、利用できないプロトコル、接続失敗、アプリケーション拒否を一つの「見つからない」にまとめなかった。

ライブ交渉にも証拠の限界がある

AIPの応答は、固定表より現在の能力に近い可能性がある。それでも認証ではない。サービスを提供すると答えたことは、誰にでも利用を許可したことではない。ポートを返したことは容量予約でもない。接続成立は業務処理の完了でもない。

逆方向の誤読も避ける必要がある。後の接続が失敗しても、ドメイン委任が偽だったとは限らない。アプリケーションが拒否しても、アドレス検索が誤りとは限らない。各層は自分の問いにしか答えない。

多段の証拠は障害解析だけでなく、権限の抑制にもなる。ドメイン管理者、DNS運用者、AIP、アプリケーション、利用者は同じ主体ではない。最初の座標を管理する者が最後の行為を支配する理由はない。

キャッシュを任意にした設計

毎回すべての階層を解決すれば通信量と遅延が増える。RFC 830も以前の結果を再利用するキャッシュの価値を認めた。それでもキャッシュをSINSの標準機能には含めず、各実装の判断に委ねた。

この選択は初期共通仕様を小さくしたが、鮮度の共通契約を弱くした。いつまで保存するか、いつ再確認するか、古い結果と権威元をどう区別するかは、相互運用規則の外に残る。

一方、アプリケーション/AIP、AIP/DNS、AIP/AIPのコマンドは具体的だった。名前、サービス、アドレス、コメントを型付き項目として運び、短い交換には通常UDPを想定した。データの置き方より、独立実装が出会う瞬間を標準化したのである。

DNSは共有データの意味を厚くした

RFC 881はHOSTS.TXTからの段階移行を示した。ドメイン形式の表を並行提供し、やがて従来の表を置き換える。アプリケーションが呼ぶ検索関数の内部をリゾルバに差し替えれば、各アプリケーションは移行方法を意識しなくてよい。

RFC 882とRFC 883は、名前に関連付ける情報を一般化した。問い合わせはドメイン名だけでなく資源タイプを指定し、クラスでプロトコル体系も分けられる。名前サーバは権威ゾーンと参照を持ち、リゾルバは問い合わせを追い、結果をキャッシュする。

権威データとキャッシュは別物になった。ゾーンはマスタ情報と更新手続から得る。キャッシュは過去の問い合わせで得た外部情報で、期限により捨てる。共通フォーマットはデータの出所を同じにせず、違いを表現できるようにした。

アプリケーションとローカル・リゾルバの間には共通ネットワーク交渉を要求しなかった。ローカル手続やOS呼出しでよい。共有契約はリゾルバとサーバ、資源レコード、参照、ゾーン更新へ移った。

採用されなかった境界が残す教訓

RFC 1034はRFC 830を階層名に関する複数提案の一つとして挙げ、RFC 882とRFC 883の分散データベースと一般化資源が後のDNSへ発展したと説明する。階層は共通でも、共有する知性の場所は同じではなかった。

型付きレコードは複製、キャッシュ、監査に向く。全ドメインに万能AIPを要求せず、多様な用途へ拡張できる。その代わり、レコードは宣言である。権威応答はゾーンが何を公開したかを示し、キャッシュ応答はリゾルバが期限内に何を保持したかを示す。現在の稼働、互換性、許可、完了は別に確認しなければならない。

RFC 830を復活案として読む必要はない。重要なのは、位置発見と能力選択を一度は明示的に分けた点だ。共有層が成功するほど、その答えを後続の権限や実行結果へ水増ししてはならない。

出典