第102回IETF Meeting（モントリオール）報告

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は、以下の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メッセージのやりとりや処理に使えるようになり、開発の効率化が期待できます。

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に提出されています。

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

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

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

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）。

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

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

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

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

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

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

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

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

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

発表では今後の課題として、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は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）」を作成するための枠組み

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

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

現在のDHCP（*11）ではDNS関連の情報として、フルリゾルバーの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 LLCの設立

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

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

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

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

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）。

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

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

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

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

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

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

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

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