[第116回IETF Meeting報告] DNS関連WG・BoF・サイドミーティングの状況

本記事では、第116回IETF Meetingにおける話題から、DNS関連WG・BoF・サイドミーティングの状況についてご紹介します。

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

▽コンパクトなDNSSEC不在応答（draft-huque-dnsop-compact-lies）

動的に生成するDNSSEC不在応答^[*1]の内容を工夫することで生成に必要なコストを下げ、応答サイズを小さくするための機能拡張の提案です。

DNSSECにおいてゾーン列挙^[*2]を防ぐために不在応答を動的に生成する方法は、RFC 4470で定義されています。この方法でNXDOMAIN応答^[*3]を生成する場合、そのドメイン名の不在を証明するNSEC RRとワイルドカードの不在を証明するNSEC RRの二つを生成し、それぞれに署名する必要があります。

本提案では、この際にNXDOMAIN応答の代わりにNODATA応答^[*4]を生成するようにすることで必要なNSEC RRの数を減らし、応答生成のコストを下げると共に、応答サイズを小さくしています。

この方法では、本来はNXDOMAIN応答を返す場合もNODATA応答を返すようになるため、NXDOMAIN応答をキャッシュすることで抑制されていたDNS問い合わせが、権威DNSサーバーに送られてしまう可能性があります。そのため、本提案では当該NODATA応答のNSECタイプビットマップに「NXNAME」を追加することで、存在しない名前の応答であることを受け取り側が判別できるようにしています。

発表では、本提案は2016年に提案されたdraft-valsorda-dnsop-black-lies（NSEC Black Lies）が原型になっており、CloudflareのマネージドDNSサービスやAmazon Route 53などの大手マネージドDNSサービスで既に運用されているものの、元の提案が標準化されていないため、改良を加えた上で改めて提案したものであることが示されました。

参加者からは「CloudflareがNXNAMEのタイプコードに実験用の65283を割り当て、本提案の試験運用を始めている^[*5]」「本提案とRFC 8198^[*6]との関係について言及した方がよい」などのコメントなどがあり、継続して作業を進めることになりました。

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

DNS NOTIFYを拡張し、さまざまな用途に利用できるようにするための、機能拡張の提案です。

DNS NOTIFYはRFC 1996で定義され、SOA RRの更新を送信先に伝えることで、ゾーンデータの更新を通知します。DNS NOTIFYを使うことでプライマリサーバーとセカンダリサーバーの間のゾーンデータの同期を、短時間で実現できるようになります。

本提案はDNS NOTIFYを拡張し、他のRRの更新通知にも使えるように一般化することで、よりよいDNS・DNSSECの運用に役立てることを目的としています。

発表者からは、CDS RR^[*7]やCSYNC RR^[*8]による子ゾーンから親ゾーンへの情報伝達、複数のマネージドDNSサービスを利用する場合のDNSSEC署名鍵の共有が、ユースケースとして紹介されました。

参加者からは「本機能を実装する場合、セキュリティの観点から従来のNOTIFYのものとは別のアクセスコントロールリストが必要になる」「UDPは送信元アドレスの偽装が容易であるため、それ以外のトランスポートを使うことにした方がよい」などのコメントがあり、継続して作業を進めることになりました。

▽DNSプロトコル外でのシグナリング
（draft-grubto-dnsop-dns-out-of-protocol-signalling）

DNSサーバーソフトウェアが経路制御など、DNSプロトコルに直接関与しない外部のプログラムやサービスにシグナルを送る方法を定める、機能拡張のための提案です。

本提案の著者には主要なオープンソースのDNSサーバーソフトウェアの開発元（ISC・PowerDNS・CZ.NIC・NLnet Labs）の技術者が含まれており、それらのDNSソフトウェアと外部のプログラムやサービスとの連携の方法を共通化することで、権威DNSサーバーやフルリゾルバーの運用に役立てる狙いがあります。

本提案は、WGに参加していたI-Rootの運用者の一人であるLars-Johan Liman氏から良い提案である旨のコメントがあるなど好意的であり、継続して作業を進めることとなりました。

addはAdaptive DNS Discoveryに由来しており、パブリックネットワーク・プライベートネットワーク・VPNを含むさまざまなネットワーク環境において、DNSクライアントがリゾルバーを発見・選択するための技術的な仕組みの作成を目的としています。

▽標準化作業の進捗状況

add WGでは主要な提案に関する作業を終え、スプリットホライズン環境^[*9]におけるリゾルバーの発見・選択の取り扱いなど、残っている作業を進めています。

WGでは現在の提案に対する反対意見はなく、現在の作業を継続することになりました。

なお、HTTPS/SVC RRのRFC発行の遅れの影響を受けていたadd WGの三つの提案（draft-ietf-add-ddr、draft-ietf-add-dnr、draft-ietf-add-svcb-dns）についても、順次RFCの発行が進められる見込みになっています。

ドメイン名の管理境界を識別・判定する仕組みを取り扱うdbound WGを再開するための、dbound2 BoFが開催されました。dbound WGは2014年にBoFが開催され、2015年にWGとなりましたがRFCの発行には至らず、2017年に活動を終了しています。

▽ドメイン名の管理境界とは

インターネットにはドメイン名の管理境界（domain boundaries）を識別して、動作を変えているサービスやソフトウェアが存在します。

例えば、Webサーバーwww.example.comが「domain=example.com」という属性を設定してクッキーを発行した場合、Webブラウザーはそのクッキーを、blog.example.comやwww2.example.comなど、example.comの別のWebサーバーにも送信します。

しかし、Webサーバーexample.co.jpが「domain=co.jp」という属性を設定してクッキーを発行しても、Webブラウザーはそのクッキーを、example2.co.jpやexample3.co.jpなどのWebサーバーには送信しません。

このように、Webブラウザーはcomとco.jpでは利用者が登録可能なドメイン名の階層が異なるため、管理境界が異なっていることを認識して、動作を変えています。

▽Public Suffix Listとは

Webブラウザーはこの管理境界の判定を、Public Suffix List（以下、PSL）というリストで行っています。PSLは約1.4万行の長大なテキストファイルで、Firefoxを開発するMozilla Foundationが管理し、無償で公開しています^[*10]。

Webブラウザーには、開発時点のPSLがハードコード（埋め込み）されています。

▽当面の活動目標

今回のBoFではdbound2の当面の活動目標を、PSLを含む現在の手法・手順の見直しとユースケースの洗い出しに限定し、最初の活動として、現状の問題点を洗い出す文書（draft-tjw-dbound2-problem-statement）の作成を進めることになりました。

ルートゾーンのアルゴリズムロールオーバーに関する検討状況を共有する「Meet the Root Zone Algorithm Rollover Design Team」ミーティングが、新たに組織されたデザインチーム（後述）の主催で開催されました^[*11]。

▽アルゴリズムロールオーバーの概要と検討の背景

DNSSECで使われる暗号・署名のアルゴリズムを変更することを、アルゴリズムロールオーバーと呼びます。DNSSECによる保護を維持する形でアルゴリズムロールオーバーを実施する場合、所定の手順が必要になります。

従来、DNSSECでは署名鍵のアルゴリズムとして、RSAを用いた方式が広く使われてきました。これを、楕円曲線デジタル署名アルゴリズム（ECDSA）を用いた方式に変更することで、同じレベルの安全性をより短い鍵で実現でき、署名のサイズ、つまりDNS応答のサイズをより小さくできます。

そうしたメリットから、.chや.czなどのTLDではECDSAを用いた方式へのアルゴリズムロールオーバーを実施済みとなっており、ルートゾーンにおいても将来のアルゴリズムロールオーバーに向けた検討が必要になる旨が、識者から指摘されていました。

▽アルゴリズムロールオーバーの検討状況

こうした指摘を受け、ICANNはルートゾーンのアルゴリズムロールオーバーの手順と計画の作成を支援するためのデザインチームの結成を決定し、検討を開始しました。デザインチームには、JPRSの米谷嘉朗がメンバーとして参加しています。

デザインチームは2023年7月に推奨事項の草案を公開してパブリックコメントを実施し、2023年9月に推奨事項の最終版を公開する予定です。

ミーティングではデザインチームの役割と現在までの検討状況が共有されました。また、今後のスケジュールとして、2023年から2025年に実施される次回のルートゾーンKSKロールオーバーではアルゴリズムロールオーバーは実施されないため、アルゴリズムロールオーバーは2028年の第4四半期を見込んでいる（Possible）旨が、IANAの担当者から発表されました。