第101回IETF Meeting（ロンドン）報告

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は、以下の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サーバーの認証方式を定義します。
  

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として発行されました。

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）を返すという従来の動作に加え、

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

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

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

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

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

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

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

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

が発表されました。

本件は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?」と題した発表を行いました。

発表では、

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

が呼び掛けられました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

計測の結果、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に関する適切な応答の仕方は以下のいずれかであり、そのように実装すべきであることを呼び掛けています。

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

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

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