第111回IETF Meeting報告

2021年7月26日から30日にかけ、第111回IETF Meeting（以下、IETF 111）が、オンラインで開催されました。新型コロナウイルス感染症の拡大を受け、IETF Meetingは2020年3月に開催されたIETF 107以降、オンラインでの開催が続いています。

今回のFROM JPRSでは、オンライン会合の開催状況、DNS関連RFCの発行状況、及びDNS関連WGにおける話題について、以下の項目に沿ってお伝えします。

• オンライン会合の開催に関する話題
  - 開催の状況
• IETF 110以降に発行されたDNS関連のRFC
  - 相互運用可能なDNSサーバークッキー（RFC 9018）
  - DNSにおけるプライバシーに関する考慮事項（RFC 9076）
  - NSECとNSEC3のTTLに関する仕様変更（RFC 9077）
  - TLS上でのゾーン転送（RFC 9103）
• dnsop WGにおける話題
  - 議論された主な提案の内容と作業の進行状況
• dprive WGにおける話題
  - 議論された主な提案の内容と作業の進行状況
• add WGにおける話題
  - 議論された主な提案の内容と作業の進行状況
• 次回のIETF Meetingについて

▼開催の状況

前回に引き続き、今回のIETF 111もフルアジェンダの形でオンライン開催され、世界各地から1,300人以上が参加しました。会合の時間は、当初の開催予定地であった米国サンフランシスコの時間帯（UTC-7）を基準にしてスケジュールされました。

前回のIETF 110以降に発行された、DNS関連のRFCの内容をご紹介します。

▼相互運用可能なDNSサーバークッキー

• RFC 9018: Interoperable Domain Name System (DNS) Server Cookies
  （Standards Track、draft-ietf-dnsop-server-cookies）

RFC 9018は、IP Anycast[*1]を用いて複数台／複数種類のサーバーを運用する際に相互運用可能なDNSクッキー[*2]の作成方法を定義します。RFC 9018は、RFC 7873を更新します。

DNSクッキーには、問い合わせに付加するクライアントクッキーと、応答に付加するサーバークッキーの2種類があります。サーバークッキーの生成には受け取ったクライアントクッキーが使われ、通信相手を相互に確認します。

しかし、従来のRFC 7873では、サーバークッキーの生成アルゴリズムはサーバーソフトウェアの実装者の判断に委ねられており、IP Anycastを用いて複数台／複数種類のサーバーを運用する際、複数のサーバー間でのサーバークッキーの相互運用が困難になるという問題がありました。

RFC 9018はこの問題を解決するため、相互運用可能なサーバークッキーの生成方法、クッキーの生成に必要なサーバーシークレット[*3]の更新方法を定義します。

RFC 9018はこれと併せ、クライアントクッキーの生成におけるプライバシーの保護についても言及しています。

▼DNSにおけるプライバシーに関する考慮事項

• RFC 9076: DNS Privacy Considerations
  （Informational、draft-ietf-dprive-rfc7626-bis）

RFC 9076は、DNSにおいてプライバシーを考慮する際に必要な項目を洗い出し、それぞれの項目に関する考察をまとめたものです。

RFC 9076は、既存のRFC 7626を置き換えます。RFC 7626からの主な更新点は、以下の通りです。

• 参照文献の更新
• 暗号化されたトランスポートに関する議論と、DNSペイロード・サーバーの認証・名前解決サービスのブロックに関する記述の追加
• QNAME minimisation[*4]のRFC公開を反映
• セルラーネットワークのDNS、DNSブロッキングとセキュリティに関する記述の追加
• フルリゾルバー（キャッシュDNSサーバー）に関する考慮事項の追加
• リゾルバーの選択に関する議論の追加

▼NSECとNSEC3のTTLに関する仕様変更

• RFC 9077: NSEC and NSEC3: TTLs and Aggressive Use
  （Standards Track、draft-ietf-dnsop-nsec-ttl）

RFC 9077はDNSSECの仕様を更新し、NSECレコードとNSEC3レコードのTTLの定義を変更します。

DNSの不在応答[*5]には、SOAレコードが含まれます。含まれるSOAレコードのTTLは、SOAレコード自身のTTLとSOAレコードのMINIMUMフィールドの値のうち小さい方の値となり、その値がネガティブキャッシュのTTLとして使われます。

RFC 8198では、リゾルバー側でキャッシュ済みのNSECレコードとNSEC3レコードを活用し、権威DNSサーバーに問い合わせることなく不在応答を生成します。リゾルバー側が不在応答を生成する期間は、キャッシュされたNSECレコードとNSEC3レコードのTTLに依存します。

DNSSECの仕様では、ゾーンの署名時に生成されるNSECレコードとNSEC3レコードのTTLはSOAレコードのMINIMUMフィールドの値と同じにすべき（SHOULD）と定義されています。そのため、もしMINIMUMフィールドの値がSOAレコードのTTLよりも大きかった場合、RFC 8198によってフルリゾルバーが不在応答を生成する時間が、ゾーンの管理者が意図したものよりも長くなってしまう可能性があります。

RFC 9077はこの問題を解決するため、ゾーンの署名時に生成されるNSECレコードとNSEC3レコードのTTLとして、SOAレコード自身のTTLとSOAレコードのMINIMUMフィールドの値のうち小さい方を使用するように、プロトコルの仕様を変更します。

RFC 9077は、既存のRFC 4034、4035、5155、8198を更新します。

▼TLS上でのゾーン転送

• RFC 9103: DNS Zone Transfer over TLS
  （Standards Track、draft-ietf-dprive-xfr-over-tls）

RFC 9103は、ゾーン転送[*6]の通信をTLS[*7]上で行う、XFR-over-TLS（XoT）の仕様を定義します。

ゾーン転送の通信は暗号化されないため、攻撃者が権威DNSサーバー間の通信を傍受できた場合、ゾーンの設定内容を収集できます。XoTはゾーン転送の通信をTLSで暗号化することで情報の収集を防止し、ゾーン情報のプライバシーを確保します。

XoTはゾーンのすべての情報を送るAXFR、あるバージョンからの差分のみを送るIXFRの双方を、AXoT、IXoTとしてサポートします。また、TLSは通信相手の認証も提供することから、DNSの通信に電子署名を付加して通信相手を認証するTSIGの機能も実現できます。

RFC 9103は、IXFRを定義したRFC 1995、AXFRを定義したRFC 5936に加え、DNSのTCPサポートにおける実装上の要求事項を定義したRFC 7766を更新します。

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

▼議論された主な提案の内容と作業の進行状況

▽DNSにおけるIPフラグメンテーションの回避
（draft-ietf-dnsop-avoid-fragmentation）

JPRSの藤原和典が第一著者となっている、DNSにおけるIPフラグメンテーション[*8]を回避するための提案です。

今回の発表では、前回から議論されているDNS/UDPの最大ペイロードサイズの推奨値の検討が進められました。藤原は、IPv4とIPv6におけるDNS/UDPの最大ペイロードサイズの推奨値は一つに定めず、以下の5種類からオペレーターが選択可能であると記載した旨を報告しました。

• 1220：DNSSECでサポートしなければならない最小値
• 1232：DNS flag day 2020の推奨値
• 1400：著者の推奨値（1500 - 40 - 8 - ヘッダー）
• 1472（IPv4）と1452（IPv6）：EthernetのMTU（1500）に基づく最大値
• MTUに基づいた実測値：MTU - 20 - 8（IPv4）とMTU - 40 - 8（IPv6）

推奨値を一つに定めないことについて、参加者からはそれでよいという肯定的 なコメントと、推奨値を定めないのは問題ではないかという否定的なコメント の双方が寄せられました。

また、藤原はIETF 111と同時開催されたANRW'21[*9]で発表される予定の研究発表「DNS-over-TCP Considered Vulnerable[*10]」の内容が本提案に影響を与える可能性があることから、研究発表の概要を紹介した上で、WG参加者にワークショップへの参加を呼び掛けました。

参加者からは、研究発表の資料に記述されているAlexa Top Sites[*11]のトップサイト10万のうち496が脆弱であったという点について、対象が全体の0.5％と低いことから、本提案には影響を及ぼさないのではないかというコメントがありました。

藤原は、この研究発表の影響がなければ、本提案のワーキンググループラストコール（WGLC）を実施してほしい旨をチェアに依頼し、継続して作業を進めることとなりました。

▽委任応答のグルーレコードはオプションではない
（draft-ietf-dnsop-glue-is-not-optional）

RFC 1034を更新し、DNSメッセージサイズの制約によりUDPの委任応答にすべてのグルーレコードを含めることができない場合に、権威DNSサーバーが応答にTC（切り詰め）ビットをセットして、フルリゾルバーにその旨を通知する必要があることを明確化するための提案です。

本提案は当初、RFC 1034の4.3.2.で定義される名前解決アルゴリズムに、グルーレコードを応答に含めることができない場合にTCビットをセットする旨を追加するだけの、シンプルな提案でした。

その後、必要なグルーレコードとして何を含めるかが議論の対象となり、TCビットをセットする条件として「Sibling Glue」の記述が追加されました。本提案ではSibling Glueを「同じ親からの別の委任ゾーンにグルーレコードとして含まれるA/AAAAレコード」と記述しており、Sibling Glueを権威DNSサーバーが付加できなかった場合についても、TCビットをセットする条件に含めるとしています。

WGでは、Sibling Glueの定義が明確でないこと、Sibling Glueを必須とした場合、キャッシュポイズニングに使われたり、tsuNAME[*12]のような問題を引き起こしたりするリスクがあるのではないかといった懸念がコメントされ、継続して作業を進めることとなりました。

本件は、DNSプロトコル仕様やサーバーソフトウェアの実装に加え、ドメイン名レジストリがネームサーバーのホスト情報として何を受け付け、どう取り扱うかという点も関係しており、今後の議論の対象となる可能性があります。

▽複数の署名者が存在する場合のDNSSECの運用自動化
（draft-wisser-dnssec-automation）

RFC 8901で定義される、一つのゾーンに複数の署名者（マルチサイナー）が存在する場合のDNSSECの運用シナリオと鍵管理の要件を実装するための、アルゴリズムとプロトコルを定義する提案です。

本提案では、RFC 8078で定義されるCDSレコードとRFC 7477で定義されるCSYNCレコードを用いて、マルチサイナー環境におけるDNSSEC運用者の切り替えを含む、DNSSEC運用を自動化するためのアルゴリズムを定義します。

会合では、アルゴリズムの実装に向けた活動状況はどうなっているかという質問がありました。それに対し、現在PowerDNSとBINDで実装を進めており、ISCと協力して相互運用性の評価をしている旨の回答があり、継続して作業を進めることとなりました。

dpriveはDNS PRIVate Exchangeに由来しており、通信の暗号化によってDNSトランザクションにおける機密性（confidentiality）を提供し、プライバシーを確保することを目的としています。

スタブリゾルバーとフルリゾルバー間の通信の暗号化に関する標準化作業は、DNS over TLS（DoT）とdoh WGによるDNS over HTTPS（DoH）の標準化により完了しました。現在、WGでは次の段階として、フルリゾルバーと権威DNSサーバーの間の通信や、権威DNSサーバー間のゾーン転送を暗号化するための作業が進められています。

▼議論された主な提案の内容と作業の進行状況

▽DNS over QUICの仕様（draft-ietf-dprive-dnsoquic）

DNS over QUIC（以下、DoQ）はDNSの通信にQUIC[*13]を使用して、プライバシーを保護するための提案です。

本提案ではDoQのポート番号として、UDP/853の割り当てを提案しています。UDP/853は実験仕様としてRFC 8094となったDNS over DTLSと同じポート番号ですが、DNS over DTLSとはデータ形式が異なるため、実装側で識別可能です。

今回の提案では、DoQの利用範囲をDNSの三つのトランスポート（スタブリゾルバーからフルリゾルバー、フルリゾルバーから権威DNSサーバー、ゾーン転送）とすると共に、データ形式がTCP及びDoTにおけるDNSのデータ形式と同じ形に修正されました。今後、残りの課題についての議論を進め、結論が見えたところでWGLCに進む見込みとなっています。

▽フルリゾルバーと権威DNSサーバー間の通信の暗号化に関する議論の状況

dprive WGではフルリゾルバーと権威DNSサーバー間の通信暗号化のため、継続的な議論を進めてきました。IETF 109ではプライバシー確保のために必要な要求事項の検討が進められ[*14]、IETF 110では暗号化を実現するためのサーバー証明書の検証方式と、暗号化の有無を検出する方式に関する検討が進められました[*15]。

今回のWGでは、暗号通信に必要な権威DNSサーバーのサーバー証明書の情報をどこにどう置くかについての議論が、活発に進められました。

現在、候補となっている方式には、以下のものがあります。

1.の方法では、SVCBレコードの名前解決までは暗号化を有効にできないため、情報が漏えいすることと、リゾルバーが当該ゾーンのSVCBレコードを名前解決しなければならないことによる、パフォーマンスの低下が問題視されました。2.から4.の方法は、1.の問題を解決するための手段として提案されているものです。

そのうち、2.についてはDNSプロトコルの大規模な書き換えと、ドメイン名レジストリ・レジストラが取り扱うデータの追加が必要であることから実現が難しく、3.と4.が追加で提案されました。

3.では親のNSレコードのホスト名のラベル、4.ではDSレコードのデータに子ゾーンのサーバー証明書の情報を格納することで、既存のDNSプロトコルとドメイン名レジストリ・レジストラが取り扱うデータの範囲で、サーバー証明書の情報を保持することを実現するものです。

本件について、今回のWGでは結論は出されず、今後も継続して作業を進めることとなりました。作業全体の方向性がまとまるまでには、まだかなりの作業を要すると予想されます。

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

▼議論された主な提案の内容と作業の進行状況

▽リゾルバーの構成を検出するための仕組み
（draft-ietf-add-ddr）

クライアントがDNS経由で暗号化リゾルバー[*16]の構成を検出する仕組みである「Discovery of Designated Resolvers（DDR）」を定義する提案です。

今回の提案では前回からの変更点として、暗号化リゾルバーの検出に使われるSVCBレコードは一対一の対応ではなく、複数の暗号化リゾルバーに対応付けられうること、検出に使われる特殊用途ドメイン名「resolver.arpa」の動作の明確化と例示を追加したことが報告されました。

会合では、resolver.arpaを使った場合DNSSECが機能しなくなるのではないか、このプロトコル仕様では、利用者は技術者でなければならないのではないかというコメントがありました。発表者からは、前者については暗号化リゾルバーの指定がIPアドレスであれば問題にならない、後者についてはDDRは暗号化リゾルバーを検出する仕組みであり、利用者側から見た場合ヒントに過ぎないと考えている旨の回答がありました。

議論の結果、継続して作業を進めることとなりました。

▽暗号化リゾルバーを検出するためのDHCP及びIPv6 RAのオプション
（draft-ietf-add-dnr）

クライアントが暗号化リゾルバーをローカルネットワーク内で検出できるようにするため、DHCPv4/v6、及びIPv6 RAに新しいオプションを定義する、プロトコル拡張の提案です。

今回の提案では前回からの変更点として、

• IETF 110で出されたコメントの反映
• Dynamic Host Configuration（dhc）WGの専門家のレビューを経た、新しいプロトコルデザインへの変更
• SVCBレコードのipv4hintとipv6hintの使用を禁止
• セキュリティに関する記述の追加

などを実施し、保留中の課題がなくなったため、WGLCを実施したい旨が報告されました。会合では、本提案のWGLCは関連文書であるDDRの進行を待ってからにすべきではないかというコメントがありました。

次回の第112回IETF Meeting（IETF 112）は2021年11月6日から12日にかけ、オンラインで開催される予定となっています[*17]。

本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。