要約

  • RFC 3467は、DNSの本来の仕事を、正確で一意なネットワーク資源識別子の解決と捉え、人や商品を曖昧な表現から推測する検索とは分けた。
  • 提案された検索層は、候補を見つけてから選択済みの名前をDNSで解決するという構想であり、規格化されたプロトコルや運用実績ではなかった。

同じ「名前を探す」でも仕事が違う

「駅前にある青い看板の店」を人に尋ねれば、相手は駅を確認し、言い間違いを補い、複数の候補を示せる。DNSリゾルバーはそうしない。完成した名前とレコード種別を受け取り、分散階層をたどって対応するデータを返す。曖昧さが残る段階は、本来その入口より前にある。

John Klensinによる2003年のInformational文書RFC 3467は、この違いをDNSの歴史から説明した。文書自身が、示した枠組みは提案された解決策ではないと明記している。歴史記述にも留保があった。初期の設計判断は十分に記録されておらず、参加者の記憶も一致しないため、後から組み立てた一つの物語にすぎないという。

当時のDNSが性能面で破綻していたという主張でもない。RFCは、性能と信頼性は許容範囲にあり、深刻な劣化の証拠は少ないと述べた。問題は意味と役割の過積載だった。広く展開済みという理由だけで新しい情報をDNSへ入れれば、短期の導入は容易でも、その階層、比較規則、キャッシュ、権限構造まで引き受けることになる。

ホスト表を超えるための設計

DNS以前には、頻繁に配布されるホスト表が名前とアドレスを対応づけていた。名前は数字を覚える負担を減らし、トポロジーでアドレスが変わっても残り、一つのホストに複数のアドレスを結び付けられた。しかし、ネットワークの成長とともに一枚の表は拡張できなくなった。DNSは一意で曖昧でない名前を保ちつつ、検索と管理を階層的に分散し、新しいレコード種別も受け入れた。

拡張可能であることは万能な名簿であることを意味しない。RFC 3467によれば、DNSは主としてネットワーク資源を識別するためのもので、人、ブランド、商品、文書を探すためのものではなかった。データ形式が任意のビットを格納できても、アプリケーションは狭いホスト名規則を前提にしていた。保存できることと、利用者の説明から発見できることは別である。

文書は、DNSが「便利だから使うデータベース」になったと評した。どこからでも問い合わせられる強みは大きい。しかし、それだけでは新しいデータがDNSの厳密なキー、公開階層、キャッシュ、委任の仕組みに適合する証明にならない。

一致判定と類似検索の間

DNSは定められた規則で一致か不一致を決める。人の検索には、綴りの揺れ、異なる文字体系、地域別の慣行、属性、近い候補の順位が必要になることがある。RFC 3467は、企業名や商品名を平坦な空間へ押し込むこと、一台のホストに多数の名前を付けること、利用者の場所で回答を変えること、権限別の個人情報、多言語名を同じ過負荷の兆候として扱った。

文字列準備は境界を消さない。指定された文字を変換または拒否し、決定的に比較できる形へ整えることはできる。しかし、それは利用者の意図を推測する曖昧検索ではない。正規化は比較前の工程であり、検索は複数候補を残して文脈と選択を必要とする。

値から名前を探す古いIQUERYも一般的な解決にはならず、実装の乏しさと運用上の問題から廃止された。アドレス逆引きのような特定の仕組みまで否定したのではない。DNSが任意の属性や関係を走査する汎用検索インターフェースではないことを示す例だった。

発見結果を正確な名前へ渡す

RFC 3467が描いたのは二段階である。検索またはディレクトリ層が、人の入力、言語、国、属性を受けて候補名を返す。利用者やエージェントが選んだ後、その正確な識別子を通常のDNSが解決する。

二つの段階には二つの証拠がある。検索結果は、ある索引、規則、時点で候補が一致したことを示す。DNS応答は、ある解決文脈で正確な名前にレコードが返ったことを示す。上位候補は本人確認ではなく、有効なDNS応答は選択の正しさではない。接続成功もサービスの権限や利用者の意図を証明しない。

検索層にも権力と危険が生まれる。索引は古くなり、順位は商業的な誘因に左右され、地域別の規則で同じ入力が別の候補を返し得る。RFC 3467は不正変更からの保護を求め、層やデータベースの追加が侵害機会を増やすと認めた。分離は責任を見えるようにするが、信頼を不要にはしない。

歴史に残ったのは解決策より境界

RFC 3467はディレクトリの通信仕様も移行計画も提供しなかった。残したものは、共通インターネットに必要な一意の識別子と、人がそれを見つける柔軟な手段を同じ仕組みに押し込まないという判断だった。

運用記録では、元の問い合わせと文脈、候補一覧、選択、DNSへ渡した名前、リゾルバーの状態、応答、接続先、アプリケーション結果を分ける必要がある。正確な応答はキーが解決された証拠であって、そのキーこそ利用者が意味した対象だったという証拠ではない。

出典