第98回IETF Meeting（シカゴ）報告

2017年3月26日から31日にかけて、第98回IETF Meeting（以下、IETF 98）が米国のシカゴで開催されました。

今回のFROM JPRSでは、IETF 98の模様を以下の項目に沿ってお伝えします。

• dnsop WGにおける話題
  - IETF 97以降のRFC発行状況
  - 議論された提案の内容と標準化作業の進行状況
  
• homenet WGにおける話題
  - 議論された提案の内容と標準化作業の進行状況
  
• regext WGにおける話題
  - データエスクローの標準化
  - WGチャーターの改訂に向けた動き
  
• IETF全般における話題
  - IETFチェアの交代
  
• IEPG会合における話題
  - DNS Violations Project
  
• 次回のIETF Meetingについて
  

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

IETF 97以降のRFC発行状況

前回のIETF 97以降に発行されたRFCは、以下の3本です。

• ネットワークインフラにおけるDNSSEC非準拠の検知法と影響の緩和策
  （draft-ietf-dnsop-dnssec-roadblock-avoidance、RFC 8027：Best Current Practice）
  EDNS0（*1）を制限するミドルボックス（*2）や、UDPフラグメントを正しく取り扱えない機器が用いられているネットワークにおいて、原因の検知と、影響軽減のための手法を記述したものです。
  
  本RFCの発行により、これまでの運用でオペレーターが培ったDNSSECに対応ネットワークインフラを効率的に検知するための手法が、現状できないにおける最良の慣行（Best Current Practice: BCP）としてまとめられました。
  

（*1）

EDNSは、RFC 6891で定義されるDNSの拡張方式で、バージョン番号を示すためにEDNS0またはEDNS(0)と呼ばれます。詳細は、以下の解説をご参照ください。
https://jprs.jp/glossary/index.php?ID=0147

（*2）

RFC 3234で定義される、通信路の間（middle）に存在する、ルーティング以外の動作をする装置（box）の総称。ミドルボックスの例として、ファイアウォールやネットワークアドレス変換（NAT）装置、侵入検知システム（IDS）などが挙げられます。




• CDS/CDNSKEYによる親のDSレコードの管理
  （draft-ietf-dnsop-maintain-ds、RFC 8078：Standards Track）
  
  DNSSECにおいて親ゾーンに設定されるDSレコードを、子ゾーンで設定するCDS/CDNSKEYレコード経由で自動更新するための手法は、RFC 7344として定義されています。
  
  その中で、親ゾーンの管理者がDNS問い合わせで子ゾーンのCDS/CDNSKEYの存在をチェックし、設定されていた場合に対応する自分のレコードを自動更新するという運用形態が想定されています。
  
  しかし、RFC 7344ではDSレコードを最初に設定する場合と削除する場合の手法が提供されていませんでした。本RFCではこれらの手法を提供します。また、CDS/CDNSKEYレコードは、RFC 7344ではInformationalでしたが、本RFCによりStandards Trackとなりました。
  
  本RFCではユースケースの一つとして、DNSオペレーターの変更において移転元と移転先が非協力的（non-cooperative）であった場合に、移転に先立って子の側から親ゾーンのDSレコードを自動的に削除し、DNSSEC検証失敗を回避することが想定されています。
  
  
• プライミングクエリによるDNSリゾルバーの初期化
  （draft-ietf-dnsop-resolver-priming、RFC 8109：Best Current Practice）
  
  フルリゾルバー（キャッシュDNSサーバー）がキャッシュを初期化するために送信する、プライミングクエリ（priming query）について記述したものです。フルリゾルバーはプライミングクエリにより、ルートゾーンの現在のNS RRSetと、ルートサーバーへのアクセスに必要なIPアドレスの一覧を取得します。
  
  BINDやUnboundなど、現在普及しているフルリゾルバーは最初の名前解決に先立ち、プライミングクエリを実行するように実装されています。
  
  本RFCは、既存のフルリゾルバーに実装されているプライミングクエリの方式を現状における最良の慣行（BCP）として文書化したものです。EDNS0を使用すべきである、DNSSEC OK（DO）ビットを設定してもよいなど、これまで明確にされていなかった項目についても記述されています。
  
  

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

FROM JPRS編集局が注目した提案の内容と、標準化作業の進行状況について紹介します。

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

今回のWGでは若干の用語の追加と、ドメイン名（domain name）の項目の記述を変更したことが報告され、内容のレビューが依頼されました。

RFC 7719ではドメイン名の項目に、ラベルの長さがゼロから63オクテット（*3）であること、ラベルの長さの合計が255オクテットに制限されることが記述されていました。提案では、これらの制限は新設された「Global DNS」の項目に移され、ドメイン名は「ゼロ個以上のラベルの順序付きリスト（An ordered list of zero or more labels）」という、DNS以外のシステムも含む、より一般的な定義に変更されています。

この変更は影響が大きいと考えられるものでしたが、会場からはその部分についてのコメントはなく、今後も継続して作業を進めることとなりました。

▽DNS Response Policy Zones（draft-ietf-dnsop-dns-rpz）

DNS Response Policy Zones（DNS RPZ）は、フルリゾルバーがクライアントに返す応答内容を、そのフルリゾルバーの運用者のポリシーにより制御可能にする機能を提供するための提案です。本提案はBIND、Knot DNS、PowerDNSなど、既存のDNSサーバーソフトウェアに実装されています。
https://dnsrpz.info/

今回のWGでは、DNS RPZは新しい機能ではなく、WGで議論するものではないという意見が出ましたが、既に実装・運用されている機能であることから、Informational RFCとして文書化を目指すこととなりました。

▽アンダースコア名のレジストリ（draft-ietf-dnsop-attrleaf）

SRVリソースレコード（*4）における「_tcp」や「_udp」、DKIM（*5）における「_domainkey」など、アンダースコア（_）で始まるラベルを特定の用途で使っているプロトコルがあります。現在、それらのラベルの仕様は、それぞれのプロトコルを定義するRFCで定められています。

本提案の背景として、「_」で始まるラベルはインターネットのホスト名としては使用できないものであり、DNSにおけるホスト名の規則とは別に管理すべきであるという点が挙げられています。

そうした「_」で始まるラベルを登録する「DNS Global Underscore Scoped Entry Registry」をIANAに設立し、対象となるリソースレコードとその用途を集中管理するための提案です。

WGでは、提案の背景と状況が再確認され、RFC 2782が発行された2000年当時にはレジストリによる管理はされなかったが、現在は管理されるプロトコルが増えてレジストリが必要とされていること、SSL/TLSで用いられるTLSA RR（*6）でも必要になることなどの確認が行われ、作業を継続することになりました。

▽DNSSEC推奨アルゴリズムの更新（draft-wouters-sury-dnsop-algorithm-update、draft-arends-dnsop-dnssec-algorithm-update）

DNSSECの電子署名とハッシュを生成するために用いられるアルゴリズムの一覧は、IANAのレジストリに登録・管理されています（*7）。本提案ではSHA-1の利用終了に向け（*8）、登録情報の一部を更新することを提案しています。

本文書では、現在利用可能とされているアルゴリズムのうちSHA-1を用いるものの取り扱いを、RFC 6944で定められている「Must Implement（実装必須）」から「Recommended to Implement（実装を推奨）」に変更し、RSASHA256を新たに「実装必須」とすることを提案しています。

今回のWGでは、取り扱いの変更にはレジストリの更新という手段もあること、提案中の「提案必須」「提案を推奨」といった表現が明確でないなどのコメントがあり、引き続き検討を進めることになりました。

homenet WGは「Home Networking」に由来する、家庭内LANなどの比較的小規模なネットワーク内、及びネットワーク間におけるさまざまな技術課題について取り扱うWGです。

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

今回のhomenet WGでは、.homenet TLDの予約に関する検討が進められました。

▽.homeに替わる特殊用途名（draft-ietf-homenet-dot）

homenet WGで標準化された家庭内ネットワークを制御するプロトコル（*9）において、名前衝突を回避するためにICANNが委任を保留した.homeの予約・利用が標準化されてしまったことが問題となりました。

この問題を解決するため、WGでは.homeに替わる新たなドメイン名を決定するための議論と検討が進められることとなりました。その結果、.homeに替えて.homenetを予約することについての検討が、dnsop WGと共同で進められました。

今回のWGでは、問題解決に向けたいくつかの選択肢が示され、.homenetをAS112プロジェクト（*10）で管理した場合にDNSSEC検証ができなくなる問題や、安全でない（insecure）委任をルートゾーンに追加することの是非などが議論され、継続して検討を進めることとなりました。

その後、IETF 98終了後の2017年3月30日に、IAB（*11）が以下の文書を発表しました（*12）。文書には、RFC 3172で定義される技術インフラのために必要な特殊用途名（special use names）を、.arpaに登録するための条件が記述されています。

これを受ける形で2017年4月6日にインターネットドラフトが改訂され、.homenetに替えて.home.arpaを予約する形で、作業が継続されています。

regext WGはRDAP（*13）の標準化と機能拡張を検討したweirds WGとEPP（*14）の機能拡張のために組織されたeppext WGの活動を一つにまとめ、RDAPなどレジストリ関連のプロトコルも扱うよう再編成されたWGです。

データエスクローの標準化（draft-arias-noguchi-registry-data-escrow、draft-arias-noguchi-dnrd-objects-mapping）

JPRSの野口昇二が共著者として作成している提案で、ドメイン名レジストリのデータエスクロー（*15）のための、データ形式と内容を定義するものです。

今回のWGで、本提案をWGの作業項目にしたいという提案があり、賛成意見が多かったことから、WGのチャーター改訂時に追加する方向となりました。

WGチャーターの改訂に向けた動き

また、WGチャーターの改訂については、既にWGの作業項目数が多く、チャーターで定めたマイルストーンの通りに進行していない状況を受け、インターネット標準とする意思がある提案や、実装が既に存在する提案の優先順位をより高くする方針であることが、WGチェアから示されました。

なお、regext WGは会期中に2回ミーティングが開催され、1回目のグループワークセッションは、既存ドキュメントの集中的なレビューにあてられました。この方式はWGミーティングにおける新しい試みとして注目されました。

IETFチェアの交代

今回、2013年から4年間にわたってIETFチェアを務めたJari Arkko氏に代わり、Alissa Cooper氏がIETFチェアに就任しました（*16）。同氏は、女性初のIETFチェアとなります。

同氏は長年にわたってIETFで活動しており、Applications and Real-Time Area（ART）のエリアディレクター、IABメンバーを歴任しました。また、IANA監督権限の移管提案について検討するIANA監督権限移管調整グループ（IANA Stewardship Coordination Group、ICG）の議長を務めるなど、インターネットガバナンスの場でも活躍しています。

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

DNS Violations Project

CZ.NICのOndrej Sury氏が、DNSプロトコル違反の事例を集めて公開する「DNS Violations」プロジェクトを始めたことと、これまでに発見された主な事例の概要について紹介しました（*17）。

同氏はこのプロジェクトを始めた目的として、

• DNSプロトコルに関する理解促進
  
• インターネットのDNS全体の改善
  
• 知見の共有
  
• 権威DNSサーバーの実装者向けに、よくある実装上の落とし穴の回避
  
• リゾルバーの実装者向けに、各種プロトコル違反を処理できるかの確認
  

の五つを挙げ、CDN（*18）の権威DNSサーバーでプロトコル違反が特に多いこと、違反の具体例として、不必要な情報の応答、0x20（*19）の処理の不具合、不正な応答パケットの生成などを紹介し、具体的な違反事例に関するコミュニティからの投稿の受け付けを開始したことを紹介しました。

会場からは、RFCにまとめるとよい、テストスイートを作るとよいといった意見や、違反事例を実名付きで公開することに関する懸念などが寄せられました。

次回の第99回IETF Meeting（IETF 99）は2017年7月16日から21日にかけ、チェコのプラハで開催されます。

本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。