バックナンバー：vol.191

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2020/09/03━
                    ◆ FROM JPRS 増刊号 vol.191 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

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

2020年7月27日から31日にかけて、第108回IETF Meeting（以下、IETF 108）が、
完全オンライン会合として開催されました。IETFが完全オンライン会合で開催
されるのは前回のIETF 107に引き続き、2回目となります。

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

  ・オンライン会合の開催に関する話題
    - 開催の状況
    - 利用されたツールの状況
  ・IETF 106以降のDNS関連RFCの発行状況
    - DLVの「歴史的」ステータスへの移行（RFC 8749）
    - AppleのDNS Long-Lived Queries（LLQ）拡張（RFC 8764）
    - DNSプッシュ通知（RFC 8765）
    - マルチキャストDNSベースのサービス発見用ディスカバリープロキシー
      （RFC 8766）
    - 期限切れキャッシュデータを用いた名前解決の継続（RFC 8767）
    - ルートサーバーのローカルでの実行
  ・dnsop WGにおける話題
    - 議論された主な提案の内容と作業の進行状況
  ・dprive WGにおける話題
    - 議論された主な提案の内容と作業の進行状況
  ・add WGにおける話題
    - WGにおける議論の状況と今後の予定
  ・今後のIETF Meetingに向けた動き
    - shmoo WGの創設

          ◇                     ◇                     ◇

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

▼開催の状況

前回のIETF 107では、開催直前の2020年3月10日に完全オンライン会合への変更
が決定されました。変更に対応する準備期間が十分に確保できなかったことか
ら、WG創設に向けたBoFと創設後に初めて会合を開催するWGを優先した、規模を
縮小した形での開催となりました。

今回のIETF 108では、約2カ月前の2020年5月14日に完全オンライン会合での開
催が発表されました[*1]。完全オンライン会合を前提とした事前準備が進めら
れ、前回は会合期間中には開催されなかったdnsop、dpriveなどのDNS関連WGや
ハッカソンなども含まれた、フルアジェンダの形で開催されました[*2]。

[*1] IETF | IETF 108 Will Be an Online Meeting
     https://www.ietf.org/blog/ietf108-online/

[*2] IETF | IETF 108 Highlights
     https://www.ietf.org/blog/ietf-108-highlights/

▼利用されたツールの状況

今回の会合のため、以前からIETF会合で発表と質疑応答に使われていた
Meetecho[*3]の機能・動作環境が強化されました[*4]。これに伴い、対面の会
合では紙ベースであった会議参加記録（ブルーシート）もMeetechoによる自動
記録に変更され、匿名でのハム（Hum）[*5]も可能になりました。

[*3] RTC Experts - Meetecho
     https://www.meetecho.com/

[*4] IETF | Preparing for IETF 108 Online
     https://www.ietf.org/blog/ietf108-preparing/

[*5] IETF会合において伝統的に採用されている、参加者が意思表示の際に口を
     閉じてうなり声を出すこと。
     IETFでの合意形成とハムの概要については、RFC 7282をご参照ください。
     RFC 7282 - On Consensus and Humming in the IETF
     https://tools.ietf.org/html/rfc7282

また、完全オンライン会合への移行に伴い従来は無料であったオンライン参加
が有料化され、参加登録と結び付けられたIETF Datatracker[*6]のアカウント
によるサインインが必須とされました。

[*6] IETF Datatracker
     https://datatracker.ietf.org/

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

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

▼DLVの「歴史的」ステータスへの移行
  ・RFC 8749: Moving DNSSEC Lookaside Validation (DLV) to Historic
    Status（Standards Track、draft-ietf-dnsop-obsolete-dlv）

本RFCは、DNSSEC Lookaside Validation（DLV）の仕様を定義した2本のRFC
（RFC 4431、RFC 5074）を「歴史的（Historic）」ステータスに移行させます。

DLVは、親ゾーンがDNSSECに対応しておらずDSリソースレコード[*7]を登録でき
ない場合に、特定のサーバーにDSリソースレコードに相当するDLVリソースレコー
ドを登録し、DNSSEC対応リゾルバー側で検証するようにすることでDNSSECに対
応する手法です。

[*7] JPRS用語辞典｜DSリソースレコード（ディーエスリソースレコード）
     https://jprs.jp/glossary/index.php?ID=0213

DLVは、ルートやTLDがDNSSECに対応していない場合にDNSSECに対応する手段と
して開発されました。その後、ルートやTLDにおけるDNSSEC対応が進んだことを
受け、今回「歴史的」ステータスに移行されることとなりました。

▼AppleのDNS Long-Lived Queries（LLQ）拡張
  ・RFC 8764: Apple's DNS Long-Lived Queries Protocol
    （Informational、draft-sekar-dns-llq）

DNS Long-Lived Queries（LLQ）は、サーバー側からクライアント側にDNSデー
タの変更を知らせることができるようにするためにAppleが独自に開発した、
DNSの機能拡張です。

LLQは、IETFで標準化された「DNSプッシュ通知（RFC 8765、次で説明）」に置
き換えられました。本RFCは、LLQからDNSプッシュ通知への円滑な移行のために
文書化され、Informational（情報提供）RFCとして発行されました。

▼DNSプッシュ通知
  ・RFC 8765: DNS Push Notifications
    （Standards Track、draft-ietf-dnssd-push）

DNSにおいて、サーバー側からクライアント側にDNSデータの変更を知らせるこ
とができるようにするための、DNSの機能拡張を定義しています。DNSプッシュ
通知は、前述したLLQを置き換えるために開発されました。

本機能では、利用したいクライアント側からのリクエストをサーバー側が受け
付けた場合にのみ、クライアント側から事前に接続しておいたTCP接続を用いて
サーバーが変更を通知するという形で、プッシュ通知を実現しています。

▼マルチキャストDNSベースのサービス発見用ディスカバリープロキシー
  ・RFC 8766: Discovery Proxy for Multicast DNS-Based Service
    Discovery（Standards Track、draft-ietf-dnssd-hybrid）

ローカルネットワークでマルチキャストDNS[*8]を用いて実現されるDNSベース
のサービス発見（DNS-SD）[*9]を広域ネットワークで実現するための、マルチ
キャストDNSとDNSの間を仲介するディスカバリープロキシーの仕様を定義して
います。

[*8] RFC 6762で定義され、DNSとは別の名前空間が使われます。
     RFC 6762 - Multicast DNS
     https://tools.ietf.org/html/rfc6762

[*9] RFC 6763で定義されています。
     RFC 6763 - DNS-Based Service Discovery
     https://tools.ietf.org/html/rfc6763

▼期限切れキャッシュデータを用いた名前解決の継続
  ・RFC 8767: Serving Stale Data to Improve DNS Resiliency
    （Standards Track、draft-ietf-dnsop-serve-stale）

フルリゾルバー（キャッシュDNSサーバー）が所定の権威DNSサーバーにアクセ
スできず、期限切れのデータを更新できない場合に、期限切れとなったキャッ
シュデータを用いた名前解決を可能にし、サービスの停止を回避する方法を定
義しています。

本RFCは、DDoS攻撃や事故などで必要な権威DNSサーバーに到達できない状態が
続いた場合の、名前解決エラーの発生の回避を目的としています。

▼ルートサーバーのローカルでの実行
  ・RFC 8806: Running a Root Server Local to a Resolver
    （Informational、draft-ietf-dnsop-7706bis）

ルートサーバーへの到達時間の短縮、ルートサーバーからの応答の確保、ルー
トサーバーに対するクエリ監視の防止などを実現するため、他の利用者に影響
しない形でルートゾーンのローカルコピーを保持する方法・留意点と、主なフ
ルリゾルバー実装における設定例について記述しています。

RFC 8806は、既存のRFC 7706を置き換えます。

■dnsop WGにおける話題

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

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

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

JPRSの藤原和典が第一著者となっている、DNSにおけるIPフラグメンテーション
（断片化）を回避するための提案です。本提案はIETF 107の終了後にWGで作業
を進めることが採択され、2020年6月30日に最初のWG draftが公開されています。

今回のWGでは、藤原が現在の提案内容と旧版からの変更点について紹介しまし
た。変更点が少なかったこともありWGでの質問はなく、メーリングリストで継
続して作業を進めることとなりました。

なお、DNSからのIPフラグメンテーションの排除を主目的とした「DNS flag
day 2020」の実施が、2020年10月1日に予定されています。本提案はDNS flag
day 2020の公式サイト[*10]や関係者の資料などからも参照され、実施根拠の
一つとなっています。

[*10] 2020 | DNS flag day
      https://dnsflagday.net/2020/

▽DNSKEYリソースレコードへのDELEGATION_ONLYフラグの追加
  （draft-ietf-dnsop-delegation-only）

DNSKEYリソースレコードに、そのゾーンの内容が委任のみである旨を示す
「DELEGATION_ONLY」フラグを追加するための提案です。DNSSECに対応したリゾ
ルバーはこのフラグによってそのゾーンに設定される内容が委任情報のみであ
ることを検証でき、違反する応答をBogus（DNSSEC検証失敗）とすることができ
ます。

本提案はWGで作業を進めることが採択され、メーリングリストで継続して作業
を進めることとなりました。

▽プライミング仕様の明確化
（draft-klh-dnsop-rfc8109bis）

RFC 8109で定義される、プライミング[*11]の仕様を明確化するための提案です。

[*11] JPRS用語辞典｜プライミング（priming）
      https://jprs.jp/glossary/index.php?ID=0222

本提案では、プライミングで得られる情報の内容、応答のTCビットの取り扱い、
ICANN RSSAC[*12]の関連文書への参照、プライベートDNSに関する説明などが
追加されています。

[*12] JPRS用語辞典｜RSSAC（アールエスエスエーシーまたはアールエスサック）
      https://jprs.jp/glossary/index.php?id=0054

WGでは特に質問・コメントはなく、メーリングリストで継続して作業を進める
こととなりました。

■dprive WGにおける話題

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

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

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

▽TLS上でのゾーン転送
  （draft-ietf-dprive-xfr-over-tls）

ゾーン転送をTLSで保護することで、権威DNSサーバー間の通信におけるプライ
バシーを確保する提案です。TLSは通信相手の認証も提供するため、DNSの通信
に電子署名を付加して相手を認証する、TSIG[*13]の機能も実現できます。

[*13] RFC 2845で定義される、DNSの通信に電子署名を付加し、通信の安全性を
      高めるための仕組みです。

本提案は目的・使い方が明確であることから標準化作業が進むことが予想され、
実装も比較的容易であることからIETFハッカソンなどの場において、BIND 9や
NSDなどへの実装実験が進められています。

▽DSリソースレコードへのDNS over TLS（DoT）情報の追加
  （draft-vandijk-dprive-ds-dot-signal-and-pin）

DSリソースレコードの用途を拡張し、自分のゾーンの権威DNSサーバーがDoTに
対応していることを伝える情報を追加する提案です。

権威DNSサーバーは、DoTで使うサーバー証明書から作成したDSリソースレコー
ドを親ゾーンに登録します。フルリゾルバーは、名前解決の際にその情報を利
用し、DoTの対応状況を確認できるようにするものです。

WGでは、本提案に対し好意的な意見が出され、今後も継続して作業を進めるこ
ととなりました。

■add WGにおける話題

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

addでは、DoTやDoHのようなトランスポートの暗号化に対応したリゾルバー
（暗号化対応リゾルバー）と、従来の暗号化に対応しないリゾルバーの双方が
対象となっています。また、活動の対象を技術的な仕組みの開発に絞り込んで
おり、クライアントやサーバーのユースケース、ポリシーに関する推奨事項に
ついては、作業の対象外となっています。

▼WGにおける議論の状況と今後の予定

今回のWGでは、個別のユースケースを想定した暗号化対応リゾルバーの発見方
法・枠組みに関する提案が5本、リゾルバーからクライアントに暗号化対応リゾ
ルバーの情報を伝達するための提案が1本、暗号化対応リゾルバーを各ネットワー
クに展開する際の考慮点・必要な機能拡張に関する提案が2本発表されました。
いずれの提案も、個人提案となっています。

今回の発表では、パブリックネットワーク・エンタープライズネットワーク・
ホームネットワークなど、接続するネットワークに関する固有のユースケース
が想定されていました。しかし、WGでは個別のユースケースについては作業の
対象外となっており、提案内容に関する個別の議論は行われませんでした。

そのため、WGでは2020年9月10日と15日の2回にわたってオンラインの中間会合
を開催し、今回の提案から一つないし二つの想定するユースケースを選び、要
求条件を絞り込んだ形で議論が進められる予定となっています。

■今後のIETF Meetingに向けた動き

次回の第109回IETF Meeting（IETF 109）は2020年11月14日から20日にかけ、
タイのバンコクで開催される予定となっていました。しかし、新型コロナウイ
ルス感染症の状況から、IETF 108に引き続き、完全オンライン会合への変更が
決定されました[*14]。

[*14] IETF 109 will be an online meeting
      https://mailarchive.ietf.org/arch/msg/ietf-announce/_ob6sbhviwx13nps9kv-af_cfym/

▼shmoo WGの創設

IETFでは今回の感染拡大を受け、状況の変化に対応できるようにIETF会合を進
化させ、参加者とインターネットコミュニティによりよいサービスを提供し続
けることを目的としたshmoo WGを、2020年7月10日に創設しました[*15]。WGで
は現在、目的達成に向けた枠組み・ガイドラインの策定が進められています。

[*15] Stay Home Meet Only Online
      https://datatracker.ietf.org/doc/charter-ietf-shmoo/

          ◇                     ◇                     ◇

◎関連URI

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

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

  - 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公式ページ）

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