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

▽DNS NOTIFYの拡張（draft-ietf-dnsop-generalized-notify）

DNS NOTIFY[*1]を拡張し、従来から利用されているゾーン転送の効率化に加え、親ゾーンと子ゾーンの間のメンテナンスにも利用できるようにするための、機能拡張の提案です。本提案のユースケースとして、子ゾーンから親ゾーンにCSYNC RR[*2]やCDS/CDNSKEY RR[*3]の変更を通知できるようにすることが想定されています。

本提案を使用する場合、親ゾーンが当該DNS NOTIFYの送付先ホストとポート番号を、DSYNCという新しいRRを使って事前公開します。例えば、comゾーンがexample.comゾーンのCDS RRのDNS NOTIFYをcds-scanner.example.netの5359番ポートで受け付ける場合、comゾーンに以下のように記述します。

example._dsync.com. IN DSYNC CDS 1 5359 cds-scanner.example.net.

その後、example.comゾーンでCDS RRを更新した際に「example._dsync.com」のDSYNC RRを名前解決して送り先が調べられ、cds-scanner.example.netの5359番ポートに、DNS NOTIFYで更新が通知されます。

WGでは、DSYNC RRを定義するのではなくSVCB RRを使うのはどうか、TLDレジストリは本提案をどう実装すべきか、_dsync.TLDを委任して管理すべきか、などといったコメントがあり、継続して作業を進めることとなりました。

▽DNSロードバランシングに関するサイドミーティングの状況

IETF Meeting開催中の2024年7月24日にdnsop WGの有志が集まる形で、DNSロードバランシングに関するサイドミーティング[*4]が開催されました。 今回、1回目のdnsop WGでミーティングの開催がアナウンスされ、2回目のdnsop WGで状況が報告されました。

権威DNSサーバーの応答を問い合わせ元の地域ごとに変更して負荷分散を実現する技術はGeoDNSやGSLBなどと呼ばれており、大手CDN[*5]プロバイダーやクラウドサービスプロバイダーなどを中心に、25年以上前から利用されています。

しかし、IETFではこれまでDNSロードバランシングに関する議論や標準化は行われておらず、各サービスプロバイダーが実装・サービスする方式には互換性がありませんでした。その問題を解決するため、今回のサイドミーティングはDNSロードバランシングの現状を認識し、今後の進め方を議論することを目的として開催されました。

ミーティングではサービスを実装・提供している関係者から現状が共有された後、DNSロードバランシングに関するさまざまなアイディア・懸念点が共有、議論され、今後メーリングリストを新たに作成して議論を継続することとなりました[*6]。

▽委任における現在の問題点とDELEG RRが満たすべき要求事項（draft-wirelela-deleg-requirements）

DELEG WGにおいて最初にまとめられた、DELEG RRが満たすべき基本的な枠組みをまとめた要求事項に関する提案です。

本提案では要求事項を、すべての場合において厳密に要求される「ハード要件（Hard Requirements）」と、特定の問題への対応のために必要な「ソフト要件（Soft Requirements）」に分類し、最初のハード要件として、以下の5項目を挙げています。

• DELEGは、既存のドメイン名登録モデルを混乱させてはならない
• DELEGは、現在の名前空間の意味付けを変更してはならない
• DELEGは、ほとんどのDNSソフトウェアに悪影響を与えてはならない
• DELEGは、DNSSECを使用して委任を保護できなければならない [*8]
• DELEGは、NS RRによる既存の方法と同じ容易さで委任情報の更新をサポートしなければならない

また、最初のソフト要件として、以下の7項目を挙げています。

• DELEGは、新しいDNSトランスポートの仕組みの利用を促進すべきである
• DELEGは、サービスアクセスポイントへの接続の詳細を明確にすべきである
• DELEGは、使用時のトランザクションコストを最小限にすべきである
• DELEGは、運用者がDNSサービスをより完全に管理できるようにすべきである
• DELEGは、従来のNSによる委任へのマッピングを許容すべきである
• DELEGは、EDNS0と同様、簡単に拡張できるべきである
• DELEGは、子に関する親側のRRを更新する必要があることを子が親に通知するための手段をサポートすべきである

WGでは、DELEGとNSを併用することの是非や、DELEGのみの委任に関する議論などが進められました。本提案は今後、情報提供（Informational）RFCの発行に向けた作業が続けられる予定です。

▽今回のWGで議論・報告された要求事項・項目

今回のWGでは前述した基本的な枠組みに加え、以下の2項目に関する要求事項が議論されました。

DELEG RRではHTTPS RRと同様、エイリアスモードを使用した委任先の記述や、委任先の権威DNSサーバーがサポートするトランスポートの種類を記述できるため、それらに関する要求事項が個別に議論されることとなりました。

また、gTLDの管理運用への影響についても報告・議論されました。DELEG RRはgTLDの既存のドメイン名登録モデルを混乱させてはならないこと、gTLDのゾーンファイルに記述可能なRRはICANNとの契約で制限されているため、運用を開始する際には契約の更新が必要になること、契約上の制限はコミュニティからのインプットで変更可能であることが共有されました。

▽親側にのみ存在するRRの取り扱い（draft-arends-parent-only-record-signalling）

DELEG RRはゾーンカット[*9] の親側にのみ存在するRRとして提案されています。こうしたRRをDNSで取り扱う場合、DS RRと同様、DNSの仕様に変更を加える必要があります。

今回、DELEG RRの導入を踏まえ、このRRは親側にのみ存在するという旨をリゾルバーに知らせることができるようにする仕組みが提案・報告されました。

▽deleg WGの今後の展望

DELEG RRに関する議論はまだ始まったばかりであり、今後長期間にわたる議論・標準化作業が必要になると考えられます。WGでは2025年12月までのマイルストーンが示されており、今後、標準化に向けたさまざまな課題に関する議論や、仕様に関する議論が進められる予定となっています。

次回のWGでは、プロトコル拡張に関する議論が進められる予定です。