要約

  • RFC 10029はDNSの主質問を一つに保ち、追加QTYPEをEDNSで求める。応答オプションに載るのは、主応答とRCODEおよび関係するフラグが一致し、必要な内容を完全に処理できた追加種別だけである。
  • 同じパケットで届いても、複数種別が原子的な一時点の証拠になるわけではない。省略された種別には単独照会が必要で、返ったRRsetにも別々のゾーン、署名者、TTL、キャッシュ時点、アプリ利用判断が残る。

空のリストは、運用上きわめて豊かな情報を持つ。サーバーは MQTYPE-Query を認識した。だから MQTYPE-Response を返した。しかし、追加で求められた種別のどれも、主応答と同じヘッダー条件の下で完全には組み込めなかった。

それでも主質問の回答は正しいかもしれない。アプリケーションがそこで処理を始めれば、DNSは成功し、必要な証拠は未完のままになる。

RFC 10029 は2026年7月に標準化過程の文書として公開された。背景には、A、AAAA、HTTPSのような関連種別を一度に得たいという実務上の需要がある。だが、通常のQUERYに質問を何個も入れる方法は採れない。RFC 9619 は、QUERYの QDCOUNT が一を超えてはならず、超えたメッセージはFORMERRになることを明確にした。

そこで主となるQNAME、QCLASS、QTYPEは一組だけ残し、追加のデータRRTYPEをEDNSオプションに並べる。重要なのは、輸送をまとめても質問の主従関係を消していないことだ。

希望した種別と完了した種別

要求側の MQTYPE-Query にはコード20、応答側の MQTYPE-Response にはコード21が割り当てられた。IANAのDNSパラメータ登録簿では、どちらも任意機能としてRFC 10029に結び付けられている。

異なるコードを使うことで、EDNSオプションをそのまま反射する中間装置を、完了リストを生成したサーバーと誤認しにくくなる。要求リストは欲しいものの宣言にすぎない。主質問と応答リストを合わせたものが、このパケットで完全に回答された種別の受領証になる。

応答オプションが無い場合、要求オプションが誤って返った場合、値が重複した場合には、クライアントは機能非対応または不正な応答として扱う。必要な種別について通常の単独照会を行わなければならない。

ANY も同じ意味にはならない。RFC 8482 により、ANYへの応答は最小化でき、サーバーが一個のRRsetだけを返すこともできる。RFC 10029の価値は「全部」という曖昧な表現ではなく、「完全に処理した種別」を列挙する点にある。

主応答が共通ヘッダーを決める

サーバーは最初に主QTYPEの応答を構築し、RCODE、AA、AD、TCなどを確定する。そこで既に切り詰めが必要なら、追加種別を束ねる処理は進めない。

追加QTYPEは、一件ずつ単独照会だった場合の結果を評価される。主応答が NOERROR なのに追加結果が SERVFAIL なら同居できない。ゾーン境界で親側のDSが権威応答になり、同じ親側で見えるNSが非権威データなら、同じAAを付けることもできない。

この省略はデータ損失ではなく、ヘッダーに嘘をつかせないための境界だ。RFC 2181 のデータ順位に従って同じ扱いを受けるRRsetであっても、発行主体や証拠の由来まで一つになるわけではない。

完全な単位が入らなければ載せない

追加種別のレコードは、単独応答なら入るはずのAnswer、Authority、Additional各部に組み込まれる。同じ区画の重複RRは一つにできる。しかし、そのQTYPEに必要なRRsetや不在証明の全体を収められなければ、完了リストには載せられない。

追加種別だけを理由に切り詰め応答を作ることも許されない。そのため TC=0 は、最終パケットが切り詰められていないことを示すだけで、要求した全種別が完了した証明にはならない。

RFC 6891 のEDNS境界も残る。OPTレコードはキャッシュされず、広告するUDPペイロードサイズはそのトランザクションの値である。実際の経路MTUやファイアウォールが同じ大きさを届けられるとは限らない。規格上、中間装置はOPT内容を削除すべきでないが、現実の対応は経路ごとに確認する必要がある。

省略から原因を逆算できない

再帰サーバーのキャッシュに対象種別が無い、個別結果のRCODEまたはフラグが違う、処理数などの制限に達した、応答サイズを超える——RFC 10029は複数の理由を挙げる。応答リストに種別が無いという一事実だけでは、どれかを選べない。

HTTPSが省かれたからといって、HTTPS RRsetが存在しないとは限らない。RFC 2308 の負の応答でもなく、RFC 4035 が求めるDNSSECの不在証明でもない。拒否、障害、攻撃、不要という意味も自動では付かない。

アプリケーションがまだ必要としているなら、単独照会を行う。このフォールバックは速度低下の例外処理ではなく、要求した意味を守る正規の手続きである。

一緒に届いても、同じ時点のデータではない

一つの応答に含まれるRRは、異なるDNSゾーンから来ることがある。不在証明の署名者も異なり得る。TTLは各RRsetで違い、再帰キャッシュに入った時刻も違う。Aは以前のキャッシュ、AAAAは直前の照会、HTTPSは別の署名者による新しい証明、という組み合わせも成立する。

RFC 9499 の用語を運用記録にも持ち込むべき理由はここにある。RRset、権威サーバー、再帰リゾルバー、キャッシュ、検証は、「DNSルックアップ」という一語に潰してよい段階ではない。

HTTPSが返っても接続はまだ決まらない。RFC 9460 に従い、クライアントは必須パラメータ、優先度、アドレス、利用可能性を評価する。配送済みと利用済みは別の証拠だ。

種別完了台帳を残す

各試行について、QNAME、QCLASS、主QTYPE、追加要求種別の順序、リゾルバーと経路、EDNSサイズ、応答オプションの有無と正確な完了リスト、RCODE、AA、AD、TCを保存する。要求集合から完了集合を引いた差分を、明示的な未処理リストにする。

返った種別ごとに、RRset、不在証明、元ゾーン、権威性、署名者、DNSSEC検証、TTL、キャッシュ由来、観測時刻を残す。単独フォールバック、その結果、アプリケーションが選んだアドレスやサービス、最終接続結果を同じ判断IDに結ぶ。

これにより、パケット受信、QTYPE完了、RRset検証、アプリ要件充足を混同せずに済む。

Heng Luのランニングコード優先は、RFC公開やIANA登録を実装事実の代わりにしないという基準を与える。最小初期仕様、将来判断の局所化、自発的採用は、狭い共通形式、局所的な上限、明示的フォールバック、通常照会への離脱を正当化する。そして主張ではなく現実を製品にするという原則に従えば、登録簿は選択肢を示し、実パケットとアプリ結果が採用を示す。

同じ箱に入ったことは、同じ権威から生まれたことを意味しない。