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

本記事では、第118回IETF MeetingのDNS関連WGの状況と、IETFハッカソンの活動としてWGで報告された、DELEGリソースレコード（以下、RR）の提案についてご紹介します。

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

▽DNSのIPv6トランスポートに関する運用ガイドラインの改訂（draft-momoka-dnsop-3901bis）

DNSのIPv6トランスポートに関する運用ガイドラインとして、現状における最良の慣行（Best Current Practice：BCP）となっている、RFC 3901を改訂するための提案です。

2004年に発行されたRFC 3901では、IPv4のみの環境からIPv4とIPv6の混在環境に移行する過程における混乱を防ぐため、以下の2項目を定めています。

• すべてのフルリゾルバーはIPv4のみをサポートするか、IPv4/IPv6のデュアルスタックのいずれかにすべきである（SHOULD）
• すべてのゾーンの権威DNSサーバーには少なくとも1台、IPv4の到達性があるものが含まれるべきである（SHOULD）

本提案では、その後のIPv4アドレスの在庫枯渇の進行、長期的にはIPv6専用のリゾルバーが必要になること、名前解決の信頼性の確保などを考慮する形で、RFC 3901の項目を以下のように更新しています。

• すべてのフルリゾルバーはIPv4/IPv6のデュアルスタックにすべきである（SHOULD）
• ただし、IPv6での名前解決に失敗した際にIPv4の権威DNSサーバーに到達するための仕組み（draft-momoka-v6ops-ipv6-only-resolver）を使用するか、別のデュアルスタックのフルリゾルバーにクエリを転送するようになっている場合、IPv6のみであってもよい（MAY）
• 同様に、IPv4での名前解決に失敗した際に別のデュアルスタックのフルリゾルバーにクエリを転送するようになっている場合、IPv4のみであってもよい（MAY）
• すべてのゾーンの権威DNSサーバーは少なくとも2台、デュアルスタックであることが推奨される（RECOMMENDED）
• 少なくとも1台、IPv4到達性があるものが含まれるべきである（SHOULD）
• 少なくとも1台、IPv6到達性があるものが含まれるべきである（SHOULD）
• 当該ゾーンを利用するすべてのクライアントがIPv6をサポートしていると確認できる場合、IPv4でDNSサービスを提供しなくてもよい（MAY）

本提案に関する参加者の印象はおおむね好意的でしたが、参加者の一部から本提案によってIPv6における名前解決の失敗率が上がるのではないか、という懸念が指摘され、継続して作業を進めることとなりました。

▽Dynamic Updateを用いた委任情報管理の自動化（draft-johani-dnsop-delegation-mgmt-via-ddns）

Dynamic Update^[*1]を用いて親ゾーンの委任情報を更新する方法を定義する、機能拡張の提案です。

子ゾーンの管理者が親ゾーンのDNS情報を自動更新・同期する方法として、これまでにさまざまなものが提案・標準化されました。それらには以下のものが含まれています。

• 子が設定したCDS RR^[*2]を親がスキャンし、DS RRを更新する
• 子が設定したCSYNC RR^[*3]を親がスキャンし、委任情報を更新する
• DNS NOTIFYを拡張して子から親に更新を通知できるようにすることで、親のスキャンの効率を高める（draft-ietf-dnsop-generalized-notify^[*4]）

しかし、これらの方法はいずれも子ゾーンがDNSSEC署名されている場合にしか適用できず、非効率的で遅い上に親ゾーンの運用が大幅に複雑化することが指摘されています。そのため、本提案ではより効率的で迅速な更新が可能になり、かつDNSSEC署名されていない場合にも適用可能となる方法として、Dynamic Update経由での更新を提示しています。

参加者からは、Dynamic Updateを用いる際の認証の考慮が十分でない旨の指摘があり、継続して作業を進めることとなりました。

▽ほとんど分離されたネットワークにおけるDNS（draft-many-dnsop-dns-isolated-networks）

地球と月、地球と火星、惑星間などを含む深宇宙（deep space）の通信では、従来のインターネットでは想定されていない長い遅延と断続的な通信（intermittent communications）を前提とする必要があります。本提案は、そうした環境においてDNSを実現するための方法と考えうる問題点について、考察・解説しています。

本提案では前提となる要件・運用形態として、以下の4項目が挙げられています。

• シングルルートのDNS名前空間
• ほとんど分離された権威DNSサーバーに時々アクセスして、キャッシュを更新する機能
• インターネットのDNSインフラに対して現実的なDNSクエリを実行できない環境での動作
• 孤立したネットワーク上の複数のネットワークとDNS運用者が、それぞれの名前空間を管理

提案では、必要なすべての名前やDNSSEC検証に必要なRRを事前に検索しておく、必要なすべてのDNSゾーンを事前に取得しておく、有用なRRのみを含む特別なゾーンを作成・署名したものを遠隔のDNSインフラにまとめて送信する、といった方法が示されており、ゾーン転送やDNSSEC、ネットワークの運用についても、要考慮点として挙げられています。

深宇宙の通信は絵空事ではなく、解決すべき現実の問題として既に認識され始めており^[*5]、IETFにおいても議論を進めるための提案^[*6]、deepspaceメーリングリストの創設^[*7]、IETF 118におけるサイドミーティングの開催など^[*8]、具体的な検討が始まっており、今後の動向が注目されます。

今回のdnsop WGで、2023年11月4日から5日にかけて開催されたIETF 118ハッカソン^[*9]で生まれた、DNSの委任情報を記述するための新しいRRである「DELEG RR」の提案が紹介されました。

委任情報の取り扱いはDNSの基本機能の一つであるのと同時に、DNSの仕様・設計における、代表的な弱点の一つとなっています^[*10]。このことはDNSが運用され始めた1980年代から認識されており、問題解決に向けたさまざまなアプローチが試みられましたが、いずれも目立った成果を挙げることなく、現在に至っています。

DELEG RRは、SVCB/HTTPS RRのフォーマットを使って委任に関する情報をまとめて記述し、従来のNS RRとグルーレコードは互換性のために残すというアイデアに基づいています。

発表では、DELEG RRはハッカソンで生まれたばかりでまだ3日しか経っておらず、混乱や意見の相違が想定されると断った上で、具体的な記述例が紹介されました。以下、発表内容から、In-domain委任における記述例をご紹介します。

  $ORIGIN example.
  a      NS     ns1.a.example.                    ; 従来のNS RRは互換性のために残す
  ns1.a  A      192.0.2.1                         ; 従来のグルーレコードは互換性のために残す
         AAAA   2001:db8::1
  a      DS     01234 99 2 ABCDABCDABCD...
  a      DELEG  1 ns1.a.example. (                ; 委任情報をDELEG RRでまとめて記述する
                  ipv4hint=192.0.2.1
                  ipv6hint=2001:db8::1
                  transport=dot                   ; DNS over TLSやDNS over HTTPSも記述できる
                  otherinfo=needed for handoff )
  a      RRSIG  DELEG ...                         ; DELEG RRには親ゾーンが署名する

このように、DELEG RRにすべての委任情報をまとめて記述することで委任情報を効率よく入手でき、かつDS RRと同様の親ゾーンが権威を持つ情報とすることで、従来は不可能であった委任情報へのDNSSEC署名・検証が可能になります。

▽DELEG RRの議論と今後

DELEG RRに関する議論は現在、DNS-OARCのチャットサーバー上に作られた、deleg-designチャンネルで続けられています^[*11]。

議論の状況を受け、IETF 118後の2023年11月29日に開催されたRIPE MeetingのDNS WGでは、DELEG RRのパラメーターとしてDS RRのテキスト表現やTLSA RRのテキスト表現を追加し、信頼の連鎖のための情報やDoT/DoH/DoQのサーバー証明書の情報もDELEG RRに記述する提案が示されました^[*12]。

DELEG RRの標準化には多くの要考慮事項があり、DNS実装やドメイン名レジストリ・DNSプロバイダーといった関係者における対応など、標準化後にも必要になるであろう、さまざまな課題の発生も予想されます。しかし、本件はDNSに長年にわたって存在する問題の解決を図るための興味深い試みであり、今後の活動内容や方向性が注目されます。