バックナンバー：vol.187

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2019/12/25━
                    ◆ FROM JPRS 増刊号 vol.187 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                第106回IETF Meeting（シンガポール）報告
                ～DNS関連WG、及び周辺会合における話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2019年11月16日から22日にかけて、第106回IETF Meeting（以下、IETF 106）
がシンガポールで開催されました。

今回のFROM JPRSでは、IETF 106とその周辺で開催された会合の中から、FROM 
JPRS編集局が注目した以下の話題をお伝えします。

  ・IETF 105以降のDNS関連RFCの発行状況
    - DNSパケットキャプチャーのためのフォーマットの定義
    - CAAリソースレコードにおける、アカウントURIと自動証明書管理環境
      （ACME）における検証方法の指定
    - CAAリソースレコードの仕様改訂
  ・dnsop WGにおける話題
    - 議論された提案の内容と標準化作業の進行状況
  ・dprive WGにおける話題
    - 議論された提案の内容と標準化作業の進行状況
  ・Application Behavior Considering DNS（abcd）BoFの状況
  ・IEPG会合における話題
    - TLDの権威DNSサーバーにおけるDNSSEC検証エラーの検出
  ・次回のIETF Meetingについて

          ◇                     ◇                     ◇

■IETF 105以降のDNS関連RFCの発行状況

前回のIETF 105以降に発行された、DNS関連のRFCの内容は以下の通りです。

▼DNSパケットキャプチャーのためのフォーマットの定義

  ・RFC 8618: Compacted-DNS (C-DNS): A Format for DNS Packet Capture
    （Standards Track、draft-ietf-dnsop-dns-capture-format）

    RFC 8618は、DNSメッセージを収集する際に利用可能なデータ表現形式を
    定義します。

    DNSトラフィックの監視や分析、サイバー攻撃の検出などを目的としたパ
    ケットキャプチャーをする場合、収集した大量のDNSメッセージを効率よ
    く保存・交換できる形式があると便利です。

    本RFCは保存に必要な容量を削減し、かつ、データの交換が可能なデータ
    表現形式としてCBOR[*1]を用いた「Compacted-DNS（C-DNS）」を定義し、
    アプリケーションの開発を支援することを目的としています。

[*1] CBOR:Concise Binary Object Representation
     https://tools.ietf.org/html/rfc7049

▼CAAリソースレコードにおける、アカウントURIと自動証明書管理環境（ACME）
  における検証方法の指定

  ・RFC 8657: Certification Authority Authorization (CAA) Record
    Extensions for Account URI and Automatic Certificate Management
    Environment (ACME) Method Binding（Standards Track、
    draft-ietf-acme-caa）

    CAAリソースレコード[*2]のissue/issuewildプロパティでは、ドメイン名
    の管理者が証明書の発行を許可する認証局（CA）を、パラメーターとして
    指定します。

[*2] CAAリソースレコードの概要については、JPRS用語辞典をご参照ください。
     JPRS用語辞典｜CAAリソースレコード（シーエーエーリソースレコード）
     https://jprs.jp/glossary/index.php?ID=0218

    RFC 8657は、それに加え、証明書を発行するためのURIを指定する
    「accounturi」と、ACME[*3]において利用可能な検証方法を指定する
    「validationmethods」の二つを指定可能にします。

[*3] 「Automatic Certificate Management Environment（自動証明書管理環
     境）」を意味しており、証明書の管理を自動化するためのプロトコルです。
     証明書の検証・発行・失効などの一連のプロセスを自動化し、運用の負担
     を軽減することを目的としています。

    以下に、accounturiとvalidationmethodsの使用例を示します（いずれも
    RFC 8657 Appendix A. Examplesから引用）。

    example.com. IN CAA 0 issue "example.net; \
      accounturi=https://example.net/account/1234"
    example.com. IN CAA 0 issue "example.net; \
      accounturi=https://example.net/account/2345"

    example.com. IN CAA 0 issue "example.net; validationmethods=dns-01"
    example.com. IN CAA 0 issue "example.net; validationmethods=xyz-01"

▼CAAリソースレコードの仕様改訂

  ・RFC 8659: DNS Certification Authority Authorization (CAA) Resource
    Record（Standards Track、draft-ietf-lamps-rfc6844bis）

    RFC 8659は、CAAリソースレコードの基本仕様を定義します。
    RFC 8659は、従来のRFC 6844を置き換えます。

    RFC 8659はRFC 6844から、以下の点が変更されています。

    ・認証局がCAAリソースレコードを検索するアルゴリズムを、途中で見つかっ
      たCNAME/DNAMEで指定される階層構造は対象としないように簡略化
    ・issue/issuewildタグの文法を明確化
    ・issue/issuewildタグを含まないCAAリソースレコードの処理を明確化
    ・用語の定義を明確にするための構成変更

■dnsop WGにおける話題

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

▼議論された提案の内容と標準化作業の進行状況

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

JPRSの藤原和典が提案している、DNSにおけるIPフラグメンテーション（断片化）
を回避する提案です[*4]。-00版から-01版への更新にあたり、Farsightの
Paul Vixie氏が共著者に加わっています。

[*4] 提案された背景とその目的の詳細については、過去のドメイン名関連会議
     報告をご参照ください。
     https://jprs.jp/related-info/event/2019/0829IETF.html

今回、IETF 105以降の作業で、以下の項目を追記したことが発表されました。

  ・RFC 8085（UDPの使用ガイドライン）への参照
  ・DNSにおけるデフォルトのUDPペイロードサイズに関する考察
  ・ゾーン管理者に対する要請事項
  ・path MTUの値を得る方法

WGでは、intarea WGがIPフラグメンテーションの脆弱さ（fragility）とその代
替案を開発者とネットワークオペレーターに提案している、
draft-ietf-intarea-frag-fragileがRFC発行の直前（RFC Ed Queue）であり発
行を待つことと、発行後にその内容を踏まえた内容調整が必要であるとのコメ
ントがありました。今後、コメントを受けたアップデート作業を継続していく
予定です。

▽プライベートな名前空間のためのTLD（draft-arends-private-use-tld）

プライベートな名前空間のためのTLDとして、ISOがユーザー割り当て用コード
（user-assigned codes）として予約している文字列を使える、ということを
示した提案です。

これまで、通常のインターネット以外で利用するための特殊用途ドメイン名
（Special-Use Domain Names）[*5]として、.testや.localなどのTLDが提案・
予約されてきました。しかし、現時点ではプライベートIPアドレスに相当する、
プライベートな名前空間のためのTLDは設定・予約されていません。

[*5] これまでの特殊用途ドメイン名の取り扱いについての概要は、過去のドメ
     イン名関連会議報告をご参照ください。
     https://jprs.jp/related-info/event/2017/1213IETF.html

この提案ではプライベートな名前空間のためのTLDとして、ISO 3166 alpha-2
[*6]のユーザー割り当て用コードとされている文字列のうち、.ZZを利用するこ
とを推奨しています。

[*6] ISO 3166-1のalpha-2は、国や地域に割り当てられるccTLDで採用されてい
     ます。詳細は、JPRS用語辞典をご参照ください。
     https://jprs.jp/glossary/index.php?ID=0144

その理由として、それらの文字列は予約されているため、将来いずれかの国や
地域に割り当てられてしまうリスクがないことを挙げています。

WGでは、これまでのTLD予約文字列とそのRFCに関する状況が確認されました。
会場からは、ccTLDの国・地域コードを定めるのはISOの仕事であってIETFの仕
事ではなく、dnsop WGとして特定のコードに関する特別な使用法を推奨するこ
とはできないのではないか、という意見が寄せられました。

▽相互運用可能なサーバークッキー（draft-ietf-dnsop-server-cookies）

IP Anycastを用いた複数台／複数種類のサーバーを運用する際にも相互運用可
能な、DNSクッキー[*7]の作成方法を定義するための提案です。

[*7] DNSクッキーの取り扱いに関する運用上の問題点についての詳細は、過去
     のドメイン名関連会議報告をご参照ください。
     https://jprs.jp/related-info/event/2019/0829IETF.html

前回のIETF 105では、使用されるアルゴリズムがSipHash-2.4の1種類のみとさ
れ、クッキー中のSub-Fieldの利用方法が明確化されました。

今回のIETF 106ではdnsop WGに先だって開催されたIETFハッカソンの結果を踏
まえた提案が行われました。提案では、従来からのサーバークッキーの相互運
用性に加え、クライアントクッキーが少なくとも64ビットのエントロピーを持
つようにという推奨事項が加えられるなど、DNSクッキーに関するセキュリティ
とプライバシーに関する考慮事項が追加されています。

今後、これまでに議論・実験された仕様をもとに、標準化作業と実装が進めら
れていく予定です。

▽DNSエラーコードの拡張（draft-ietf-dnsop-extended-error）

本提案では、EDNS0を用いてエラーコードを拡張するための「Extended
DNSError (EDE)」オプションと、情報を返すための「Extended DNS Error
Code」を定義することで、エラーの原因に関する追加情報を問い合わせ元に返
せるようにします。

現在のDNSSECでは検証においてエラーが発生した場合、従来のDNSにおける名前
解決エラーの場合と同様、SERVFAIL応答を返します。しかし、SERVFAIL応答は
サーバー側で名前解決エラーが発生したことのみを示しており、その原因が何
なのかを示す追加情報は含まれません。この提案は、この問題を解決し、
DNSSEC検証エラーの原因を問い合わせ（スタブリゾルバー）側で把握できるよ
うにするものです。

本提案は、2017年2月に初版（draft-wkumari-dnsop-extended-error-00）が公
開された後、多くの議論と改訂を経た後、現在ワーキンググループラストコー
ル（WGLC）が実施されています。

■dprive WGにおける話題

dpriveはDNS PRIVate Exchangeに由来しており、DNSトランザクションにおけ
る機密性（confidentiality）の提供を目的としています。

▼議論された提案の内容と標準化作業の進行状況

▽Oblivious DoHによるプライバシーの向上
  （draft-pauly-dprive-oblivious-doh）

DNSクライアントとフルリゾルバー（キャッシュDNSサーバー）の通信にプロキ
シを介在させることで、DNSクライアントのIPアドレスと問い合わせ内容の双方
を同時に把握されないようにする、DNS over HTTPS（DoH）の拡張機能の提案で
す。

本提案では、Oblivious DoH（ODoH） Proxyと呼ばれるプロキシをDNSクライア
ントとフルリゾルバーの間に配置したうえで、クライアントとフルリゾルバー
の間の通信を暗号化する方式を提唱しています。

しかし、この方式はODoH Proxyの追加に加え、DNSクライアントとフルリゾルバー
における暗号化と復号も必要になるため、プロトコルが複雑化するというデメ
リットがあります。

▽権威DNSサーバーとフルリゾルバーの間の通信の暗号化に関する議論
  （draft-lmo-dprive-phase2-requirements）

dprive WGのPhase 2[*8]として、権威DNSサーバーとフルリゾルバーの間の通信
の暗号化が検討されています。

[*8] これまでの議論の詳細は、過去のドメイン名関連会議報告をご参照くださ
     い。
     https://jprs.jp/related-info/event/2019/0829IETF.html

今回は前回のIETF 105に引き続き、標準化作業を進めるための要求条件と実装
案についての議論が行われました。

会場では、通信の暗号化ではなくQNAME minimisation[*9]で十分ではないか、
サーバーの証明書として何を使うべきか、といった既存の問題点が確認され、
今回のIETFハッカソンでUnboundに権威DNSサーバーとフルリゾルバーの間の
DNS over TLSを試験実装したことが紹介されました。

[*9] QNAME minimisation詳細は、過去のドメイン名関連会議報告をご参照くだ
     さい。
     https://jprs.jp/related-info/event/2015/0421IETF.html

■Application Behavior Considering DNS（abcd）BoFの状況

DoHはプロトコルの仕様がRFC 8484として標準化されましたが、その運用・利用
についての規定はなく、さまざまな懸念が指摘されています。今回のIETF 106
では、DoHの運用に必要な技術的規定を作成するWGの設立を目的としたabcd
BoFが開催されました。

BoFでは、DoHとDoT（DNS over TLS）のクライアント・サーバー実装状況の紹介
と、DoHの考慮事項やクライアント設定方法の各種提案[*10]について振り返ら
れた後、WGの作業対象を決めるチャーターについて議論されました。

[*10] これまでのDoHについての議論は、過去のドメイン名関連会議報告をご参
      照ください。
      https://jprs.jp/related-info/event/2019/0829IETF.html

BoFチェアから示されたチャーター案に対して、会場からは、dnsopではなく独
立したWGとする理由を明確にすべき、作業項目をもっと絞り込み解決可能な技
術的議論に集中すべき、BCPは技術的課題が解決してからリチャーターして取り
込めばよい、などの意見が寄せられました。WG設立に反対する意見は特にあり
ませんでしたが、チャーターのコンセンサスは得られず、AD及びIETFチェアか
ら、WG設立を前提にadd MLで議論を継続することとまとめられました。

■IEPG会合における話題

IEPG（Internet Engineering and Planning Group）は、IETF会合に先立って
日曜日午前に開催される会合で、インターネットの運用に関連するさまざまな
テーマを取り扱っています。

▼TLDの権威DNSサーバーにおけるDNSSEC検証エラーの検出

国立情報学研究所（NII）とJPRSが共同で進めている、JP DNSサーバーへの問い
合わせ状況を計測することでDNSSEC検証失敗の検知を試みる研究について、
JPRSの米谷嘉朗が発表しました。

フルリゾルバー（バリデーター）でDNSSEC検証の失敗が発生すると、名前解決
を繰り返すため、当該ドメイン名の権威DNSサーバーやTLDを含む親ゾーンの権
威DNSサーバーへのDNSSEC関連クエリが増加します。DNSSEC検証失敗によるクエ
リ増加の特徴を捉えることができれば、DNSSECの誤設定を早期に検知できるよ
うになるのではないかという仮説のもと、研究を進めています。

今回の発表では、現在までの知見として、DNSKEYのクエリ増加がその特徴を示
す可能性があることを紹介しています。

■次回のIETF Meetingについて

次回の第107回IETF Meeting（IETF 107）は2020年3月21日から27日にかけ、
カナダのバンクーバーで開催されます。

          ◇                     ◇                     ◇

◎関連URI

  - 106 Meeting Index
    https://www.ietf.org/how/meetings/106/
    （IETF 106公式ページ）

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

  - 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/
    （dnsop WG公式ページ）

  - Application Behavior Considering DNS (abcd)
    https://datatracker.ietf.org/wg/abcd/charter/
    （Application Behavior Considering DNS BoF公式ページ）

  - IEPG Meeting - November 2019
    https://iepg.org/2019-11-17-ietf106/
    （IEPG Meeting - November 2019 @ IETF 106公式ページ）

━━━━━━━━━━━━━━━━━━━━━━━━━━━【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), 2019 Japan Registry Services Co., Ltd.