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

▽dnsop WGからプロトコルの拡張・メンテナンスを分離する検討が開始

2025年9月10日に、dnsop WGのチャーターが改訂されました。

新しいチャーターには、2013年にdnsext WGが終了した後dnsop WGで進められてきたDNSプロトコルの拡張・メンテナンスを新たなWGを創設して分離するか、dnsop WGに残すかを検討し、その結果を踏まえて2年以内に改めてチャーターを改訂するという、新たな活動方針が盛り込まれました。

dnsop WGでは10年以上にわたり活発な活動が続けられており、多数のRFCが発行されてきました。ここ数年のIETF MeetingにおいてWGの開催枠が2回分設定されるなど、その状況は現在も続いています。こうした状況から今回の改訂にはdnsop WGの負荷を下げ、標準化活動の効率を向上させる狙いが含まれています。

チャーターの改訂後、2025年10月7日に本件を進めるための専用のメーリングリストdns-at-ietfが作られ、検討が進められています。

▽DNSSECアルゴリズムのライフサイクル管理の文書化（draft-crocker-dnsop-dnssec-algorithm-lifecycle）

DNSSECアルゴリズムにおけるライフサイクルのフェーズと、それぞれのフェーズに移行するための基準を定義する提案です。本提案はRFCの発明者であり、1969年に発行されたRFC 1の著者でもあるSteve Crocker氏が共著者となっており、会場での発表と質疑応答も担当しました。

DNSSECに使われる暗号方式や電子署名方式には固有の番号とニーモニックが割り当てられ、DNSSECアルゴリズムとしてIANAに登録・管理されます。

提案ではDNSSECアルゴリズムのライフサイクルのフェーズとして、Experimental（実験）、Adopted（採用）、Available（使用可能）、Mainstream（主流）、Phaseout（段階的廃止）、Deprecated（非推奨）、Obsoleted（廃止）の7段階を定義し、アルゴリズムがそれぞれのフェーズに変化する際の条件について検討しています。

DNSSECアルゴリズムのフェーズ（引用元：dnsop WGの発表資料）

会場からは、「セキュリティエリアで一般的なものを作ろうとしてできなかった項目で、DNSSECに範囲を限定して始めることはありがたい」「本件を進める場としてIETFのdnsop、IANA、IRTFのcfrgなどが考えられるが、どこで進めるべきか」などのコメントが寄せられ、継続して検討を進めることになりました。

▽委任先が存在しないゾーンカットの設定（draft-jabley-dnsop-zone-cut-to-nowhere）

委任先が存在しないゾーンカットを親ゾーンに設定する手段を定義する、プロトコル拡張のための提案です。

DNSでは、親ゾーンにNSリソースレコード（RR）を設定することでゾーンカットが設定されます。NS RRには委任先のネームサーバーホスト名が指定され、名前解決の際に参照・利用されます。

本提案では、RFC 7505で定義されるNull MX（そのドメイン名では電子メールを受け取らないことを示すMX RR）と同様、委任先のネームサーバーホスト名として"."（長さ0のドメイン名）を指定することで、ゾーンカットは存在するが委任先が存在しないことを示すNS RRの設定を可能にしています。

会場からは、「この設定はテストしたのか」「導入するとフルリゾルバーから権威DNSサーバーへのトラフィックが増えるのではないか」といったコメントがありました。発表者からは、「本件については既に多数のテストを実施したが、不具合は見られなかった」という旨が回答され、継続して標準化作業を進めることになりました。

▽基本仕様に関する標準化作業の状況（draft-ietf-deleg）

WGでは、DELEG RRの基本仕様に関する標準化活動の振り返りと、今後の活動に関する議論が集中的に進められました。

DELEG RRの標準化では、従来のNS RRとグルーレコードによる委任を置き換える／併存させる部分を最初に進め、フルリゾルバーと権威DNSサーバーの通信の暗号化に使う証明書の情報など、DELEG RRの追加機能については、基本仕様の標準化作業の完了後に進めることが合意されています。

今回は作業状況の中から、以下の2項目について報告します。

• パケットフォーマットの変更
• In-domainとSibling domain/Unrelatedの取り扱いの明確な分離

▽パケットフォーマットの変更

当初、DELEG RRのフォーマットにはHTTPS/SVCB RRのフォーマットがそのまま使われていました。

その後、本稿執筆時点の仕様（draft-ietf-deleg-05、以下deleg-05）ではkey=value方式によるシンプルな記述を前提とし、HTTPS/SVCB RRのSvcParamsフィールドの部分を利用した専用のフォーマットに変更されました。

▽In-domainとSibling domain/Unrelatedの取り扱いの明確な分離

DNSにおいて、委任先ゾーンとネームサーバーホスト名の関係は、In-domain、Sibling domain、Unrelatedの3種類に分類されます。

以下に、In-domain、Sibling domain、Unrelatedの定義と、jpからexample.jpの委任におけるネームサーバーホスト名の例を示します。

現在のNS RRとグルーレコードによる委任では、委任元の権威DNSサーバーが応答を返す際、

• In-domain：グルーレコードを付加する（名前解決にグルーレコードが必須）
• Sibling domain：付加できる場合、グルーレコードを付加する（名前解決の効率が向上）
• Unrelated：グルーレコードを付加しない

のように動作します。deleg-05ではこれに対応するDELEG RRの仕様を、

• In-domain：権威DNSサーバーのIPアドレスのみを記述し、ホスト名の記述を禁止する
• Sibling domain/Unrelated：権威DNSサーバーのホスト名のみを記述し、IPアドレスの記述を禁止する

のように、In-domainの場合とそれ以外の場合の2通りとし、In-domainの場合はIPアドレスのみ、Sibling domain/Unrelatedの場合はホスト名のみを記述する形にすることで、取り扱いをシンプルにしています。

以下に、それぞれの場合における、DELEG RRの記述例を示します。

（In-domainの記述例）
example.jp.    IN DELEG server-ipv4=192.0.2.1,192.0.2.2 server-ipv6=2001:db8::1,2001:db8::2
（Sibling domainの記述例）
example.jp.    IN DELEG server-name=ns1.example.ne.jp.,ns2.example.ne.jp.
（Unrelatedの記述例）
example.jp.    IN DELEG server-name=ns1.example.com.,ns2.example.com.