ドメイン名関連会議報告
2024年
[第121回IETF Meeting報告] DNS関連WG・IEPG Meetingの状況
2024/12/13
本記事では、第121回IETF Meeting（IETF 121）におけるDNS関連WGの状況と、IETF Meetingに併設する形で開催されたIEPG Meetingにおける、DNS関連の発表の内容についてご紹介します。
dnsop WGの状況
dnsopはDNS Operationsに由来しており、権威DNSサーバー・フルリゾルバー（キャッシュDNSサーバー）や登録情報の管理など、DNSの運用全般に関するガイドラインの作成を目的としています。また、運用上の課題に着目したDNSプロトコルの拡張・メンテナンスについても、活動項目としています。
▽DNSプロトコルへの上限値の設定（draft-fujiwara-dnsop-dns-upper-limit-values）
DNSプロトコルにおけるさまざまな設定や動作について、合理的な上限値を設定する提案です。本提案はJPRSの藤原和典が著者となっています。
dnsop WGで発表するJPRS藤原
DNSが開発された1980年代のインターネットの状況から、DNSプロトコルにおける上限値の設定は最小限に留まっており、CNAMEリソースレコード（RR）の段数やゾーンを管理するネームサーバーホスト名（NS RR）の数など、上限値がサーバーソフトウェアの実装やDNSサービスの運用に任されている項目が存在します。本提案では、こうした状況がNXNSAttackやKeyTrapといったサイバー攻撃の発生につながっているとして、DNSの安定性を向上させるため、適切な上限値を設定することを推奨しています。
WGでは「まず既知の上限値を文書化するのはどうか」「現在の上限値を実装の開発元に確認するとよい」「実装者の立場としてはこうしたRFCがあると便利である」「使い方をプロトコルで制限すべきではないのでは」などのコメントがあり、継続して作業を進めることになりました。
▽DNSSEC推奨アルゴリズムの管理方法の改良（draft-ietf-dnsop-rfc8624-bis）
現在、IETFの標準化プロセスを経たRFCの発行で決定・管理されているDNSSEC推奨アルゴリズムの一覧を、IANAレジストリへの登録による管理に移行するための提案です。
DNSSECでサポートされる推奨アルゴリズムは現在、RFCの発行（最新版は2019年6月発行のRFC 8624）で定義されています。本提案では、推奨アルゴリズムの決定・管理をRFCの発行によるものからIANAへの登録管理に移行することで、暗号アルゴリズムの追加や状況の変化に迅速に対応できるようにすることを狙いとしています。
RFC 8624では、DNSSEC署名・DNSSEC検証においてサポートが必須のアルゴリズムを「MUST」と記述しています。本提案ではIANAへの移行に伴い、「MUST」という記述が「指定されたすべてのアルゴリズムを使用しなければならない」と誤解される恐れがあるため、「RECOMMENDED」に変更することを提唱しています。
WGでは、権威DNSサーバーとフルリゾルバーの実装における推奨事項と運用における推奨事項の違いに関する確認、RECOMMENDEDという表記の妥当性に関するコメントなどがあり、継続して作業を進めることになりました。
▽プライベート利用のためのTLD（draft-davies-internal-tld）
プライベートIPアドレス[1]に相当する、組織内で使用するためのトップレベルドメイン（TLD）を定義するための提案です。提案者はIANAのKim Davies氏とICANNのAndrew McConachie氏で、会場ではKim Davies氏が発表しました。
現在、通常のインターネットの利用以外に使われるドメイン名は特殊用途ドメイン名（Special-Use Domain Names）として予約されています。特殊用途ドメイン名の例として、マルチキャストDNSで使われる.local、DNS以外の手段で名前解決されることを示す.alt、家庭用ネットワークで使われる.home.arpaなどが挙げられます。
本提案には2024年1月にIANAが公開した評価結果を受け、2024年7月にICANN理事会がこのためのTLDとして「.internal」を予約したことが記述されています。
WGでは「フルリゾルバーに.internalのネガティブトラストアンカー[2]を追加する必要がある」「.internalを特殊用途ドメイン名に追加すべき」「IETFでBest Current Practice（BCP）[3]のRFCとすることで重みを持たせるとよい」などのコメントがある一方、「そうしたTLDの予約はIETFではなくICANNで決定すべきだ」という声もあり、継続して作業を進めることとなりました。
deleg WGの状況
delegはDNS Delegationに由来しており、DNSの委任に関する仕様を再設計・改良することを目的としています。
▽WGにおける議論の状況
WGでは現在、DNSにおける重要な再設計を慎重に進めていこうという意思の下、WG創設のきっかけとなったHTTPS/SVCB RRのフォーマットを流用したDELEG RRの提案[4]にとらわれない形で、委任の再設計に当たっての要求仕様を明確にするための議論が続けられています。
要求事項に関する現在の提案（draft-ietf-deleg-requirements-02）では、要求事項をすべての場合において厳密に要求される「ハード要件（Hard Requirements）」と特定の問題への対応に必要な「ソフト要件（Soft Requirements）」の2種類に分け、ハード要件として、以下の7項目を挙げています。
- H1. 既存のドメイン名登録モデルを混乱させてはならない
- H2. 現在のエコシステムと下位互換性がなければならない
- H3. ほとんどのDNSソフトウェアに悪影響を与えてはならない
- H4. DNSSECを使用して委任を保護できなければならない
- H5. 既存の方法と同じ容易さで委任情報の更新をサポートしなければならない
- H6. 段階的に展開可能で、一斉変更するflag dayを必要としてはならない
- H7. 複数の独立した運用者が同時にゾーンを処理できなければならない
また、ソフト要件として、以下の7項目を挙げています。
- S1. DNS over TLS・DNS over HTTPS・DNS over QUICを含む、新しいDNSトランスポートの使用を促進する必要がある
- S2. DNSサービスの利用に必要な詳細情報（プロトコル・ポート・DNSクエリのために必要なデータ）を明確にする必要がある
- S3. 使用時のトランザクションコストを最小限に抑える必要がある
- S4. ゾーンの管理を簡素化する必要がある
- S5. 従来のNSによる委任の仕組みとの下位互換性を確保する必要がある
- S6. 最初の展開後に、新しい機能を段階的に追加できる必要がある
- S7. 既存のDNSSECよりも強力な、委任のためのセキュリティモデルを備える必要がある
WGでは引き続き、標準化に向けたさまざまな課題に関する議論や、採用する仕様に関する議論が進められることとなりました。
IEPG Meetingの状況
IEPG（Internet Engineering and Planning Group）は、IETF会合に先立って開催される会合で、インターネットの運用に関連するさまざまなテーマを取り扱っています。
▽委任されていないTLDへのアクセスの状況
ICANNのRoy Arends氏から「The Rise and Fall of an Undelegated Domain: The Impact of a Global Misconfiguration（参考訳：委任されていないドメインの興亡：グローバルな構成ミスの影響）」と題し、ルートサーバーに到達するクエリの観測で検出された、委任されていないTLDへのアクセスの状況が報告されました。
報告では、2024年4月ごろから「.scloud」という存在しないTLDへの多数のアクセスが観測されたことが報告されました。内容について調査した結果「collector.azure.microsoft.scloud」への問い合わせであったことから、Microsoftに確認したところ5月13日に同社の知人と連絡がとれ、バグであることの確認と修正が実施された結果、当該クエリは段階的に収束した旨が報告されました。
