要約

  • IQUERYは通常のDNSメッセージを反転し、Answer欄の資源レコードを手掛かりに、対応する所有者名をQuestion欄へ返させた。
  • DNSの権威は名前とzoneの委任で配置され、任意のRDATA値では配置されていないため、応答は「そのサーバーが知る一致」に限られ、局所的に正しくても完全性を証明できなかった。
  • 全件走査、別索引、通常と異なるキャッシュ条件、大容量応答、情報露出の負担が積み重なり、IN-ADDR.ARPAのPTRがアドレス逆引きを通常の委任可能な名前問い合わせへ作り替えた。

Questionが空なのにAnswerが埋まっている

普通のDNS問い合わせでは、クライアントが名前と種類をQuestion欄に置き、サーバーがAnswer欄へレコードを返す。IQUERYは、この直感をひっくり返した。A IN 10.1.0.52のようなレコードを先にAnswer欄へ置き、「この答えを持つ問い、すなわち名前を示せ」と要求した。

RFC 1035では、この操作にopcode 1が割り当てられていた。要求レコードのowner nameとTTLには意味がなく、未知の名前の代わりに短いroot labelを置けた。応答側は一致したQNAME、QTYPE、QCLASSをQuestion欄にゼロ件以上並べ、最初の一致に合わせてAnswer欄のレコードを整えた。

ワイヤ形式の上では美しい対称だった。標準問い合わせは名前を入力して資源を受け取り、inverse queryは資源を入力して名前を受け取る。同じヘッダーとsectionを使い、向きだけを反転できた。

ただし、DNSの実体は関数表ではない。名前はrootから委任をたどり、その名前について責任を持つzoneへ到達できる。アドレスやMXの宛先、HINFOの文字列など、任意のレコード値から「その値を含む全zoneの権威」へ向かう同等の経路は存在しなかった。

欠陥は後年に発見されたのではない

RFC 882は1983年の時点で、inverse queryの完全性と一意性を保証できないと明記していた。domain systemはdomain nameで組織され、host addressその他のresource typeでは組織されていないからである。保証を求めるresolverは、適切なデータを持つと分かっているname serverを使うか、対象domainの全serverへ尋ねなければならない。

これは計算機性能の但し書きではない。問い合わせのkeyと権威のkeyが異なるという構造上の制限である。名前なら、親側のNS情報が次に尋ねる先を示す。値には親がなく、referralを進める方向もない。クライアントは答えを求める前に、答えを知るはずのサーバーを外部情報で選ばなければならなかった。

RFC 883は、inverse queryを環境依存で扱うよう記している。組織内で包括的なコピーを持つサーバーを決め、管理やデバッグに利用することはできる。その限定された用途は、公開Internet全体への権威を意味しない。

三つの一致を返したサーバーが嘘をついている必要はない。三つすべてが正確でも、別zoneに第四の一致があり得る。正確さと完全さは別の性質であり、IQUERYの成功コードは後者を与えなかった。

応答の範囲は「そのサーバーが知るもの」

RFC 1035の文言は核心を短く示す。応答するのは、指定レコードを持つ名前のうち which the name server knows、つまりそのname serverが知るものだけである。全domain spaceを知るサーバーはないため、結果を完全だと仮定してはならない。IQUERYはdatabase managementとdebugging向けであり、addressからhost nameを得る一般手段には使えないとされた。

ゼロ件は、問い合わせ先の可視範囲で見つからなかったという意味にとどまる。世界のどこにもないという否定ではない。一件は関係の存在を示しても一意性を示さない。多数件でも、そのserverが権威を持つzone、保持していたcache、対応する型の索引だけを反映している可能性がある。

標準DNSの否定応答が持つ強さは、名前から責任zoneを定められる点にある。権威サーバーは、境界のあるnamespaceについて名前の不存在を表せる。IQUERYで「この値を持つ名前は存在しない」と証明するには、その値が現れ得るあらゆるzoneを排除しなければならない。opcodeにはその探索範囲が入っていない。

検索結果を評価するには、行の正しさだけでなく母集団が必要である。どの集合を調べたか、誰がその集合を管理するか、調べていない分割を発見できるか。この来歴が失われると、整った一覧が無限定の事実に見えてしまう。

一つのDNSデータベースに第二の索引を課す

name serverはowner nameからレコードを取り出しやすい形でデータを持つ。標準queryのkeyがQNAMEだからである。IQUERYを速く処理するには、RDATAからowner nameへ向かう別の構造が必要になった。

RFC 883はzoneごとのinversion tableを説明し、zone更新時に該当索引も更新する設計を示した。RFC 1035は、database全体のexhaustive searchか、primary databaseの値をkeyにしたseparate databaseを挙げた。走査なら要求のたびにCPU時間を払い、索引ならメモリーと同期を常に払う。

比較規則も単純ではない。RRのRDATAにはアドレス、domain name、文字列、型固有の複合構造がある。RFC 1035は可能ならcase-insensitive comparisonを求める一方、サーバーが保存するoctet列のどこまでを文字として理解できるかは保証できないとした。任意値検索は一つの普遍的な比較処理にならない。

費用負担にも偏りがある。要求者は短いレコード値を一つ送るだけで、server側が索引維持、走査、応答組み立て、送信を担う。要求者がzone運用上の必要性を示す仕組みも、結果件数に自然な上限を与える委任境界もなかった。

個別レコードをDNSで公開することと、その全体に対する自由な分析queryを提供することは同じ約束ではない。IQUERYは両者を一つのprotocol operationで結び付けようとした。

キャッシュは局所回答を権威回答に変えない

DNSはTTL付きの回答を再利用して規模を支える。しかしRFC 1035は、IQUERYで返ったRRを標準回答と同じ仕組みでcacheできないと警告した。

一つのaddressを持つ名前が、ほかにも同型RRを持つ場合がある。値から見つけた一関係をQNAMEの下へ普通に保存すると、それが完全なRRsetであるかのような印象を作る。検索で抽出した一部と、名前をkeyに権威から取得した集合は同じではない。

さらにcacheは元のcorpusを隠す。どのserverの、どのzoneとcacheを、どの時点で調べた結果なのかが抜け落ちやすい。回答を多数のresolverへ複製しても、観測範囲は増えない。速く広まる局所情報は、全体情報へ昇格しない。

標準queryでは、lookup key、delegation、authority、cache key、TTLが名前を中心にそろう。IQUERYはmessage formatだけを再利用し、その整合を外した。運用上の工夫を加えるほど、「この一台が当時知っていた範囲」という限定を全経路で保持する必要が生じた。

PTRは逆引きを普通の名前へ変換した

実用的なaddress reverse mappingは、全レコードを値で検索する機能を拡大して成立したのではない。RFC 1034が説明するIN-ADDR.ARPAでは、IPv4 addressのoctetを逆順にしたlabelが特別なdomainの下に置かれ、そのowner nameのPTR RRが別のdomain nameを指す。

10.1.0.52を調べるresolverはreverse tree上の予測可能な名前を作り、通常のqueryを送る。そのtreeは階層に沿って委任できる。責任serverを見つけ、TTL付きのRRsetをcacheし、境界のあるzoneから否定応答を得られる。

一段のindirectionは欠点ではなく、権威経路の回復である。PTRは、すべてのaddressにrecordがあるとも、一addressに一nameだけとも、返ったnameが主体を認証するとも約束しない。reverse relationをDNSが権威を探せるowner nameの下へ置く。

IQUERYでは未知の索引をsystem全体に発見させようとした。PTRではreverse spaceの責任者が、決められたnameで明示的なrelationをpublishする。global searchをdelegated retrievalへ縮めたことが成功だった。

正規利用より資源消費に向いた構造

RFC 3425は2002年、IQUERYを正式にobsoleteとした。一般には実装されず、古い実装で提供されてもoperatorが無効化することが多かった。ほとんど使われないcodeのbug、database負荷、zone内の大量name露出が理由として挙げられた。

同じ値が非常に多くのnameに現れる場合、responseは巨大になる。大手ISPのname serverへ委任された全domainを探すようなqueryは、数万tuple、megabyte級の返答になり得る。小さなrequestが大きな計算と送信を誘発し、denial of serviceに利用できる。

inverse MX queryも、共通mail基盤を使う多数のnameをまとめて示し得る。各RRが個別に公開されている事実は、任意の軸で一括目録を作るサービスへの同意ではない。IQUERYは情報そのものより、情報を集約する費用を大きく変えた。

善意のclientは完全性を必要とするが得られない。一方、攻撃者はCPU、memory、bandwidthを消費させたり、local namesの集合を得たりできればよく、global completenessを必要としない。この利害の逆転が、optional featureを維持する理由をさらに弱くした。

opcodeを空き番号に戻さなかった意味

RFC 3425はopcode 1を新しい用途へ再割り当てせず、永久にretiredとした。RFC 1035 section 6.4を全面的にobsoleteとし、IQUERYを受けたname serverはNot Implementedを返すべきだとした。

古い意味を持つ番号を再利用すれば、残存実装が新しいpacketを旧い操作として読む危険がある。退役は番号の浪費ではない。歴史上の意味を一意に残しながら、提供義務だけを終える互換性の選択である。

文書は、意味あるserviceをIQUERYに依存する既知clientがなく、IN-ADDR.ARPAのPTRが長年使われてきたとも記す。標準上の撤去は、単なる美的整理ではなく、広く使われる依存関係が育たなかったことに支えられていた。

DNSSECとの関係も、検索結果の証明の難しさを示す。RFC 3425は、on-the-fly signingなしにIQUERY responseをsecureにすることが極めて難しいとする。署名zoneはnamed RRsetを事前に認証できる。任意値検索の完全回答は、列挙した項目だけでなく、定義された全集から何も漏れていないことまで含意する。

サーバーは証人であってnamespace全体ではない

name serverは本物の参加者であり、特定zoneに対してauthoritativeであり、正確なrecordを持ち得る。その範囲では信頼できる証人である。しかし検索可能なcopyを持つことは、同じ値を含むすべてのnameを代表するmandateではない。

Lu Hengの論考が参加とauthorization、registry recordと対象そのものへのauthorityを分けるように、IQUERYもvisibilityの限界を機械的に示す。データを見ていることから導けるのは、見たデータについての発言までである。見ていないzoneの不存在は導けない。

解決は、Internet全体を検索する中央catalogueを作ることではなかった。DNSはnames、delegations、RR types、TTL、明示的なreverse recordsという小さな共通層を保った。各参加者は有界なzoneでclaimをpublishし、resolverは共通規則でそこへ到達する。

証拠の限界

五つのRFCは、IQUERYの仕様、既知の構造的制限、PTRへの道、obsolete決定を確認できる。現在のopcode 1 traffic比率、すべての歴史的implementation、閉じたnetwork内の診断利用まで測定する資料ではない。

NOTIMPは期待されるprotocol behaviorであって、serverがrequestを一切読まなかった証明ではない。timeoutにはpacket lossやfilteringなど複数の原因がある。返答があっても、responding serverの範囲を越えたcompletenessは得られない。

PTRにもidentity authorityを与えてはならない。forwardとreverseが一致しないことも、recordがないことも、複数名があることもある。本稿の要点はclaimの責任範囲をlocateできることであり、そこに書かれたすべてが自動的に真になるという主張ではない。

IQUERYは問いの向きを示したが、権威の向きを示せなかった。一bitでmessageを反転できても、distributed delegationまで反転できない。reverse relationを再びname treeの中に置いたとき、DNSは魅力的な対称より検証可能な非対称を選んだ。

参照資料