要約

  • RFC 3425はDNS opcode 1のIQUERYを恒久的に廃止し、受信したネームサーバーはNot Implementedを返すべきだとした。この応答の対象は操作であって、名前ではない。
  • 逆引きは委任された名前空間の明示的PTRレコードに残った。NOTIMP、NXDOMAIN、NODATA、PTR応答、DNSSEC検証は、別々の権威を持つ別々の記録である。

答えなかったのではなく、その質問を終えた

RFC 3425は2002年11月、RFC 1035のIQUERY規定を置き換えた。opcode 1をobsoleteとし、IQUERYを受けたサーバーにはNot Implementedを推奨した。

これは「調べたが名前がなかった」という応答ではない。検索処理へ入る前に、要求された操作が現行DNSの問いではないと判定した記録である。NXDOMAINでもNODATAでもなく、PTRの有無を述べていない。

この違いをUIが消すと、正しい拒否が誤った不存在証明へ変わる。

値から全データベースを逆走する設計

RFC 1035のIQUERYでは、依頼者がRRの値をanswer sectionに置き、サーバーが一致するtype・name・classの組をquestion sectionへ返す。in-addr.arpaの明示的なowner nameを引く仕組みではない。

一般に答えるには、サーバーは全レコードを走査するか、値をキーにした別インデックスを維持する必要がある。RFC 1035自身が重い処理になり得ると認め、RFC 3425は数百万名を持つサーバーと巨大応答の問題を具体化した。

大規模ISPの一つのnameserver値から全委任ドメインを求めれば、数万個の組が返り得る。小さい入力が大量列挙を生み、十分に試験されていない古いコードを通り、zone内の名前をまとめて露出させる。RFCが退けたのは便利な方向転換ではなく、局所データベースを無制限に反転させる面だった。

問いは委任をたどれなかった

通常のDNSは名前を手掛かりに権威へ近づく。IQUERYは、接触した一台のサーバーが持つ値を対象にするため、そのサーバーが知らない情報の場所を参照で示しにくい。

別の権威サーバーに該当データがあっても、現在のサーバーの局所探索からは見えない。同じ値について二台が異なる結果を返しても、それぞれのデータベースが違えば矛盾ではない。したがって一つのIQUERY応答を「この値に対応する世界中の名前」と読む権限はなかった。

PTRは逆向きの問いにowner nameを与えた

普及した方法は、逆対応を普通のDNSデータとして表すことだった。IPv4ならアドレスのoctetを反転してin-addr.arpa配下の名前を作り、そのowner nameのPTRを問い合わせる。RFC 1033、RFC 1034、RFC 1035が土台を示し、RFC 2317は/24未満のブロックにも明示的な委任設計が必要だと示す。

PTRは完全性を保証しない。しかし質問に名前があり、委任経路があり、権威とTTLを記録できる。DNSSECを使う場合は検証状態も保存できる。不在を主張するなら、この名前空間の否定応答から導くべきで、廃止済みopcodeの拒否から推測してはならない。

エラーの主語を保存する

NOTIMPの主語は操作である。NXDOMAINの主語はowner nameである。NODATAは名前が存在しても要求typeがない状態を表す。timeoutは観測時間内に受理可能な応答がなかっただけである。

RFC 8020が権威NXDOMAINの利用を整理しても、NOTIMPがNXDOMAINになるわけではない。RFC 8499の用語も、これらを別の状態として扱う助けになる。

古いIQUERYが拒否された後の正しい次手は、対象アドレスから正確なPTR owner nameを作って新しい問い合わせを行うことだ。最初の応答を「見つからない」に丸めることではない。

opcode 1は空き番号ではない

RFC 3425はopcode 1を恒久的にretiredとした。IANA DNS Parametersと RFC 6895はobsoleteなIQUERYとして履歴を保つ。

廃止番号を再利用すれば、保存された古いpacketの意味が時代によって衝突する。予約は新機能を与えないが、過去を一意に読める状態を守る。これは消去ではなく、将来の割り当てを禁じる制御である。

ただしregistryは実装の消滅証明ではない。仕様、binary、設定、受信packet、送信応答は別の現実層であり、現在の挙動には現在の観測が要る。

署名対象を作れない逆引き

RFC 3425は、IQUERYを残すならDNSSECで応答を保護するためにon-the-fly署名が必要になり、極めて難しいと述べた。任意の値から合成する巨大な結果は、既存owner nameのRRsetとは違う。

RFC 4033、RFC 4034、RFC 4035は明示的DNSデータと否定証明の検証体系を定める。検証済みPTRはzoneの主張を支え得るが、アドレス所有、host支配、正引き一致、到達性、application認証まで自動で証明しない。

ましてIQUERYへのNOTIMPは、DNS messageに入っているというだけでPTRの否定証明にはならない。

正しく拒否する歴史

RFC 3425は逆引きを廃止したのではなく、権威が曖昧で高コストな一台のdatabase inversionを廃止した。反対側には、明示的で委任可能なPTR名前空間が残った。

ここで重要なのは、成功と失敗の二分法ではない。何についての応答かである。操作拒否、名前不存在、type不在、署名検証、host同一性、service成功を別々に保てば、NOTIMPは有用な記録になる。それらを一つの「なし」に潰せば、正しいprotocol動作から誤った現実判断が生まれる。

情報源と限界

一次記録は RFC Editor HTML、text、RFC Editor情報ページ、Datatracker文書、履歴、参照関係、errata検索で確認した。DNSの背景は RFC 1033、RFC 1034、RFC 1035、RFC 2317、RFC 6895、RFC 8499、RFC 4033、RFC 4034、RFC 4035、RFC 8020、IANA DNS Parametersから得た。仕様上の記号と稼働事実の区別には、Heng Luの現実層に関する論考とrunning code優先の論考を用いた。

これらは現在のIQUERY普及率、特定製品の脆弱性、実測攻撃、PTR完全性、host同一性、到達性、認可、service結果を示さない。