[第125回IETF Meeting] DNS関連WGの状況

▽DNS関連WGの構成に関する検討事項（draft-hardaker-dns-wgs-at-ietf）

文書はインターネットドラフトの形で公開され、調査で判明したコミュニティの共通見解として、以下の項目を挙げています。

• DNS関連の新しい提案を適切なWGに誘導する「DNSDISPATCH」機能を独立させることは、標準化作業をどこでどう実施すべきかを決定する上で有用である。
• 運用を取り扱うWGとプロトコル開発を取り扱うWGの二つを作る（分ける）ことは、IETFのDNSエンジニアにとって有益である。
• WGを再編するだけでは、「人の問題」は解決できない。
• より困難な課題に取り組む際には、専門性の高い別のWGが必要になる。

また、共通見解とはならなかった項目として、以下を挙げています。

• 提案に関する実行可能なコード（running code）を必須とするか。
• 現状における最良の慣行（Best Current Practice：BCP）文書の作業を、どのWGで取り扱うか。
• 運用とプロトコル開発に加え、アプリケーションを取り扱う第3のWGを創設するか。
• 新たなWGを創設する際に既存のdnsop WGを終了するか、あるいはチャーターを改訂して存続させるか。

これらの見解、項目を踏まえ、文書ではWGの再編における推奨項目として、以下の五つを挙げています。なお、WGの名前は仮のものであり、今後の作業により決定されるとしています。

• プロトコルの開発とメンテナンスに取り組む、dnsprot WGを創設する。
• プロトコルの展開と運用上の問題に取り組む、dnsdep WGを創設する。
• DNSDISPATCH機能を担当する、dnsdispatch WGを創設する。
• WGの管理方法はWGごとに異なっていてよいが、各WGのチェアは緊密に連携し、コミュニケーションを取る必要がある。
• 提案の開発・改良の作業で問題や解決策のスコープが変更された場合、取り扱うWGが移される場合がある。

これらのうち、DNSDISPATCH機能については良い提案であるとして、現在のdnsop WGの一部として運用を開始することが、dnsop WGの共同チェアのBenno Overeinder氏から示されました。今後、議論を反映する形で文書を更新・確定し、IESGと協議の上、再編に関する具体的な実装を進めていく予定です。

▽DNSランキングデータの明確化（draft-fujiwara-dnsop-ranking-data）

RFC 2181で定義されるDNSデータの信頼度（trustworthiness）のランキングデータを改訂し、データの出自に応じ、当該データをどの目的で使えるかの指針を示すための提案です。本提案はJPRSの藤原和典と、NLnet LabsのWillem Toorop氏が著者となっています。

WGでは、2026年3月に公開した改訂版（-01）で以下の指針を追加した旨が、発表者のToorop氏から示されました。

• 権威DNSサーバー・フルリゾルバー・フォワーダーなど、複数の機能を兼ねるネームサーバーでは、取り扱うデータをマージせず、機能ごとに分離しなければならない（MUST）

また、フルリゾルバーが権威DNSサーバーから受け入れるデータを以下のものに限定し、それら以外は受け入れるべきではない（SHOULD NOT）ことも示されました。

• 委任応答に含まれるAuthorityセクションのNS・DSリソースレコード（RR）とその署名、及びAdditionalセクションのグルーレコード
• NXDOMAIN応答、及びNODATA応答に含まれるAuthorityセクションのSOA RRとその署名
• 肯定応答、CNAME応答のAnswerセクションとその署名
• 委任されたドメイン名に対し明示的に許可されている、Additionalセクションのデータ

WGにおける参加者の反応はおおむね肯定的で、deleg WGで作業中の委任に関する新しい仕様（DELEG）の取り扱いも含めるべき、DELEGに関する内容は後からでも追加できるため、DELEGの標準化を待たずに作業を進めるべき、などのコメントがあり、継続して作業を進めることとなりました。

▽親中心（parent-centric）のリゾルバー（draft-sury-dnsop-parent-centric-resolver）

フルリゾルバーがDNSの階層構造をたどる（iterative resoluction）際の情報源として親ゾーンに設定された情報のみを使う、「親中心（parent-centric）」モデルを定義する提案です。

DNSでは、委任を示すNS RRを親ゾーンと子ゾーンの両方に設定します。親ゾーンのNS RRは権威を持たない情報として扱われるため、現在の多くのフルリゾルバーは子ゾーンのNS RRを優先する、「子中心（child-centric）」モデルを採用しています。本提案では、階層構造をたどる際の情報源を親ゾーンのNS RRとそれに付随するグルーレコードのみとし、子ゾーンのNS RRを使わないようにすることで幽霊ドメイン名やPhonenix Domainによる攻撃を防止すると共に、親ゾーンと子ゾーンのNS RRが一致していない場合のフルリゾルバーの動作を明確にすることで、名前解決を安定化させることを目的としています。

また、本提案では受け取った委任情報は階層構造をたどる目的でのみ使い、かつ個々の委任ごとに分割管理するようにすることで、Sibling domainのグルーを安全に取り扱えるようになること、実装におけるDELEGのサポートが容易になることも、親中心モデルのメリットとして示されています。

本提案は、IETF 125に先立ち、dnsopメーリングリストで共有・紹介されました。共著者のOndřej Surý氏からは、開発版のBIND 9に本提案を実装したこと[2]、親中心モデルはオプションであり、従来の子中心モデルを否定するものではなく、フルリゾルバーはどちらのモデルも選択可能であることが示され、それらを反映した新しい提案（-02）が、IETF 125終了後の2026年4月3日に公開されたことが伝えられました

▽IETF 124からの主な変更点

WGで共有されたIETF 124からの主な変更点を、以下に示します。

• 外部のDNSプロバイダーからDELEGの設定を読み込むためのRRの名前を、DELEGIからDELEGPARAMに変更
• それに伴い、記述するキーの名前をinclude-delegiからinclude-delegparamに変更
• 仕様を明確化するため「委任点（delegation point）」と「委任されたゾーン（delegated zone）」という用語を定義
• プロトコルの概要、DELEG/DELEGPARAM RRとパラメーターの定義、運用に関する考慮点のセクションを追加

• 委任の検証における、ADT（Authoritative Delegation Types）

  [3]ビットの取り扱いを明確化

• セキュリティに関する要考慮点を拡充

WGでは後述する「To NS or Not to NS」の問題と、WGで指摘されたDynamic Update [4]の問題の解決後、ワーキンググループラストコール（WGLC [5]）に向けた作業を進めることとなりました。

▽DELEG RRのみの委任を許可するかに関する議論の状況（To NS or Not to NS）

DELEGの基本仕様においてDELEG RRのみの委任を許可すべきかの議論が、集中的に進められました[6]。

会場では、「トランスポートの暗号化を必須にするには、DELEGのみの委任を許可する必要がある」「現在の仕様ではDELEG非対応のフルリゾルバーがDELEGのみの委任先の名前を問い合わせた場合にNXDOMAIN応答が返されるが、その仕様でよいか」「NXDOMAIN応答に代えて別のエラーを返すべきか」などの課題が議論されましたが結論は出されず、メーリングリストで議論を継続することとなりました。