バックナンバー：vol.194

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2021/04/13━
                    ◆ FROM JPRS 増刊号 vol.194 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

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

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

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

  ・オンライン会合の開催に関する話題
    - 開催の状況
  ・IETF 110までに発行されたDNS関連のRFC
    - DNSゾーンのメッセージダイジェスト（RFC 8976）
  ・dnsop WGにおける話題
    - 議論された主な提案の内容と作業の進行状況
  ・dprive WGにおける話題
    - 議論された主な提案の内容と作業の進行状況
  ・add WGにおける話題
    - 議論された主な提案の内容と作業の進行状況
  ・次回のIETF Meetingについて

          ◇                     ◇                     ◇

■オンライン会合の開催に関する話題

▼開催の状況

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

■IETF 110までに発行されたDNS関連のRFC

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

▼DNSゾーンのメッセージダイジェスト（ZONEMD）
  ・RFC 8976: Message Digest for DNS Zones
    （Standards Track、draft-ietf-dnsop-dns-zone-digest）

RFC 8976は、DNSゾーンデータ全体のメッセージダイジェスト（ハッシュ値
[*1]）を生成し、ZONEMDリソースレコード（以下、RR）としてゾーンファイル
に保持するプロトコル拡張の仕様を定義します。

[*1] JPRS用語辞典｜ハッシュ値（ダイジェスト値）
     https://jprs.jp/glossary/index.php?ID=0230

ZONEMDをDNSSECと組み合わせて使うことで、ゾーンデータの受信者は受信した
ゾーンデータ全体の完全性と作成元の正当性を確認でき、ゾーン転送やその他
の手段で受信したゾーンデータがオリジナルから変更されていないことを検証
できます。DNSSECなしで使った場合、ZONEMDはチェックサムとしてのみ機能し、
送信エラーや切り捨てなどの偶発的な破損からゾーンデータを保護します。

ZONEMD RRのフォーマットを以下に示します。スキームは現時点で1のSimpleの
みが、ハッシュアルゴリズムは1のSHA-384と、2のSHA-512が定義されています。

  ＜フォーマット＞
  ドメイン名 TTL IN ZONEMD シリアル スキーム ハッシュアルゴリズム (
      ダイジェスト )

  ＜使用例（RFC 8976から引用）＞
  example.com. 86400 IN ZONEMD 2018031500 1 1 (
      FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE
      7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE )

■dnsop WGにおける話題

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

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

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

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

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

会合では発表者の藤原が、IPv4とIPv6におけるDNS/UDPの最大ペイロードサイ
ズとしてどの値を採用するかを決めるため、いくつかの候補を示した上で参加
者に問い掛けました。藤原が示した候補は、以下の通りです。

  ・DNSSECでサポートしなければならないと定められている最小値である1220
  ・DNS flag day 2020で推奨されている1232
  ・PPPoEやIPv4 over IPv6など、アクセス回線の状況を考慮した1400
  ・Geoff Huston氏の文書[*3]に記載されている1472（IPv4）及び1452（IPv6）
  ・他に良い値があれば、その値と理由

[*3] Measuring the impact of DNS Flag Day 2020 | APNIC Blog
     https://blog.apnic.net/2020/12/14/measuring-the-impact-of-dns-flag-day-2020/

議長からは、どうすれば値を決められるか意見が欲しい旨の参加者への呼び掛
けと「実装者からのフィードバックを得て欲しい」という発表者へのコメント
がありました。会合にはGoogle Public DNSの担当者も参加しており「特定の
値を選ぶのは難しい」というコメントがありました。

また、「IPv4とIPv6で同じ値を選ぶ必要はなく、問題を起こさないと認識され
ている最大値をそれぞれ選ぶのがよい」「一つの値を理由と共に示し、変更を
許容するのはどうか」などのコメントもあり、どの値を採用するかについては
メーリングリストで継続して作業を進めることとなりました。

▽DNSを介したサービスバインディングとパラメーターの指定
  （draft-ietf-dnsop-svcb-https）

そのドメイン名で提供されるサービスへのアクセスに必要な情報を設定する
SVCB RRとHTTPS RRの仕様を定義する、プロトコル拡張の提案です。

SVCBは、"Service Binding"に由来しています。SVCB RRはHTTPS以外のサービ
スにも適用可能な形で定義され、HTTPS RRはSVCBのバリエーションとして、
HTTPS及びHTTPスキームに特化した形で定義されています。

SVCB RRと同様の機能を持つものに、RFC 2782で定義されるSRV RRがあります。
SVCB RRにはSRV RRにはなかった、クライアントにプロトコルの変更やアップ
グレードを通知する機能や、新しいパラメーターで自身を拡張する機能が含ま
れています。

本稿では、一部のベンダーが先行導入を進めている、HTTPS RRについて説明し
ます。HTTPS RRのフォーマットと使用例を以下に示します。

  ＜フォーマット＞
  ドメイン名 TTL IN HTTPS 優先度 ターゲット名 [ サービスパラメーター ]

  ＜使用例（draft-ietf-dnsop-svcb-httpsから引用）＞
  （CDNサービス利用者のゾーン）
  $ORIGIN aliased.example.
  @     7200 IN HTTPS 0 pool.svc.example.

  （CDNサービスプロバイダーのゾーン）
  $ORIGIN svc.example.
  pool  7200 IN HTTPS 1 h3pool alpn=h2,h3 echconfig="123..."
                HTTPS 2 .      alpn=h2 echconfig="abc..."
  pool   300 IN A        192.0.2.2
                AAAA     2001:db8::2
  h3pool 300 IN A        192.0.2.3
                AAAA     2001:db8::3

CDNサービス利用者のaliased.exampleゾーンで用いられるエイリアスモード
（優先度に0を設定）は、CDNサービスを利用する際に、ゾーン頂点（zone
apex）に別名を書けるようにするためのものです。この例では、CDNサービス
利用者のaliased.exampleゾーン頂点のドメイン名（aliased.example）に、別
名（pool.svc.example）を指定しています。

CDNサービスプロバイダーのsvc.exampleゾーンでは、WebブラウザーがHTTP/2
やHTTP/3の接続に必要な、各種パラメーターと優先度を指定しています。この
例では、WebブラウザーがHTTPS RRをサポートしている場合、そのCDNサービス
プロバイダーへの接続はHTTPSにアップグレードされ、利用可能な場合、
HTTP/3接続を使うようになります。

このように、CDNサービスプロバイダーが接続に必要なパラメーターをHTTPS
RRで設定し、Webブラウザーが接続時にHTTPS RRを検索するようにすることで、
HTTPS接続に必要な情報を、DNS検索で取り扱えるようになります。

本提案はWGでの議論を経て、現在ワーキンググループラストコール（WGLC）が
実施されています。作業の進捗状況を受け、SVCB RRとHTTPS RRはIANAによる
RRタイプの割り当てが完了しており[*4]、一部のWebブラウザーやCDNサービス
事業者などで使われ始めています[*5]。

[*4] SVCB RRには64が、HTTPS RRには65が割り当てられています。
     Domain Name System (DNS) Parameters
     https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

[*5] New SVCB & HTTPS Resource Records in the wild
     https://community.akamai.com/customers/s/article/networkoperatorcommunitynewsvcbhttpsresourcerecordsinthewild20201128135350

▽NSEC3パラメーター設定のガイダンス
  （draft-hardaker-dnsop-nsec3-guidance）

DNSSECのNSEC3による不在証明について、現在の運用状況を基にパラメーター
設定のガイダンスを提供する運用方式の提案です。

NSEC3では外部からのゾーン列挙[*6]をしにくくするため、ソルト[*7]付きの
ハッシュ計算を繰り返し実施します。NSEC3の仕様を定義するRFC 5155では繰
り返し回数の最大値を、鍵長が1024ビットの場合150回、2048ビットの場合500
回、4096ビットの場合2500回と定めています。

[*6] DNSSEC 関連情報 ～よくある質問～ / JPRS
     https://jprs.jp/dnssec/faq.html#q16

[*7] 元データを推測しにくくするため、ハッシュ値を計算する際に入力に付
     加するランダムなデータ。

本提案では、不特定多数のクライアントのリクエストを処理することで計算リ
ソースが制約されがちなパブリックDNSサービスにおいて、DNSSEC検証サポー
トが大幅に進んでいることを勘案し、リゾルバー側のDNSSEC検証におけるハッ
シュ計算の繰り返し回数を鍵長によらず最大100回に制限した上で、制限を超
えた場合SERVFAILエラーにすることを推奨しています。

また、権威DNSサーバー側ではソルトの値を0にした上で繰り返し回数を0回に
し、大規模なTLDのような非常に大きく、かつ署名されていない数多くの委任
情報を持つゾーン以外では、Opt-Outフラグを設定しないことを推奨していま
す。

会合では「SERVFAILエラーではなく、知らない署名アルゴリズムと同じように
安全ではない（Insecure）と扱うのが良いのでは」「TLDによってはゾーン内
容を開示しないように、ソルトを設定した上でDNSSECを運用しているため、運
用に悪影響を及ぼす可能性がある」などのコメントがあり、それらを検討する
ために継続して作業を進めることになりました。

■dprive WGにおける話題

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

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

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

▽フルリゾルバーと権威DNSサーバー間の通信の暗号化
  （draft-ietf-dprive-opportunistic-adotq）

フルリゾルバーと権威DNSサーバーの間の通信の暗号化に関する提案の内容が、
前回のIETF 109で提案されたものから大きく変更されました。

最初のバージョン（-00）では、認証方式にはopportunistic（日和見）[*8]を、
暗号化にはDoTまたはDNS over QUIC（DoQ）を使い、暗号化の有無は権威DNS
サーバーのDoTのポート（853/TCP）でのサービス提供の有無で検出する方式が
採用されていました。

[*8] 暗号化を試みるが、相手の正当性を検証しない方式。

会合直前の2021年2月22日に公開された次のバージョン（-01）では、認証方式
として日和見に加え、設定されているTLSA RR[*9]でサーバー証明書を検証し、
通信相手の正当性を認証する方式が追加され、TLSA RRが存在しない、あるい
は検証に失敗した場合、名前解決エラーにする厳密なモードも定義されました。

[*9] 証明書の検証に利用する証明書そのものや、検証用の公開鍵を格納する
     ためのRR。

同時に、暗号化の有無を検出する方式も、TLSA RRの存在をチェックする方法
に変更されました。内容が大幅に変更されたことを受け、本提案は標準化過程
（Standards Track）RFCを目指すものから、実験的（Experimental）RFCを目
指すものに変更されました。

会合終了後の2021年3月22日、本提案の第一著者であるPeter van Dijk氏がWG
のメーリングリストに、本件に関する今後の進め方の案を投稿しました[*10]。
投稿では、本提案と別に公開された提案（draft-rescorla-dprive-adox-
latest）の内容を取り込み、認証方式としてTLSAに代えてSVCB RR[*11]を採用
することでプロトコルの柔軟性を高め、DoTとDoQ以外の暗号化の方式も使える
ようにする形で作業を進めたい旨が提案されています。

[*10] [dns-privacy] next steps for draft-opportunistic-adotq
      https://mailarchive.ietf.org/arch/msg/dns-privacy/bb-usm6vhv9o4mo732hdnahz6tu/

[*11] 本稿の「DNSを介したサービスバインディングとパラメーターの指定」
      を参照。

メーリングリストでは現在も本件に関するさまざまな意見が投稿されており、
作業全体の方向性がまとまり、RFCが発行されるまでには、まだかなりの作業
を要すると予想されます。

■add WGにおける話題

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

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

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

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

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

本提案は、非暗号化リゾルバーのIPアドレスのみを知っているクライアントが、
リゾルバーを非暗号化リゾルバーから暗号化リゾルバーに移行するために使う
ことを想定しています。具体的には、特殊用途ドメイン名として
「resolver.arpa」を予約し、「_dns.resolver.arpa」に暗号化リゾルバーの
サービスを検出するためのSVCB RRを設定する方法が提案されています。

また、本提案は、暗号化リゾルバーのホスト名を知っているクライアントが、
そのリゾルバーがどのような暗号化プロトコルをサポートしているかを検出す
るために使うことも想定しています。具体的には、暗号化リゾルバーのホスト
名が「resolver.example.com」であった場合、「_dns.resolver.example.com」
に暗号化プロトコルを検出するためのSVCB RRを設定する方法が提案されてい
ます。

会合では、「接続先の確認の際、サーバー証明書にIPアドレスの記載がないと
信用できないのではないか」「特殊用途ドメイン名はDNSSECに対応できないた
め、実際のドメイン名を使う方法にすべき」「ホスト名がCNAMEで提供された
場合の対応はどうするのか」といったコメントがあり、それらを検討するため
に継続して作業を進めることになりました。

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

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

会合では、最初に問い合わせ先の情報をクライアントに応答する際、どのよう
なフォーマットでデータを渡すべきかについて議論されました。「DDRと同じ
情報が必要なのであれば、同じ仕組みを適用してSVCB RRで渡せばよく、別の
仕組みを作る必要はないのではないか」というコメントがあり、それらを検討
するために継続して作業を進めることになりました。

■次回のIETF Meetingについて

次回の第111回IETF Meeting（IETF 111）は2021年7月24日から30日にかけ、米
国のサンフランシスコで開催される予定となっています。開催形式が変更され
る場合、IETFから別途アナウンスされる予定です。

          ◇                     ◇                     ◇

◎関連URI

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

  - IETF 110 preliminary & interim materials
    https://datatracker.ietf.org/meeting/110/materials.html
    （IETF 110発表資料一覧）

  - 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.