バックナンバー：vol.198

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2021/08/31━
                    ◆ FROM JPRS 増刊号 vol.198 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                      第111回IETF Meeting報告
        ～オンライン会合の開催状況と、DNS関連WGにおける話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

前回の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を更新します。

[*1] JPRS用語辞典｜IP Anycast（アイピーエニーキャスト）
     https://jprs.jp/glossary/index.php?ID=0108

[*2] DNSメッセージに所定の方法で作成したデータ（クッキー）を付加するこ
     とで、HTTPのクッキーと同様の仕組みを実現し、キャッシュポイズニン
     グ対策に用いるための仕組み。

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

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

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

[*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サーバー）に関する考慮事項の追加
  ・リゾルバーの選択に関する議論の追加

[*4] RFC 7816で定義される、プライバシー保護の観点から、フルリゾルバー
     の名前解決アルゴリズムを変更する仕組み。

▼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として使われます。

[*5] JPRS用語辞典｜不在応答（Negative Answers）
     https://jprs.jp/glossary/index.php?ID=0187

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）
の仕様を定義します。

[*6] JPRS用語辞典｜ゾーン転送（zone transfer）
     https://jprs.jp/glossary/index.php?id=0170

[*7] Transport Layer Securityの略称。
     TCPのようなコネクション型プロトコルにおいて、暗号通信を行うための
     プロトコル。

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

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

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

■dnsop WGにおける話題

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

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

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

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

[*8] JPRS用語辞典｜IPフラグメンテーション（IP fragmentation）
     https://jprs.jp/glossary/index.php?ID=0180

今回の発表では、前回から議論されている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参加者に
ワークショップへの参加を呼び掛けました。

[*9] ACM SIGCOMMとIRTFが後援する、研究者・ベンダー・ネットワークオペ
     レーター・標準化コミュニティを対象とした学術ワークショップ。
     Applied Networking Research Workshop 2021 (ANRW'21)
     https://irtf.org/anrw/2021/

[*10] DNS-over-TCP considered vulnerable | Proceedings of the Applied
      Networking Research Workshop
      https://dl.acm.org/doi/10.1145/3472305.3472884

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

[*11] Alexa Internetが運営する、Webサイトの利用状況を調査し、統計デー
      タを提供するサービス。

藤原は、この研究発表の影響がなければ、本提案のワーキンググループラスト
コール（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プロトコル仕様やサーバーソフトウェアの実装に加え、ドメイン
名レジストリがネームサーバーのホスト情報として何を受け付け、どう取り扱
うかという点も関係しており、今後の議論の対象となる可能性があります。

[*12] JPRS用語辞典｜tsuNAME（ツネーム）
      https://jprs.jp/glossary/index.php?id=0275

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

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

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

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

■dprive WGにおける話題

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]を使用して、プライバ
シーを保護するための提案です。

[*13] Googleが2013年に公開した、汎用のデータ通信プロトコル。従来、TLS
      で実現していた通信路の保護・暗号化を始めとする、TCPに追加された
      さまざまな機能を標準でサポートしている。Googleの公開後、IETFで標
      準化作業が進められ、RFC 8999～9002として標準仕様が公開された。

本提案では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]。

[*14] 第109回IETF Meeting報告 | 2020年 | ドメイン名関連会議報告
       | ドメイン名関連情報 | JPRS
      https://jprs.jp/related-info/event/2020/1223ietf.html

[*15] 第110回IETF Meeting報告 | 2021年 | ドメイン名関連会議報告
       | ドメイン名関連情報 | JPRS
      https://jprs.jp/related-info/event/2021/0413ietf.html

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

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

  1. サーバー証明書の情報をSVCBレコードに格納し、子側に置く。当該SVCB
     レコードの名前解決については暗号化しない。

  2. サーバー証明書の情報をSVCBレコードに格納し、親側に置く。その上で、
     名前解決の際に当該SVCBレコードをグルーレコードとして得られるよう
     に、DNSプロトコルを更新する。

  3. 親に登録するNSレコードのネームサーバーホスト名のラベルに、サー
     バー証明書の情報をエンコーディングして格納する。

  4. 親に登録するDSレコードのデータに、サーバー証明書の情報をエンコー
     ディングして格納する。

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

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

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

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

■add WGにおける話題

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

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

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

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

[*16] 本提案では、クライアントとの通信が暗号化されたリゾルバーを暗号化
      リゾルバー（Encrypted Resolver）、通信が暗号化されていないリゾル
      バーを非暗号化リゾルバー（Unencrypted Resolver）と定義しています。
      以降の説明では、これらの用語を使用します。

今回の提案では前回からの変更点として、暗号化リゾルバーの検出に使われる
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の進行を待ってから
にすべきではないかというコメントがありました。

■次回のIETF Meetingについて

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

[*17] スペインのマドリードでの開催が予定されていましたが、新型コロナウ
      イルス感染症の状況を受け、オンラインに変更されました。

          ◇                     ◇                     ◇

◎関連URI

  - IETF | IETF 111 Online
    https://www.ietf.org/how/meetings/111/
    （IETF 111公式ページ）

  - IETF 111 Proceedings
    https://datatracker.ietf.org/meeting/111/proceedings
    （IETF 111議事録）

  - Domain Name System Operations (dnsop)
    https://datatracker.ietf.org/wg/dnsop/charter/
    （dnsop WG公式ページ）

  - DNS PRIVate Exchange (dprive)
    https://datatracker.ietf.org/wg/dprive/charter/
    （dprive WG公式ページ）

  - Adaptive DNS Discovery (add)
    https://datatracker.ietf.org/wg/add/charter/
    （add WG公式ページ）

━━━━━━━━━━━━━━━━━━━━━━━━━━━【FROM JPRS】━
■会議報告：https://jprs.jp/related-info/event/
■配信先メールアドレスなどの変更：https://jprs.jp/mail/henkou.html
■バックナンバー：https://jprs.jp/mail/backnumber/
■ご意見・ご要望：from@jprs.jp

当メールマガジンは、Windowsをお使いの方はMSゴシック、macOSをお使いの方
はOsaka等幅などの「等幅フォント」で最適にご覧いただけます。

当メールマガジンの全文または一部の文章をWebサイト、メーリングリスト、
ニュースグループ、他のメディアなどへ許可なく転載することを禁止します。
また、当メールマガジンには第三者のサイトへのリンクが含まれていますが、
リンク先のサイトの内容などについては、JPRSの責任の範囲外であることに
ご注意ください。
その他、ご利用に当たっての注意事項は読者登録規約にてご確認ください。
https://jprs.jp/mail/kiyaku.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
編集・発行：株式会社日本レジストリサービス（JPRS）
https://jprs.jp/
Copyright (C), 2021 Japan Registry Services Co., Ltd.