バックナンバー：vol.200

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2021/12/16━
                    ◆ FROM JPRS 増刊号 vol.200 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

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

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

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

  ・オンライン会合の開催に関する話題
    - 開催の状況
    - 全体会議の日程移動
  ・IETF 111以降に発行されたDNS関連のRFC
    - TLSのDNSSECチェーン拡張（RFC 9102）
    - DNSのクラスとリソースレコードタイプのためのYANGタイプ（RFC 9108）
    - arpaトップレベルドメインのルートからの分離（RFC 9120）
    - QNAME minimisationの仕様の更新（RFC 9156）
    - DNSSECにおけるIANAに関する考慮点の改訂（RFC 9157）
  ・dnsop WGにおける話題
    - 議論された主な提案の内容と作業の進行状況
  ・dprive WGにおける話題
    - 議論された主な提案の内容と作業の進行状況
  ・add WGにおける話題
    - 議論された主な提案の内容と作業の進行状況
  ・次回のIETF Meetingについて

          ◇                     ◇                     ◇

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

▼開催の状況

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

▼全体会議の日程移動

今回のIETF 112では会議に先立ち、全体会議（Plenary）の日程を本会議の前
の2021年11月3日に移動する旨が発表されました[*1]。

その理由として、オンライン開催では1日のミーティング時間が短く、スケ
ジュールが競合しやすくなるため、時間の長い全体会議を本会議と別日程とす
ることで、スケジュールを確保しやすくするためである旨が示されています。

[*1] Proposed Experiment for IETF 112: Moving the Plenary
     https://mailarchive.ietf.org/arch/msg/ietf-announce/z3fznhmcuxdevc4bkmoy8i89ypk/

■IETF 111以降に発行されたDNS関連のRFC

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

▼TLSのDNSSECチェーン拡張
  ・RFC 9102: TLS DNSSEC Chain Extension
    （Experimental: draft-dukhovni-tls-dnssec-chain）

RFC 9102は、TLSAレコード[*2]のDNSSEC検証に必要な情報を、TLS[*3]のオプ
ションとして提供するためのプロトコル拡張です。なお、本RFCはIETFのWGで
標準化されたものではなく、実験（Experimental）仕様となっています。

本RFCでは、DS・DNSKEY・RRSIGなど、DNSSEC検証に必要なリソースレコード
（以下、RR）の情報をWebサーバーからクライアントにまとめて送付すること
で、DNS問い合わせをすることなく、TLSAレコードのDNSSEC検証を実現するた
めの仕様を定義しています。

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

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

▼DNSのクラスとリソースレコードタイプのためのYANGタイプ
  ・RFC 9108: YANG Types for DNS Classes and Resource Record Types
    （Standards Track、draft-ietf-dnsop-iana-class-type-yang）

RFC 9108は、DNSのRRをデータモデリング言語YANG（ヤン）で取り扱うための
モジュール「iana-dns-class-rr-type」を導入します。

YANGは構成と状態データをモデル化し、機器の操作や非同期通知の形式を指定
可能にすることで管理を支援するための言語で、RFC 7950で定義されています。
当該モジュールを導入することでDNSのRRをYANGで取り扱うことが可能になり、
権威DNSサーバー、リゾルバー、ゾーンデータの設定・管理に、YANGを活用で
きるようになります。

▼arpaトップレベルドメインのルートからの分離
  ・RFC 9120: Nameservers for the Address and Routing Parameter Area
    ("arpa") Domain
    （Informational、draft-iab-arpa-authoritative-servers）

RFC 9120は、ルートサーバーで管理されているarpaゾーンをルートサーバーか
ら分離することについて定めています。本RFCはarpaゾーンを管理するIAB[*4]
が、今後の方針として公開したものです。

arpaはARPANET[*5]からの移行用のTLDとして、1985年に創設されました。その
後、2001年に発行されたRFC 3172で、通信プロトコルの内部で使われるインフ
ラストラクチャドメインとして再定義されました。

本RFCではarpaゾーンを管理する権威DNSサーバーをns.arpaゾーン内に
a.ns.arpa、b.ns.arpa...という形で準備し、arpaゾーンの管理をルートサー
バーから分離することで、ルートサーバーの管理ポリシーに影響されない形で
arpaゾーンを管理可能にする旨の方針を定めています。

本RFCはarpaゾーンの管理ガイドラインを定めた、RFC 3172を更新します。

[*4] JPRS用語辞典｜IAB（アイエービー）
     https://jprs.jp/glossary/index.php?id=0025

[*5] JPRS用語辞典｜ARPANET（アーパネット）
     https://jprs.jp/glossary/index.php?id=0010

▼QNAME minimisationの仕様の更新
  ・RFC 9156: DNS Query Name Minimisation to Improve Privacy
    （Standards Track、draft-ietf-dnsop-rfc7816bis）

RFC 9156は、QNAME minimisationの仕様を定義します。QNAME minimisationは
プライバシー保護の観点から、フルリゾルバー（キャッシュDNSサーバー）の
名前解決アルゴリズムを変更するための仕組みです[*6]。

QNAME minimisationの最初のバージョンは、2016年にRFC 7816として公開され
ました。本RFCは実験（Experimental）仕様となっていたRFC 7816を置き換え、
標準化過程（Standards Track）として再定義します。

QNAME minimisationは、既に主要なフルリゾルバーやパブリックDNSサービス
でサポートされ、標準で有効にされています。本RFCではこれまでの運用から
得られた知見を反映する形で、DNS問い合わせにおける推奨事項が一部変更さ
れています。

[*6] 従来の名前解決アルゴリズムでは、フルリゾルバーは利用者が問い合わ
     せたドメイン名・タイプを、ルートサーバーやTLDの権威DNSサーバーに
     そのまま問い合わせます。これに対し、QNAME minimisationでは名前解
     決に必要な最低限の情報である子のNSレコードを問い合わせるように、
     アルゴリズムを変更します。

▼DNSSECにおけるIANAに関する考慮点の改訂
  ・RFC 9157: Revised IANA Considerations for DNSSEC
    （Standards Track、draft-ietf-dnsop-dnssec-iana-cons）

RFC 9157は、DNSSECにおけるIANAに関する考慮点（IANA Considerations）の
内容を改訂し、これまでStandards Track（標準化過程）RFCの発行が必要で
あったDSレコードとNSEC3[*7]で使われるハッシュアルゴリズムの割り当てを、
それ以外のRFCの発行においても可能とします。これにより、これらの割り当
て要件と、他のDNSSECアルゴリズムの割り当て要件の間の差異を解消します。

RFC 9157はNSEC3不在証明を定義したRFC 5155、DNSSECの暗号アルゴリズムの
割り当てを定めたRFC 6014、及びDNSSECの暗号アルゴリズムの実装要件と使用
ガイドラインを定めたRFC 8624を更新します。

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

■dnsop WGにおける話題

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

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

▽DNSを使った検証方式の調査
  （draft-sahib-domain-verification-techniques）

DNSを使った管理権限の検証方式に関する調査結果と、利用時の推奨事項をま
とめた提案です。

DNSを使った検証方式は、独自ドメイン名を用いたサーバー証明書の発行やホ
スティングサービスの設定など、サービス提供者が利用者のドメイン名に関連
付けるサービスを提供する際、利用者がそのドメイン名の管理権限を有してい
るかの確認に使われます。

具体的には、利用者が自分のドメイン名の権威DNSサーバーにサービス提供者
が指定した検証用RR（TXT・CNAME）を追加・編集し、サービス提供者がそれを
確認することで、ドメイン名の管理権限を検証します。本提案の推奨事項とし
て、複数の検証用RRがゾーン頂点に設定されることでDNS応答が大きくなるの
を避けるため、サービスごとに特定のprefixed names[*8]を使うことと、信頼
性向上のためDNSSECを適用すべきである旨を挙げ、今後、検証用のRRの公開期
間に関する検討を進める予定である旨が発表されました。

WGでは「本提案は重要なので進めるべき」という意見や「提案がターゲットと
する層を明確にするのがよい」というコメント、「協力者として一緒に作業を
進めたい」という申し出などがあり、継続して作業を進めることとなりました。

[*8] 「_acme-challenge.example.jp」のように、アンダースコアで始まるラ
     ベルを付加したドメイン名です。サービスごとのprefixed namesは、
     IANAが管理しています。
     Underscored and Globally Scoped DNS Node Names
     https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

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

DNSSECのNSEC3による不在証明について、現在の運用状況に基づくNSEC3パラ
メーターの設定に関するガイダンスを提供する運用方式の提案です。本提案は
過去のdnsop WGでも議論されています[*9]。

NSEC3では外部からゾーン列挙[*10]をしにくくするため、ハッシュ計算を繰り
返し実行します。提案では、繰り返し回数が多い場合にフルリゾルバーのパ
フォーマンスが低下し、名前解決に影響を及ぼす可能性があることを懸念し、
権威DNSサーバーとフルリゾルバーの設定・動作について、以下を推奨する旨
が発表されました。

  ・権威DNSサーバーで設定する繰り返し回数の推奨値を0（繰り返さない）と
    し、ソルト[*11]は値を毎回変更する場合にのみ設定する

  ・フルリゾルバーでDNSSEC検証を実施する繰り返しの最大数を100とし、100
    を超える場合はDNSSEC検証を実施せず、101から500までは安全ではない
    （Insecure）と扱い、501以上は攻撃とみなしSERVFAILとして扱う

WGでは「信頼の連鎖が構築されているのにInsecureやSERVFAILとして扱うのは、
かえって安全性を損なうのではないか」というコメントがあり、継続して作業
を進めることになりました。

[*9] 第110回IETF Meeting報告
     https://jprs.jp/related-info/event/2021/0413ietf.html

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

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

▽DNSフィルタリングされた理由を利用者に伝える仕組み
  （draft-wing-dnsop-structured-dns-error-page）

管理者のポリシーによってDNSフィルタリングされた理由を、利用者に伝える
仕組みを定義するための提案です。

DNSフィルタリングは、セキュリティ上の理由やペアレンタルコントール、法
執行機関からの要請など、さまざまな理由で実施されることがあります。本提
案ではEDNS0[*12]を使い、フィルタリングされた理由と詳細情報を取得するた
めのURIを、利用者に伝える仕組みを提供します。

WGでは「エラー情報の提供方法としてWebアクセスが前提となっているが、ア
プリケーションはWebに限らないのではないか」というコメントや「フィルタ
リングを支援する仕様を標準化することは、検閲に協力することになるのでは
ないか」という懸念のコメント、それに対し「何をなぜフィルタリングしたか
を利用者に開示する『よい検閲』を支援するため、この仕組みが必要なのでは
ないか」などのコメントがあり、継続して作業を進めることとなりました。

[*12] JPRS用語辞典｜EDNS0（イーディエヌエスゼロ）
      https://jprs.jp/glossary/index.php?ID=0147

▽DNSカタログゾーン（draft-ietf-dnsop-dns-catalog-zones）

権威DNSサーバーに設定するゾーンの設定情報をゾーンファイルの形で配布で
きる「カタログゾーン」の仕様を定義する、機能拡張の提案です。

カタログゾーンとして設定情報を管理・配布することで、複数の権威DNSサー
バーへのゾーンの追加・削除やゾーン情報の変更を、DNSソフトウェアの実装
によらない形で管理できます。カタログゾーンは当初BINDに実装され、現在で
は複数のDNSソフトウェアでサポートされています[*13]。

WGでは、カタログゾーンを設定するドメイン名について「arpa配下に作成する
のがよいのではないか」というコメントや、それに対し「専用のTLDがよい」
「自身のドメイン名のサブドメインとするのがよい」などのコメントがありま
した。

カタログゾーンには既に複数の実装と運用実績があり、大まかな仕様も固まっ
ているため、細部が合意された時点で、ワーキンググループラストコール
（WGLC）が実施される見込みです。

[*13] DNS Catalog Zones - Implementations & Interoperability
      https://zones.cat/implementations.html

■dprive WGにおける話題

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

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

最近のdprive WGではフルリゾルバーと権威DNSサーバー間の通信の暗号化につ
いて、継続的な議論が進められてきました。現在、WGでは暗号化に用いるサー
バー証明書の検証方法、フルリゾルバー側での暗号化の有無の検出方法、権威
DNSサーバー側でのサーバー証明書の情報の設定方法など、本件に関するさま
ざまな課題の検討が進められています。

▽暗号通信が可能かをフルリゾルバー側から検出・記憶する仕組み
  （draft-dkgjsal-dprive-unilateral-probing）

権威DNSサーバーとの通信時に暗号通信が可能かをフルリゾルバー側から検出・
記憶することで、暗号化による名前解決の遅延や悪影響を最小限に留めること
を目的とした提案です。

提案では、名前解決の際に通信先の権威DNSサーバーが暗号通信に対応してい
るかをフルリゾルバー側から検出し、暗号通信ができた場合はその方式、でき
なかった場合はその事実を権威DNSサーバーのIPアドレス単位で記憶すること
で、opportunistic（日和見）[*14]方式を用いた、より簡便な暗号化方式への
対応を図っています。

WGでは、フルリゾルバー側の記憶はIPアドレス単位ですることになっているが、
サーバー証明書の検証は本来ネームサーバーホスト名単位であるため、整合性
がとれないのではないかというコメントがあり、継続して作業を進めることに
なりました。

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

▽DSレコードによるグルーの提供
  （draft-schwartz-ds-glue、draft-dickson-dnsop-ds-hack）

DNSSECの信頼の連鎖の構築・検証に用いるDSレコードを拡張し、フルリゾル
バーと権威DNSサーバーの間の通信の暗号化に必要な情報を、親ゾーンに登録・
設定可能にするための提案です。本提案は、既存のDNSやドメイン名登録シス
テムへの影響を最小限に留めながら、フルリゾルバーと権威DNSサーバーの間
の通信の暗号化を実現することを目的としています。

親ゾーンに登録・設定される委任情報（NSレコード・グルーレコード）は権威
を持たない情報であり、DNSSECでは保護されません。そのため、本提案では権
威を持つ情報として親ゾーンに登録されるDSレコードにこれらの情報をエン
コードして格納できるようにし、DNSSECで保護されるようにします。

現在、WGでは本件に関する複数の方式が提案・比較検討されている段階であり、
合意形成には至っておらず、標準化には今後かなりの期間を要することが予想
されます。

■add WGにおける話題

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

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

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

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

WGでは前回からの変更点として、構成の検出に使用するSVCBレコードの内容・
参照を最新の提案に合わせて更新したこと、クライアントがDDR以外の方法で
暗号化リゾルバーを検出可能である旨の記述を追加したこと、使用する用語を
一部変更したことなどが発表され、現時点における残課題の内容が共有・議論
されました。

本提案は残課題の解決後にWGLCが実施され、IESGに送付される見込みとなって
います。

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

▽DNSフォワーダー経由でのDDR（draft-schwartz-add-ddr-forwarders）

DDRによる暗号化リゾルバーの検出について、クライアントとフルリゾルバー
の間にDNSフォワーダーが存在する場合の問題点の指摘と、問題解決のために
取りうる緩和策に関する情報をまとめた提案です。

一般的なホームルーターにはDNSフォワーダーの機能が実装されており、広く
普及しています。これらのDDRを認識して実装されていないレガシーDNSフォ
ワーダーは、DNS問い合わせ・応答を転送する際、送信元のIPアドレスを自ら
のものに付け替えます。

一方、DDRによる暗号化リゾルバーの検出ではその暗号化リゾルバーのサー
バー証明書の検証が必要であり、レガシーDNSフォワーダーによってIPアドレ
スが書き換えられた場合、サーバー証明書の検証に失敗します。そのため、レ
ガシーDNSフォワーダー経由で動作するクライアントは、DDRによる暗号化リゾ
ルバーの検出を利用できないことになります。

WGでは、数多くの利用者がレガシーDNSフォワーダー経由でインターネットを
利用しており、現在のDDRではそれらの利用者をカバーできないことが懸念さ
れること、コンシューマー向けのホームルーターは長期間にわたって使われる
場合が多く、状況の改善には長い時間を要することが問題点として指摘され、
継続して議論を進めることとなりました。

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

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

今回のWGでは、IETF 110・111[*16]までに仕様に関する議論がほぼ終了し、関
連文書であるDDRも残課題の解決後にWGLCが実施される見込みとなったことか
ら、WGLCが実施される予定である旨が発表されました。

[*16] 第110回IETF Meeting報告
      https://jprs.jp/related-info/event/2021/0413ietf.html
      第111回IETF Meeting報告
      https://jprs.jp/related-info/event/2021/0831ietf.html

■次回のIETF Meetingについて

次回の第113回IETF Meeting（IETF 113）は、2022年3月19日から25日にかけて
開催される予定です。

IETF 113は新型コロナウイルス感染症の状況から、当初予定のタイのバンコク
では開催できず、オンサイトの参加者比率を50%と想定した別の開催地を検討
中であり、今年中に決定予定である旨が発表されています[*17]。

[*17] IETF 113 (March 2022) venue update
      https://mailarchive.ietf.org/arch/msg/ietf-announce/jcvd9xgdaj8fhx5u1fjnghdn1mq/

          ◇                     ◇                     ◇

◎関連URI

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

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

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