バックナンバー：vol.175

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2018/04/20━
                    ◆ FROM JPRS 増刊号 vol.175 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                  第101回IETF Meeting（ロンドン）報告
                ～DNS関連WG、及び周辺会合における話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2018年3月17日から23日にかけて、第101回IETF Meeting（以下、IETF 101）が
英国のロンドンで開催されました。

今回のFROM JPRSでは、IETF 101における議論から、FROM JPRS編集局が注目し
た以下の話題をお伝えします。

  ・IETF 100以降のDNS関連RFCの発行状況
    - DNS over TLS/DTLSにおけるプロファイルと認証方式
    - DNSの再設計と置き換え、機能に関する明確な線引きの呼びかけ
  ・dnsop WGにおける話題
    - チェアの追加募集
    - 議論された提案の内容と標準化作業の進行状況
    - RFC 8324の公開を受けての議論
  ・dprive WGにおける話題
    - 議論された提案の内容と標準化作業の進行状況
  ・doh WGにおける話題
    - 議論された提案の内容と標準化作業の進行状況
  ・IEPG会合における話題
    - Additional Truncated Response（ATR）に関する計測結果
    - EDNS0に関する一時的な回避策（ワークアラウンド）の削除
  ・次回のIETF Meetingについて

          ◇                     ◇                     ◇

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

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

▼DNS over TLS/DTLSにおけるプロファイルと認証方式

  ・RFC 8310：DNS over TLS/DTLSにおけるプロファイルと認証方式
    （Standards Track、draft-ietf-dprive-dtls-and-tls-profiles）

    RFC 8310は、DNS over TLS/DTLS（*1）による通信のために必要なプロ
    ファイル（*2）の内容と、DNS over TLS/DTLSにおけるDNSサーバーの認証
    方式を定義します。

（*1）DNS over TLSはHTTPSで用いられているTLSをDNSに適用する技術で、TCP
      での通信が前提となります。一方、DNS over DTLSはTLSをUDPに対応さ
      せたDTLSをDNSに適用する技術で、UDPでの通信が前提となります。

（*2）プロファイルについての概要は、過去のドメイン名関連会議報告をご参
      照ください。
      https://jprs.jp/related-info/event/2016/0510IETF.html

▼DNSの再設計と置き換え、機能に関する明確な線引きの呼びかけ

  ・RFC 8324：DNSプライバシー、認可、特殊用途、エンコーディング、文字、
    マッチング、そしてルート構造：見直しの時なのか？
    （Informational、draft-klensin-dns-function-considerations）

    DNSの基本部分は30年以上前に設計されました。そして、その後のイン
    ターネットの状況の変化やDNSに対する要求事項の変化に対応するため、
    これまでにさまざまな改良や機能追加が図られてきました。

    RFC 8324は、DNSにおいてこれまでに欠点が指摘されたり、議論の対象と
    なったりした項目の概要とその論点をまとめた上で、それらを踏まえた
    DNSの再設計と置き換え、機能に関する明確な線引きの必要性について、
    広く問いかけたものです。

    なお、このRFCはIETFのワーキンググループで議論されたものではなく、
    長年にわたってIETFで活動し、多数のRFCを執筆したJohn Klensin氏の執
    筆によるものです。今回、IESG（*3）の承認を経た上で、Informational
    （情報提供）RFCとして発行されました。

（*3）Internet Engineering Steering Groupの略称。
      IETFのWGが所属する各エリアのエリアディレクターにより構成され、
      IETFの活動と標準化プロセスの技術管理を担当します。

■dnsop WGにおける話題

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

▼チェアの追加募集

最近のdnsop WGでは活発な標準化活動が進められており、第99回IETF Meeting
以降、多数の提案を扱うために2枠分の時間を使い議論される状況が続いてい
ます。

そのため、担当エリアディレクターのWarren Kumari氏から、dnsop WGの運営
を担当する現在の2人のチェアに加え、3人目のチェアの追加募集が呼び掛けら
れました。

その結果、IETF 101終了後の2018年4月11日にNLnet LabsのBenno Overeinder
氏が、3人目のチェアに任命されました。

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

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

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

会合に先立って更新された提案では、「Lame delegation」や「Public suffix」
といった用語の追加や、細部の修正などが行われています。

今回のWGでは前回に引き続き、著者の一人であるICANNのPaul Hoffman氏から、
WGの参加者に更新内容のレビューが依頼されました。今後、2018年4月中に
ワーキンググループラストコール（WGLC）が実施される予定です。

▽クエリタイプANYのレスポンスサイズの小型化
  （draft-ietf-dnsop-refuse-any）

DNSリフレクター攻撃の効果を低減するため、クエリタイプANYに対する応答の
仕様を変更して応答サイズを小さくする、プロトコル変更の提案です。

提案では応答サイズを減らすため、サーバーが知っているすべてのリソースレ
コードセット（以下、RRset）を返すという従来の動作に加え、

  1. 一部のRRsetのみを返す
  2. 動的に生成されたHINFO（ホストの情報）リソースレコード（以下、RR）
     を返す

という動作を選択可能にしています。

今回のWGでは、WGLC後に出されたすべてのコメントを提案に反映したこと、近
日中にIESGに送付予定であることが報告されました。

▽トラストアンカーの状況をクライアント側から調べる方法
  （draft-ietf-dnsop-kskroll-sentinel）

DNSクエリによって、DNSSECバリデーターのトラストアンカーの状況をクライ
アント側から調べるための仕組みを定義する、プロトコル拡張の提案です。本
提案は、ルートゾーンKSKロールオーバーの進行状況の調査に用いることを想
定しています。

今回のWGでは、前回のIETF 100からの変更点が共有・議論され、継続して作業
を進めることとなりました。主な変更点は、以下の通りです。

  ・トラストアンカーの状況を調べる特殊ラベルの仕様変更
    * 従来：_is-ta-<key-tag>と_not-ta-<key-tag>
    * 変更：root-key-sentinel-is-ta-<key-tag>と
            root-key-sentinel-not-ta-<key-tag>

  ・<key-tag>に指定する鍵タグの仕様変更
    * 従来：16進数で指定
    * 変更：10進数で指定、5桁にパディング（例えば42の場合、00042）

▽ANAMEリソースレコードの定義（draft-ietf-dnsop-aname）

CDN（Content Delivery Network）での利用を想定し、ANAME
（Address-specific DNS Name Redirection）というCNAME RRと同様の機能を
提供する、他のRRと共に指定可能な新しいRRを定義するための提案です（*4）。

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

今回のWGでは、前回までの議論を踏まえ、

  ・ANAMEの機能を、権威DNSサーバーとフルリゾルバー（キャッシュDNSサー
    バー）の双方の仕様変更で実現する予定であること
  ・それぞれの仕様を記述するため、現在の提案を二つに分割しようと考えて
    いること

が発表されました。

本件はDNSプロトコルに大きな変更を加えるものであるため、活発な議論が交
わされましたが結論には至らず、継続して作業を進めることとなりました。

▼RFC 8324の公開を受けての議論

今回のWGでは、DNSの再設計と置き換え、機能に関する明確な線引きについて
問いかけたRFC 8324の発行を受け、PowerDNSの開発者のBert Hubert氏が「The
DNS Camel, Or How many features can we add to this protocol before it
breaks?」と題した発表を行いました。

発表では、

  ・DNSに長年にわたり多数の機能が追加され、仕様が複雑化している
  ・それにより、以下の状況が引き起こされている
    * 機能間の衝突
    * すべての仕様や機能を理解できる人の減少
    * コードの複雑化
    * 実装の品質とセキュリティレベルの低下
  ・その原因として、DNSの実装開発者・フルリゾルバーの運用者・TLDやルー
    トの権威DNSサーバーの運用者・標準化活動の推進者といった、主なDNS関
    係者の思惑と要求が、互いに反映されていないことが挙げられる
  ・結果、機能の過剰（glut）が、DNS全体の停滞（statis）を引き起こす

という問題が提起され、この状況を打破するための方策として、

  ・標準化の際に誰がその機能を欲するか、誰が便利になるのかを考えること
  ・そのコストを誰がどう負担するのかも考えること
  ・DNSの実装開発者やサーバー運用者のコミュニティが、より包括的にIETF
    の活動に関われるようにすること

が呼び掛けられました。

会場からは大きな反響があり、肯定的な内容を中心に活発な意見交換が行われ
ました。また、RFC 8324の発行を受けた具体的な動きの例として、以下が紹介
されました。

  ・EDNS0に準拠しない応答を受け取った際の例外処理の廃止（*5）
    （draft-spacek-edns-camel-diet）
  ・使われておらず、かつ廃止されていないRRの廃止
    （draft-sury-deprecate-obsolete-resource-records）

（*5）今回のIEPG会合で、複数のオープンソースDNSサーバーの実装における
      対応スケジュールが発表されました。詳細は本報告の「IEPG会合におけ
      る話題」をご参照ください。

■dprive WGにおける話題

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

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

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

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

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

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

今回のWGでは、本提案は初版であり、まだ多くの作業項目があることが報告さ
れ、DNSプライバシーの運用には技術だけではなくポリシーも含まれるが、今
後もIETFで議論を続けるべきかどうかが話し合われました。

会場からは、運用ポリシーの議論についてはIETFでも進めるのがよいというコ
メントがあり、また、提案の内容についてもサポートする意見が多く、今後も
継続して作業を進めることになりました。

▽フルリゾルバーと権威DNSサーバー間におけるプライバシーの確保
  （draft-bortzmeyer-dprive-resolver-to-auth）

dprive WGではこれまで、スタブリゾルバーとフルリゾルバー間の通信におけ
るプライバシーの確保に関する標準化作業を進めてきました。

今回の提案は次の段階として、フルリゾルバーと権威DNSサーバー間の通信に
おけるプライバシーの確保を目標としています。そして、そのために必要な暗
号化と認証の仕組みの標準化において考慮すべき点についてまとめています。

▽リチャーターに関する議論

dprive WGの当初の目標であった、スタブリゾルバーとフルリゾルバー間の通
信のプライバシー確保に関する標準化作業は、ほぼ完了しています。それを受
け、今後WGのチャーターを改定（リチャーター）して、次のステップであるフ
ルリゾルバーと権威DNSサーバーの通信のプライバシー確保をどう進めていく
かについての検討が進められました。

今回のWGでは、今後の作業に関するさまざまな論点や作業を進めるにあたって
の懸念点について活発な議論が行われましたが結論には至らず、継続して議論
を進めることとなりました。

■doh WGにおける話題

dohはDNS over HTTPSに由来し、DNSの通信をHTTPSの通信路で実現するため、
DNSクエリとレスポンスのエンコードを標準化することを目的としています。

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

▽DNS over HTTPS（draft-ietf-doh-dns-over-https）

HTTPS通信のメッセージの本体に、DNSのワイヤーフォーマット（ビット列形式
のバイナリフォーマット）をそのまま用いる提案です（*7）。

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

現在の提案ではHTTP/2の利用が必須となり、GETメソッドではBase64エンコー
ド、POSTメソッドではバイナリフォーマットのままで取り扱う形になっていま
す。

WGでは、今回のIETFハッカソンで作成された五つの実装で相互接続を行った経
験が紹介され、その結果を提案に反映し、継続して作業を進めることとなりま
した。

■IEPG会合における話題

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

▼Additional Truncated Response（ATR）に関する計測結果

APNICのGeoff Huston氏から、IPフラグメンテーションを適切に受信できない
場合の対策として提案されているATR（*8）について、実際のネットワークで
どの程度の効果が期待できるかを計測した結果が発表されました。

（*8）フラグメントされた応答を受け取れない場合にTCPでの再問い合わせを
      促すため、通常の応答の10ms後に、切り詰めが起こったことを意味する
      TCビットがセットされた短い応答を追加で返すようにする提案です
      （draft-song-atr-large-resp）。

計測の結果、DNS応答処理の失敗率がIPv4では12.5%から4.0%に、IPv6では
20.8%から8.4%に減少したことが発表され、ATRの導入が一定の効果を発揮する
可能性があることが示されました。

▼EDNS0に関する一時的な回避策（ワークアラウンド）の削除

ISCのOndrej Sury氏から、EDNS0対応したDNSクエリに対して不適切な応答を返
すDNSサーバーに対応するためのワークアラウンドの処理を、複数のオープン
ソースDNSサーバーの実装から削除する計画が発表されました。

今回の計画は同氏が所属するISCに加え、CZ.NIC、NLnet Labs、PowerDNS.COM
BVの連名で発表されており、それぞれが開発しているリゾルバーの実装である
BIND、Knot Resolver、Unbound、PowerDNS Recursorで、同時に実施される予
定です。

今回の計画では、2019年2月1日にワークアラウンドの処理の削除を実施すると
しており、DNSサーバーの実装者に向け、EDNS0に関する適切な応答の仕方は以
下のいずれかであり、そのように実装すべきであることを呼び掛けています。

  ・EDNS0を正しく実装し、適切に処理する
  ・DNSの応答コード（RCODE）として、フォーマットエラーを意味する
    FORMERRを応答する

この計画は、前述したRFC 8324の公開とその後の議論を受けたものの一つであ
り、サーバー実装をシンプルにすることで開発コストを軽減するための動きの
一環です。

■次回のIETF Meetingについて

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

          ◇                     ◇                     ◇

◎関連URI

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

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

  - Domain Name System Operations (dnsop)
    https://datatracker.ietf.org/wg/dnsop/charter/
    （dnsop WG公式ページ）

  - The DNS Camel, Or How many features can we add to this protocol
    before it breaks?
    https://datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-01
    （dnsop WGのBert Hubert氏の講演資料）

  - DNS PRIVate Exchange (dprive)
    https://datatracker.ietf.org/wg/dprive/charter/
    （dprive WG公式ページ）

  - DNS Over HTTPS (doh)
    https://datatracker.ietf.org/wg/doh/charter/
    （doh WG公式ページ）

  - IEPG Meeting - March 2018
    https://iepg.org/2018-03-18-ietf101/
    （2018年3月18日の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.