[第119回IETF Meeting] DNS関連WG・BoF・IEPG Meetingの状況

本記事では、第119回IETF MeetingのDNS関連WG・BoFと、IETFに併設される形で開催されたIEPG Meetingに関する状況についてご紹介します。

dnsopはDNS Operationsに由来しており、権威DNSサーバー・フルリゾルバー（キャッシュDNSサーバー）や登録情報の管理など、DNSの運用全般に関するガイドラインの作成を目的としています。WGでは、運用上の課題に着目したDNSプロトコルの拡張・メンテナンスについても、活動項目としています。

▽ルートゾーンのトラストアンカーの配布方式（draft-ietf-dnsop-rfc7958bis）

ルートゾーンのトラストアンカーの配布に使う形式と仕組みを定めた、RFC 7958を改訂する提案です^[*1]。

本提案ではRFC 7958から、以下の点が更新されています。

• 配布の形式をXML^[*2]、PKIX^[*3]、PKCS #10^[*4]の3種類から、XMLのみに変更
• XML形式のトラストアンカーに公開鍵の情報をオプションとして追加（従来は公開鍵のハッシュのみ）
• IANAの運用がPTI^[*5]に移行したことを反映

発表では今後の課題として、トラストアンカーの情報をDNSに載せることを考慮している旨が共有されました。また、この仕組みがいつ必要になるのかという質問に対し、次回のルートゾーンKSKロールオーバーで使うことを想定している旨の回答があり、今後も継続して作業を進めることとなりました。

▽DNSランキングデータの拡張・改訂（draft-toorop-dnsop-ranking-dns-data）

RFC 2181で定義される、DNSデータの信頼度（trustworthiness）のランク付け（ランキングデータ）を拡張・改訂するための提案です。

RFC 2181ではDNSのランキングデータを高い順から低い順に、以下のように定義しています。

• プライマリサーバーのゾーンのグルー以外のデータ
• ゾーン転送で得たグルー以外のデータ
• 権威を持つ応答のanswerセクションの権威を持つデータ
• 権威を持つ応答のauthorityセクションのデータ
• プライマリサーバーのゾーンのグルー、またはゾーン転送で得たグルー
• 権威を持たない応答のanswerセクションのデータと、
  権威を持つ応答のanswerセクションの権威を持たないデータ
• 権威を持つ応答の追加情報（additionalセクションのデータ）、
  権威を持たない応答のauthorityセクションのデータ、
  権威を持たない応答の追加情報（additionalセクションのデータ）

発表では、現在のランキングデータの定義について、リゾルバーに組み込まれたルートサーバーの情報が考慮されていない、ランキングデータとデータの受け入れの可否に関する明確な定義がない、各ランクの具体的な値が定義されていないなどの問題点が指摘され、ランキングデータの初案として「AAA」から「CC」までの9段階の値を付与して細分化した、新たなランキングを提案しています。

この提案については、DNSにおける課題としてしばしば話題になる「親と子のどちらのNSリソースレコード（RR）を優先すべきか」という問題の明確化の契機となる旨が、メーリングリストで指摘されていました^[*6]。

また、これまで数回にわたって問題提起された、名前解決の対象となるデータ（A・AAAA・TXTなど、通常のRR）とその制御に使われるデータ（NS・グルー・プライミングなど）を完全分離する契機となる旨も指摘されており^[*7]、継続して作業を進めることとなりました。

▽DNSプロトコルにおけるグリーシングの考慮点（draft-huque-dnsop-grease）

DNSプロトコルにグリースを適用する（グリーシングする）際の考慮点について考察した提案です。

グリース（GREASE）は、プロトコル仕様において未割り当て・未定義となっている項目にランダムな値を意図的・定期的に指定することで誤動作を引き起こすミドルボックス^[*8]や実装を洗い出し、プロトコルの拡張性・柔軟性を維持する手法です。グリースの名前は「Generate Random Extensions And Sustain Extensibility（参考訳：ランダムな拡張の生成と拡張性の維持）」に由来しています。

グリースはTLSで導入・適用が進められ、TLSへの適用がRFC 8701、QUICへの適用がRFC 9287として標準化されています。なお、英単語のグリース（grease）には潤滑剤という意味があり、この手法の名前はそれにちなんでいます。

提案ではDNSプロトコルにおけるグリースの対象として、以下の項目が挙げられています。

• DNSのヘッダーフラグ
• リソースレコードのタイプ
• 応答コード（OpCode）
• EDNSのバージョン
• EDNSのヘッダーフラグ
• EDNSのオプションコード

WGにおける本提案に対する参加者の印象は好意的で、「サポートする」「進めるべきだ」といったコメントが複数寄せられ、継続して作業を進めることとなりました。

今回のIETF 119で、委任情報を記述するための新しいRR「DELEG」について議論するための「deleg BoF」が開催されました。ここでは、BoF開催までの状況、BoFにおける議論の状況、今後の展望について解説します。

▽BoF開催までの状況

DELEG RRのアイデアは前回のIETF 118の会場で誕生し^[*9]、開催後の2024年1月23日に最初のインターネットドラフト（I-D）が公開されました^[*10]。

その後、dnsop WGの参加者を中心にDELEG RRの標準化作業を進める機運が高まり、2024年2月6日に新しいメーリングリスト「dd」が作成され^[*11]、WGの設立に向けた議論が進められてきました。

なお、メーリングリスト名の「dd」は「DNS Delegation」に由来しています。

▽BoFにおける議論の状況

BoFではまず、NS RRとグルーによる従来の委任に存在する制限事項が再確認され、DELEG RRによる新しい委任が目指すべきゴール・要求事項・要考慮点が、参加者に共有されました。

続いて、DELEG RRを活用した暗号化DNSのロールアウト、フルリゾルバーと権威DNSサーバーの間の暗号化における諸問題をDELEG RRで解決するシナリオ、IETFが以前試みてうまくいかなかったドメイン名の管理境界の識別・判定にDELEG RRを使える可能性が、それぞれの発表者から示されました。これらはいずれも構想の段階ですが、DELEG RRが持つ潜在能力に対する、発表者・参加者の高い期待がうかがえます。

その後、DELEG RRの現在の仕様と提案の動機、提案を知った業界関係者の好意的な反応、今後解決すべき課題が、I-Dの提案者から共有されました。なお、この発表ではDELEG RRの動機付けについて「新しい基本プロトコル『DNSv2』への円滑な遷移（オフランプ）を容易にする（Makes a clean off-ramp to a new base protocol ("DNSv2") easier）」と説明していました。

最後に、WGの設立に向け、チャーター案の更新と確定に向けた議論が進められました。担当エリアディレクター（AD）をはじめとする参加者の反応は非常に前向きであり、BoFの開催は有益であったと結論付けられました。

▽今後の展望

BoFの終了後、2024年3月21日にIABからBoFのレポートが公開されました^[*12]。

レポートには、BoFの議論は前向き・建設的でよくガイドされており、課題解決に向けた議論の継続を期待している旨の見解が示されています。

その後、2024年4月4日にWG設立に向けたチャーターの最終案がMLに共有され、意見募集が開始されました^[*13]。今後、次回のIETF 120で2回目のBoFを開催した後、IETF 121から正式なWGとして活動する見込みとなっています。

dnssdはExtensions for Scalable DNS Service Discovery（スケーラブルなDNSサービス発見のための拡張）に由来しており、ローカルなネットワークで使われているDNSを用いたサービス発見^[*14]の仕様を拡張し、大規模なネットワークで動作可能にするための標準化を目的としています。

今回のdnssd WGはIPv6ネットワークへの端末の接続を自動構成する仕様を標準化している、snac WG^[*15]との共催で開催されました。

▽1回のDNSクエリによる複数のクエリタイプの問い合わせ（draft-ietf-dnssd-multi-qtypes）

1回のDNSクエリで複数のクエリタイプ（QTYPE）を問い合わせるEDNS0拡張を定義する、プロトコル変更のための提案です。本提案では、一つのクエリ内にクエリタイプを列挙するためのEDNS0オプションを追加しています。

現在のほとんどのDNS実装では問い合わせを格納するQuestionセクションの数（QDCOUNT）は1であると想定しており、問い合わせに含められる名前とタイプの組み合わせは事実上、一つになっています。

WGでは、応答の増大がDoSの原因となりうることが懸念事項として指摘され、継続して作業を進めることとなりました。

IEPGは、IETF Meetingに先立って日曜日午前に開催される略式の会合で、インターネットの運用に関連するさまざまなテーマを取り扱っています。

▽現在のインターネットにおけるDNSのIPv6対応状況

APNIC LabsのGeoff Huston氏から、現在のインターネットにおけるDNSのIPv6対応状況を調査した結果をまとめた「Is the DNS ready for IPv6?（参考訳：DNSはIPv6対応済みなのか？）」が発表されました。

DNSのIPv6トランスポートへの対応を定めた現在のガイドラインであるRFC 3901では発行当時（2004年）のIPv6の普及状況とサポート状況を踏まえ、各ゾーンの権威DNSサーバーにおけるIPv6対応を必須としていません。

前回のIETF 118で、RFC 3901の発行から長期間が経過してインターネットにおけるIPv6対応が進んだことを受け、RFC 3901を改訂してIPv6対応も必須とするための提案が、rfc3901bisとして発表されました^[*16]。今回の発表ではこの提案の根拠となっているDNSのIPv6対応の状況について、APNICの環境を使って調査した結果がまとめられています。

発表では、現在のIPv6ネットワークはIPフラグメンテーション^[*17]を適切に扱えず、その失敗率が56%にのぼることが最大の問題点として指摘されました。そして、同氏はIPフラグメンテーションが発生する可能性がある現在のDNSとDNSSECの状況を考慮した場合、DNSはまだIPv6対応済みであるとは言えないのではないかと結論付けました。

▽問題解決に向けた動き

Geoff Huston氏が発表で指摘したDNS over UDPにおけるIPフラグメンテーションの問題は従来から指摘されているものであり、その解決のため「DNS flag day 2020^[*18]」など、さまざまな施策が実施されましたが、今だ根本的な解決には至っていません。

現在、その解決に向け、JPRSの藤原和典がDNSにおけるIPフラグメンテーションを回避する方法を提案しており、作業が進められています。この提案が標準化された場合、フラグメントされたDNS応答をフルリゾルバー側でドロップすることが可能になり、状況の改善が期待できます^[*19]。