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

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

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

dnsop WGで発表するJPRS藤原

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

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

この定義は、現在のランキングデータはRFCが発行された1997年当時の状況を反映する形で、ゾーンファイル・ゾーン転送・名前解決など、出自が異なるデータが共通のデータベースで保持され、かつ、一つのネームサーバーが権威DNSサーバーとフルリゾルバーの双方の機能を併せ持つモデルを想定しています。

提案では、DNSの運用状況の変化によりこのモデルは現在の運用状況を反映しておらず、改訂が必要であるとして、以下の4項目を指針として提示しています。

1. 権威DNSサーバーは、ゾーンデータを一つのソース（ゾーンファイル・内部データベース・ゾーン転送）から入手し、複数のソースのデータをマージしてはならない（MUST NOT）
2. 名前解決の結果（answerセクション、NXDOMAIN、NODATA）は、委任された権威DNSサーバーからの、権威を持つ応答でなければならない（MUST）
3. 権威DNSサーバーの権威を持たない応答（参照、委任）は、名前解決における委任先の権威DNSサーバーへの問い合わせにのみ使う（MUST）
4. ルートゾーンのように、あるゾーンの権威DNSサーバーの名前とIPアドレスがヒントファイルとして組み込まれている場合、その情報はそのゾーンに対するプライミングにのみ使う（MUST）

WGでは「委任部分の仕様変更を含んでいるため、より重要なdeleg WGの作業を優先すべきではないか」「この提案は以前から問題になっている項目であり、deleg WGの作業を待たず、今すぐクリーンアップしたい」「この提案とDELEGはいずれも重要であり、両方とも進めるべきだ」など、さまざまな意見があり、継続して作業を進めることになりました。

▽衝突が発生しないDNSSEC鍵タグ（draft-huque-dnsop-keytags）

DNSSECにおいて鍵の識別に使われる鍵タグ（Key Tag）の衝突を回避するための鍵生成のプロセスを定義し、DNSSECプロトコルを更新するための提案です。

鍵タグは、DNSSECの公開鍵（DNSKEYリソースレコード）から計算される、16ビットのチェックサムです。リゾルバーは鍵タグを確認し、検証対象となる鍵と署名を絞り込むことで、DNSSEC検証のコストを低減しています。

しかし、悪意を持つ者が鍵タグを意図的に衝突させた多数の鍵と多数の署名を持つゾーンデータを準備し、そのゾーンの名前をDNSSEC検証させるように仕向けることでDNSSEC検証のコストを高め、リゾルバーの名前解決を妨害する「KeyTrap」が2024年2月に公開され、問題となりました。本提案はDNSSEC鍵タグの衝突を禁止することで、KeyTrapによる攻撃をプロトコルの側面から防ぐことを目的としています。

現在の提案では仕様を開発する前段階として、取りうる手法と検討が必要な項目の洗い出しが進められています。取りうる手法として、衝突を禁止する新しいDNSSECアルゴリズム番号の導入、特定日以降に鍵タグの衝突を禁止するflag dayの実施などが検討されています。

また、検討が必要な項目として、一つのゾーンを複数のDNSプロバイダーが管理するマルチ署名者（RFC 8901で定義）環境における、鍵タグの衝突回避が挙げられました。提案ではそのために取りうる手法として、鍵タグ空間の分割、鍵を管理するブローカーの導入、DNSプロバイダー間の調整による衝突の回避が挙げられています。

本提案は開発に向けた検討が進められている段階であり、DNS運用における対応も必要になることから、今後も継続して作業を進めることになりました。

▽プライベート利用のためのTLD（draft-davies-internal-tld）

プライベートIPアドレス[1]に相当する、プライベートアプリケーションで使用するための「.internal」トップレベルドメイン（TLD）を定義するための提案です[2]。

今回、当初からの著者であるIANAのKim Davies氏とICANNのAndrew McConachie氏に加え、長年にわたりIETFのopsエリアのエリアディレクターを務め、現在はIABメンバーの一人であるGoogleのWarren Kumari氏が著者に加わり、内容の充実が図られました。

WGでは、Kumari氏から.internalの提案に至った経緯が改めて説明され、.internalをIANAの特殊用途ドメイン名（Special-Use Domain Names）に登録することと、本提案に関する作業をdnsop WGで進めることの是非が問いかけられました。

参加者からは大きな反対意見はなく、継続して作業を進めることとなりました。

▽IDELEG案とDELEG案の比較検討

今回のWGでは、現在提案されている「IDELEG案」と「DELEG案」の二つの内容を比較し、当面のターゲットとしてどちらを選択すべきかを定めるための議論が、集中的に進められました。

• IDELEG案

委任情報を記述するIDELEG RRを、親ゾーンに設定した専用のラベル（_deleg）の配下の、同じ階層構造に記述する提案です。例えば、jpゾーンの権威DNSサーバーにexample.jpゾーンとexample.co.jpゾーンの委任情報を記述する場合、以下のようになります。

$ORGIN jp.
example._deleg.jp.    IN IDELEG 10 ns1.example.jp. ipv4hint=192.0.2.1 ipv6hint=2001:db8::1
                      IN IDELEG 10 ns2.example.jp. ipv4hint=192.0.2.2 ipv6hint=2001:db8::2
example.co._deleg.jp. IN IDELEG 10 ns1.example.co.jp. ipv4hint=198.51.100.1 ipv6hint=3fff:123:4567::1
                      IN IDELEG 10 ns2.example.co.jp. ipv4hint=198.51.100.2 ipv6hint=3fff:123:4567::2

• DELEG案

委任情報を記述するDELEG RRを、ゾーンカットの親側に記述する提案です。例えば、jpゾーンの権威DNSサーバーにexample.jpゾーンとexample.co.jpゾーンの委任情報を記述する場合、以下のようになります。なお、本稿執筆時点のDELEG案では、グルーレコードを記述する形式が「Glue4/Glue6」に変更されています。

$ORIGIN jp.
example.jp.           IN DELEG 10 ns1.example.jp. Glue4=192.0.2.1 Glue6=2001:db8::1
                      IN DELEG 10 ns2.example.jp. Glue4=192.0.2.2 Glue6=2001:db8::2
example.co.jp.        IN DELEG 10 ns1.example.co.jp. Glue4=198.51.100.1 Glue6=3fff:123:4567::1
                      IN DELEG 10 ns2.example.co.jp. Glue4=198.51.100.2 Glue6=3fff:123:4567::2

WGでは、それぞれの案のメリットとデメリット、フルリゾルバーにおける取り扱い、従来のNS RR/グルーレコードによる委任との互換性維持の手法など、さまざまな項目が議論されました。

また、今回をもって担当エリアディレクターを退任するWarren Kumari氏から申し送り事項として、「現在のNS RR/グルーレコードによるDNSの委任の仕組みは40年間にわたって使われた。そのため、今回開発されるdelegについても、40年間使えるプロトコルをデザインしてほしい」という、強い要望がありました。

議論の後、現時点でデザイン案を一つに絞り込めるかと、IDELEGとDELEGのいずれの案が好ましいかについて、簡易投票が実施されました。結果は以下の通りで、DELEG案がより多くの支持を集めました。

しかし、いずれの提案も合意と見なせるほどの賛同を集められなかったため、WGでは最終的な結論は出されず、メーリングリストで議論が継続されることになりました。