バックナンバー：vol.178

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2018/08/29━
                    ◆ FROM JPRS 増刊号 vol.178 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
               第102回IETF Meeting（モントリオール）報告
                ～DNS関連WG、及び周辺会合における話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2018年7月14日から20日にかけて、第102回IETF Meeting（以下、IETF 102）が
カナダのモントリオールで開催されました。

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

  ・IETF 101以降のDNS関連RFCの発行状況
    - 特殊用途ドメイン名「home.arpa.」の予約とDNSにおける動作の定義
    - JSONによるDNSメッセージの表現
  ・dnsop WGにおける話題
    - 議論された提案の内容と標準化作業の進行状況
  ・dprive WGにおける話題
    - チャーターの改定
    - 議論された提案の内容と標準化作業の進行状況
  ・driu BOFの開催
  ・IETF全般における話題
    - IETF LLCの設立
  ・ICANN DNS Symposiumにおける話題
    - BINDの開発―30年を超えるDNSとDNS標準の拡大の記録
  ・IEPG会合における話題
    - GitHubコンテンツに存在する古いルートゾーントラストアンカー
  ・次回のIETF Meetingについて

          ◇                     ◇                     ◇

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

前回のIETF 101以降に発行されたDNS関連のRFCは、以下の2本です。

▼特殊用途ドメイン名「home.arpa.」の予約とDNSにおける動作の定義

  ・RFC 8375: Special-Use Domain 'home.arpa.'
    （Standards Track、draft-ietf-homenet-dot）

    RFC 8375は、「home.arpa.」で終わるドメイン名のDNSにおける動作を定
    義し、同時に「home.arpa.」をホームネットワークのための特殊用途ドメ
    イン名として予約します。

    このRFCは、ホームネットワークの制御を定義するHNCP（RFC 7788）で
    誤って予約されてしまった「.home」を、「home.arpa.」に更新（変更）
    するものです。

▼JSONによるDNSメッセージの表現

  ・RFC 8427: Representing DNS Messages in JSON
    （Informational、draft-hoffman-dns-in-json）

    RFC 8427は、DNSメッセージをJSON（*1）で表現する方式について記述し
    ています。

    DNSメッセージをJSONで表現可能にすることで、JSONの生成や処理のため
    の既存のアプリケーションやライブラリをDNSメッセージのやりとりや処
    理に使えるようになり、開発の効率化が期待できます。

    （*1）JavaScript Object Notationの略称。
          JavaScriptのオブジェクト表記方法に由来する、言語に依存しない
          軽量なテキストベースのデータ交換フォーマット。

■dnsop WGにおける話題

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

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

▽DNS用語の明確化（draft-ietf-dnsop-terminology-bis）

本提案はDNS用語集であるRFC 7719を改訂するもので、RFC 7719に引き続き、
JPRSの藤原和典が著者の一人となっています。

本提案は、IETF 102の直前にワーキンググループラストコール（WGLC）（*2）
が実施されており、今回のWGでは作業の状況のみが報告されました。その後、
IESGに提出されています。

（*2）標準化作業において、WGチェアがWGに呼びかける最終確認。

▽QNAME minimisationのStandards Track化（draft-bortzmeyer-rfc7816bis）

QNAME minimisationはRFC 7816で定義される、プライバシー保護の観点から、
フルリゾルバー（キャッシュDNSサーバー）の名前解決アルゴリズムを変更す
るための仕組みです。本提案は、現在は実験（Experimental）仕様となってい
るQNAME minimisation を、標準化過程（Standards Track）にするためのもの
です。

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

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

QNAME minimisationは、既にいくつかのフルリゾルバーやパブリックDNSサー
ビスでサポートされ、運用されています。Knot Resolver、Unbound、パブリッ
クDNSサービスの1.1.1.1ではQNAME minimisationが標準で有効にされており、
BINDも開発版の9.13.2で、QNAME minimisationが実装されています。

これらの実装による運用の結果、RFC 7816に書かれていない問題点が確認され、
実装ごとに独自の回避策を適用していることが報告されました。本提案では、
これらのサーバーの運用から得られた知見も提案に反映する形で、Standards
Track化の作業を進めていく予定です。

▽マルチベンダー環境におけるDNSクッキーの取り扱い

RFC 7873で定義されるDNSクッキーは、HTTPで利用されているクッキーと同様
の仕組みをDNSで実現し、キャッシュポイズニング対策に利用するための仕組
みです。

HTTPのクッキーでは、クッキーを受け取ったWebブラウザーが次回以降のリク
エストの際にそれを付加し、受け取ったWebサーバーが照合することで、リク
エストを送ってきたWebブラウザーが前回と同じ相手であると判断します（*4）。

（*4）HTTPのクッキーにはこれ以外にも、さまざまな用途・機能があります。

DNSクッキーでは、問い合わせに付加するクライアントクッキーと、応答に付
加するサーバークッキーの2種類があり、問い合わせ側と応答側が相手を相互
に確認することに特徴があります。これらのうち、今回はサーバークッキーの
取り扱いに関する運用上の問題点が取り上げられました。

サーバークッキーの作成にはクライアントの情報（IPアドレス、クライアント
クッキーの内容）に加え、サーバーのみが知る秘密の情報（以下、secret）な
どが使われます。しかし、現在のDNSクッキーの仕様ではサーバークッキーを
作成する際のアルゴリズムが明確に定められておらず、権威DNSサーバーの実
装の違いにより、アルゴリズムが異なる場合があります。

このことは、IP Anycast（*5）などで複数ベンダーの権威DNSサーバーを同じ
IPアドレスで共有している際に問題となります。

（*5）IP Anycastの詳細は、JPRS用語辞典をご参照ください。
      https://jprs.jp/glossary/index.php?ID=0108

現状では、同じアルゴリズム・secretを複数の実装で共有することが難しいこ
とに加え、secretを定期的に更新する必要もあるため、権威DNSサーバーの運
用者が対応すべき項目が増えることになります。

今回のWGでは、DNSクッキーにおけるこれらの運用上の問題点が指摘・共有さ
れ、今後とるべき問題解決策として、実装を必須とするアルゴリズムやデータ
の処理方法の定義や、DNS運用者向けの運用ガイダンスの作成などが挙げられ
ました。

なお、本件については2018年6月に開催されたDNS Summer Day 2018で、JPRSの
阿波連良尚がBIND 9.9から9.11へ移行のポイントの中で、DNSクッキーの概要と
運用へのインパクトについて報告しています（*6）。

（*6）BIND 9.9から9.11へ移行のポイント（権威DNSサーバー編）
      https://dnsops.jp/event/20180627/DNSSummerDay2018_BIND9.11%E5%A4%89%E6%9B%B4%E7%82%B9auth.pdf

▽フラグメントされた応答を適切に受信できない場合の対策
  （draft-song-atr-large-resp）

フラグメントされた応答を適切に受信できない場合の対策として、通常のDNS
応答の後にATR（Additional Truncated Response）という追加の応答を送るよ
うにするための提案です。ATRには応答の切り詰めが起こったことを意味する
TCビット（*7）がセットされており、受け取り側にTCPでの再問い合わせを促
します。

（*7）TCビットの詳細は、JPRS用語辞典をご参照ください。
      https://jprs.jp/glossary/index.php?ID=0204

ATRについては、実際のネットワークでどの程度の効果が期待できるかを計測
した結果が発表されており、一定の効果があることが示されています（*8）。

（*8）評価結果については、過去のドメイン名関連会議報告をご参照ください。
      https://jprs.jp/related-info/event/2018/0420IETF.html

発表では今後の課題として、ATRを送る際の遅延時間を制御するATRタイマーと、
ATRを発動させるDNSメッセージのサイズ（ATRペイロードサイズ）をどの値に
設定すべきかが示されました。そこでは、

  ・ATRタイマーの値は、Lルートサーバーや.com/.netの権威DNSサーバーのよ
    うにIP Anycastで世界中にサーバーが分散配置されている場合、50ms未満
    に設定するのがよいと考えられる

  ・ATRペイロードサイズの値は、IPv4ではイーサネットのMTU（Maximum
    Transmission Unit）を考慮した1472に、IPv6では最小MTUの1280から、
    IPv6ヘッダー（40バイト）とUDPヘッダー（8バイト）を除いた、1232にす
    るのがよいと考えられる

という提案がなされています。

会場からは、ATRは賢いアイデアであると評価する声があった一方、そのアイ
デアは好まないという意見や、遅延と再送を実装するためにはサーバー側にス
テートを持たなければならないため、実装が面倒になるのではないかといった
意見も出ていました。

■dprive WGにおける話題

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

▼チャーターの改定

2018年5月25日付で、dprive WGのチャーターが改定されました。今回の改定で、
これまで取り扱ってきたスタブリゾルバーとフルリゾルバーの間の通信に加え、
フルリゾルバーと権威DNSサーバーの間の機密性の提供も、WGの活動項目に追
加されました。

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

▽DNSプライバシーに関するサービス運用者の推奨事項
  （draft-dickinson-bcp-op）

本提案は、DNSプライバシーサービスの運用ポリシーとセキュリティ上の考慮
事項について考察・まとめたもので、サービスの運用者に以下の三つの項目を
提供することを目指しています。

  ・DNS over TLS/DTLSの運用の指針
  ・DNSプライバシーサービスの運用者における、データの取り扱いの概要
  ・DNSSECのDPS（*9）に相当する「DNSプライバシーポリシーと運用ステート
    メント（DNS Privacy Policy and Practice Statements：DPPPS）」を作
    成するための枠組み

（*9）DPS（DNSSEC Practice Statement）は、管理対象ドメイン名における
      DNSSECサービスの安全性や運用のポリシー、考え方、手順などについて
      網羅的にまとめた文書で、そのドメイン名のDNSSEC運用者が必要に応じ
      て作成・公開します。

今回のWGでは、RIPE NCCのBCOPタスクフォース（*10）をはじめとする、さま
ざまな関係者からのフィードバックを提案に反映したことが発表されました。
具体的には、アクセス元のIPアドレスの匿名化、RFC 6973に書かれている通信
プロトコルのプライバシーに関する考慮事項、RFC 7626に書かれているDNSの
プライバシーに関する考慮事項が、推奨項目として追加されています。

（*10）2013年10月にRIPE NCCに組織された、インターネットの運用上の慣行
       を文書化するためのタスクフォースです。
       Best Current Operational Practices Task Force (Proposed Charter)
       https://www.ripe.net/participate/ripe/tf/bcop

会場からはプライバシーのあり方に関する意見が多く寄せられ、WGチェアが本
提案をWG Draftとして採択することを検討する旨（Call for Adoption by WG
Issued）を宣言しました。その後、2018年8月8日にWG Draft（draft-ietf-
dprive-bcp-op-00）が発行されています。

■driu BOFの開催

現在のDHCP（*11）ではDNS関連の情報として、フルリゾルバーのIPアドレス・
ドメイン名と、クライアントのホスト名がクライアントに提供されます。

（*11）Dynamic Host Configuration Protocolの略称。
       ネットワークに接続されたホストに、TCP/IPの通信に必要な設定情報
       を提供するためのプロトコルです。

以前は、フルリゾルバーへのアクセス方法はTCP/UDPのポート53番のみであっ
たため、アクセスのための情報としてIPアドレスが提供されれば十分でした。
しかし、DNS over TLSやDNS over HTTPSといったプロトコルの登場により、ア
クセス方法が多様化してきました。

今回、こうしたフルリゾルバーへのアクセス方法や利用方法をクライアントに
伝える方法を考える際に考慮すべき課題を議論・検討する場として、driu
（DNS Resolver Identification and Use）BOFが開催されました。

通常、IETFのBOFは将来のWG化を目指して開催されます。しかし、今回のBOFは
現時点では将来のWG化を目的とせず、現状の確認、問題点の洗い出し、アイデ
アの提案と議論を目的として開催されました。

今回のBOFでは必要な項目として、主に以下の内容が取り上げられました。

  ・フルリゾルバーへのアクセス方法に関する設定項目
  ・DNS over TLSでのアクセスに必要な設定項目
  ・DNS over TLSにおけるIPアドレスの認証方法
  ・フルリゾルバーの挙動や機能の伝達方法

■IETF全般における話題

▼IETF LLCの設立

IETF自身の管理運営やISOCとの関係の維持は、2005年に設立されたIASA（IETF
Administrative Support Activity）が担っています。そして、IASAの活動は
投票で選ばれたメンバーで構成されるIAOC（IETF Adnimistrative Oversight
Committee）が指揮・監督しています（*12）。この体制は、2003年から2005年
にかけて進められた、IETFの構造改革によって構築されました。

（*12）IASAとIETFの運営構造については、過去のドメイン名関連会議報告をご
       参照ください。
       https://jprs.jp/related-info/event/2004/1201ietf.html

体制の発足から13年が経過し、IETFのよりよい管理運営を模索する中で、IETF
とISOCの責任範囲の明確化、ISOC、IETF、IAOCの役割と立場の明確化、活動を
進めるための資金や人的資源の確保、活動の透明性の確保などの問題点が指摘
されました。そして、これらの問題点を解決するため、現在の体制を刷新する
「IASA 2.0」が提案・議論されました。

その結果、IETFの管理運営と資金調達業務を担当するIETF LLCを創設し、IAOC
を廃止した上で、その役割をIETF LLCに組織されるLLC Boardに移管すること
が、IETFチェアから発表されました。

IETF LLCは、2018年8月末を目処に設立される予定となっています。

■ICANN DNS Symposiumにおける話題

IETF本会議前日の7月13日に、ICANN DNS Symposiumが開催されました。ICANN
DNS SymposiumはICANNが年に1回開催しているイベントで、今回が2回目の開催
となります。

今回のICANN DNS Symposiumでは、DNSを発明したPaul Mockapetris氏が基調講
演を担当し、DNSに関するさまざまな話題が取り上げられました。今回はセッ
ション中から「The development of BIND, tracking the growth of the DNS
and DNS standards over 30 years（参考訳：BINDの開発―30年を超えるDNSと
DNS標準の拡大の記録）」の内容を紹介します。

▼BINDの開発―30年を超えるDNSとDNS標準の拡大の記録

発表は、ISCのPresidentであるJeff Osborn氏が担当しました。

最初に、2000年10月にBIND 9がリリースされるまでの歴史が紹介され、続いて、
DNSSECやIPv6をはじめとするDNSに対する要求の変化に対応するため、BIND 9
のコードサイズが肥大化していった状況が紹介されました。

BIND 9はRFCのリファレンス実装となっており、IETFで標準化された機能は、
基本的にすべて実装されます。そのため、IETFの標準化活動の進捗と共にコー
ドサイズが肥大化し、内部構造が複雑になっていきました。そして、そうした
コードサイズの肥大化と内部構造の複雑化が、新たな脆弱性の発生につながっ
ていったことが紹介されました。

そして、こうした状況を打破するためにコードのリファクタリングを進めてい
るが、新しいRFCがリリースされることで実装とテストが必要になり、複雑さ
が増す、という状況が現在も続いていることが紹介されました（*13）。

（*13）本件については、IETF 101報告の「RFC 8324の公開を受けての議論」
       をご参照ください。
       第101回IETF Meeting（ロンドン）報告
       https://jprs.jp/related-info/event/2018/0420IETF.html

最後に、BIND 9の長い歴史を象徴する形で、開発を当初から担当しているISC
のMark Andrews氏の風貌の変化が紹介されました。

本発表資料は、ICANNのWebサイトで公開されています（関連URIを参照）。

■IEPG会合における話題

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

▼GitHubコンテンツに存在する古いルートゾーントラストアンカー

ICANNのRoy Arends氏とPaul Hoffman氏が、GitHub（*14）に存在する古いルー
トゾーントラストアンカーの状況と、それがルートゾーンKSKロールオーバー
に与える影響について調査した結果を発表しました。

（*14）ソフトウェア開発のプラットフォームとして広く使われているサービ
       スで、さまざまなオープンソースソフトウェアのソースコードをホス
       ティングしています。

調査の結果、それらのほとんどがUnbound、dnsmasq（*15）、Chromium（*16）
などの古いソースに由来するもので、実際のDNSSEC検証には使われておらず、
2018年10月に予定されているルートゾーンKSKロールオーバーには影響しない
と考えられる旨が報告されました。

（*15）DNSのフォワーダー、DHCPサーバー、TFTPサーバーの機能を持つオープ
       ンソースソフトウェアです。

（*16）オープンソースのWebブラウザー開発プロジェクトです。
       ChromiumはGoogle Chromeのベースにもなっています。

■次回のIETF Meetingについて

次回の第103回IETF Meeting（IETF 103）は2018年11月3日から9日にかけ、タ
イのバンコクで開催されます。

          ◇                     ◇                     ◇

◎関連URI

  - 102 Meeting Index
    https://www.ietf.org/meeting/102/
    （IETF 102公式ページ）

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

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

  - DNS Resolver Identification and Use (driu)
    https://datatracker.ietf.org/group/driu/about/
    （driu BOF公式ページ）

  - IETF Administrative Support Activity 2 (iasa2)
    https://datatracker.ietf.org/wg/iasa2/about/
    （iasa2 WG公式ページ）

  - ICANN DNS Symposium | July 2018 - ICANN
    https://www.icann.org/ids
    （ICANN DNS Symposium 2018公式ページ）

  - The development of BIND, tracking the growth of the DNS and DNS
    standards over 30 years
    https://www.icann.org/en/system/files/files/presentation-development-bind-tracking-growth-dns-13jul18-en.pdf
    （ICANN DNS Symposium 2018でのJeff Osborn氏の発表資料）

  - IEPG Meeting - July 2018
    https://iepg.org/2018-07-15-ietf102/
    （2018年7月15日のIEPG Meeting公式ページ）

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