第96回IETF Meeting報告

2016年7月17日から22日にかけて、第96回IETF Meeting（以下、IETF 96）がドイツのベルリンで開催されました。

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

• dnsop WGにおける話題
  - IETF 95以降のRFC発行状況
  - 議論された主な提案の内容と標準化作業の進行状況
  - DNS over TLSの実装状況
  
• ルートゾーンのZSK・KSKロールオーバーに関する話題
  
• 「Pecha Kucha」イベントの開催
  
• 次回のIETF Meetingについて
  

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

IETF 95以降のRFC発行状況

前回のIETF 95から2016年7月27日までに発行されたRFCは、以下の3本です。

• EDNS0によるDNSクライアントのネットワーク情報の伝達
  （draft-ietf-dnsop-edns-client-subnet、RFC 7871：Informational）
  DNSメッセージにネットワーク情報（クライアントのIPアドレス）を含めるためのEDNS0オプションを定義し、使い方を記述しています。
  Public DNSサービスなどにおいて、権威DNSサーバーへのクエリにクライアントIPアドレスを追加するために使われます。CDNなどの権威DNSサーバーでは追加されたクライアントIPアドレスを参照して、応答するIPアドレスを最適なものに設定します。


• DNSクッキー
  （draft-ietf-dnsop-cookies、RFC 7873：Standards Track）
  通信路外からの攻撃によるDNSメッセージの偽造防止のために、クライアント側でランダムなクッキーを追加するためのEDNSオプションを定義し、使い方を記述しています。


• EDNS0によるChain Query機能
  （draft-ietf-dnsop-edns-chain-query、RFC 7901：Experimental）
  フルリゾルバー（キャッシュDNSサーバー）に対しDNSSEC検証に必要な情報をまとめて送り返すことを要求するためのEDNS0オプションを定義し、使い方を記述しています。

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

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

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

DNS関連のさまざまなRFCで定義された数多くの用語を一つのドキュメントにまとめた、RFC 7719を改版するための提案です。なお、本提案はJPRSの藤原和典が共著者となっています。

今回のWGではNSEC3、ワイルドカード関連、正引き・逆引きといった用語の追加を行ったことの報告と、提案のレビュアーを募集中であることが発表されました。

▽NSEC/NSEC3の積極的な活用（draft-ietf-dnsop-nsec-aggressiveuse）

DNSSECの不在証明の仕組みを積極的に活用して、名前解決のパフォーマンス改善を図る、プロトコル変更のための提案です。なお、本提案はJPRSの藤原和典が共著者となっています。

前回のIETF 95におけるWGでの議論の結果を受け、GoogleのWallen Kumari氏のdraft-wkumari-dnsop-cheese-shop提案とマージされ、共著者にKumari氏が加わりました。今回のWGでは、Kumari氏がGoogle Public DNSにおける実装結果を紹介しています。

▽同一名に対する複数タイプの問い合わせ（draft-bellis-dnsext-multi-qtypes）

一つのDNSクエリで同時に複数のクエリタイプ（QTYPE）を問い合わせるEDNS0の拡張を行う、プロトコル変更のための提案です。

本提案では、一つのクエリ内にクエリタイプを列挙したEDNS0 Optionを追加しています。A/AAAA・A/MXなど、現在は複数のクエリを送信する必要のある問い合わせを、一つのクエリで処理できるようにすることが目的です。

▽複数応答の返答（draft-wkumari-dnsop-multiple-responses）

権威DNSサーバーからの応答のAdditional Sectionに問い合わせされた名前／タイプ以外のリソースレコード（以下、RR）の追加を行う、プロトコル変更のための提案です。

本提案では、あるRRの問い合わせの直後に問い合わせされる可能性の高いRRをフルリゾルバーに事前投入（pre-populate）することで、名前解決に要するコストを減少させることを目的としています。

提案では、追加する条件を権威DNSサーバー側で記述するためのEXTRA RRを定義しており、www.example.comのAレコードの応答に、images.example.comのAレコードやcss.example.comのAレコードを追加する例が紹介されています。

前述したdraft-bellis-dnsext-multi-qtypesでは、クライアントが同一名の別のタイプをリゾルバーに追加して問い合わせを行います。対して、本提案では権威DNSサーバーがリゾルバーから受け取った問い合わせに対し、ゾーン管理者が指定した別の名前／タイプのRRを追加して返すという点が異なります。

今回のWGでは、応答サイズの増大がDoSの原因となりうることや、DNS64やRFC7871（Client Subnet in DNS Queries）との組み合わせで問題が起きうることなどを懸念する声が上がりました。

▽BULK RRによる拡張（draft-woodworth-bulk-rr）

IPv6の逆引きなどを機械的に記述できるようにDNSのゾーンファイルフォーマットをアップデートし、BIND 9の$GENERATEディレクティブに機能を追加したものを標準化するための提案です。

BIND 9の$GENERATEディレクティブでは、連番のホスト名・IPアドレスのルールを記述すると、ゾーンファイル読み込み時にメモリ上へ個々のRRが展開されます。本提案では、個別のRRには展開せず、BULK RRのまま処理を行うことで、ゾーン転送の帯域やメモリの利用量を最小化すること、IPv6のような非常に広いネットワーク空間の逆引きを管理可能にすることを目的としています。

今回のWGでは、DNSSECで不在応答の生成を行う場合において、動的に署名する（オンザフライ）ことの確認などが行われました。

DNS over TLSの実装状況

今回のWGでは、TLS（*1）を利用してDNSにプライバシー保護の機能を提供するDNS over TLS（*2）の実装状況が報告されました。DNS over TLSは、RFC 7858として標準化されています。

報告では、DNS over TLS専用のポート番号として割り当てられた853/tcpの利用可否の状況など、各ソフトウェアにおけるDNS over TLSの実装状況がまとめられています。

また、テストベッドとして実際にDNS over TLSを試用できる環境についても紹介されています。

IETF 96期間中の7月19日に「Upcoming ZSK and KSK Changes to ther Root Zone」が、IABの支援を受けてVerisign及びICANNから解説されました。

DNSSECで用いられる鍵にはKSK（鍵署名鍵）とZSK（ゾーン署名鍵）の2種類が存在し、ルートゾーンにおいてKSKはICANNが、ZSKはVerisignが管理しています。

KSKのロールオーバーについては、ICANNの担当者から日程の概要が発表されました。主なマイルストーンとして、次の予定が公開されています。

• 2016年10月 新KSKを生成
  
• 2017年 2月 IANA Webサイトにおいて新KSKを公開
  
• 2017年 7月 ルートサーバーにおいて新KSKを公開
  
• 2017年10月 新KSKをDNSKEYとRRの署名に使用
  
• 2018年 1月 旧KSKを廃止
• 2018年 3月 旧KSKを安全に抹消し、KSKロールオーバープロセスを完了

今回のKSKロールオーバーが実行される間、ルートサーバーに対するプライミング（*3）問い合わせの応答サイズが1,139バイトから1,425バイトに増加します。

ICANNでは今回のKSKロールオーバーによる影響の規模として、インターネットユーザーの4人に1人、すなわち7.5億人が影響を受ける可能性があると予測しています。

対応として、DNSSECバリデーターにおいてRFC 5011のトラストアンカーの自動更新を有効にする（*4）ことが推奨されています。

KSKロールオーバー計画の詳細は、「Operational Plans」として5本のドキュメントにまとめられています。また、KSKロールオーバーの概要とよくある質問が2本のドキュメント「KSK Rollover at a Glance」、「KSK Rollover:Questions and Answers」に簡潔にまとめられています。

これらのドキュメントは、ICANNのKSKロールオーバー公式ページで公開されています（関連URIを参照）。

ZSKのロールオーバーについては、Verisignが2016年4月1日の24回目のOARC Workshopで発表した内容と、5月6日に公式ブログで公開した内容（*5）について、Verisignの担当者から改めて説明がなされました。

IETF 96期間中の7月21日に「Pecha Kucha」という、非公式なイベントが開催されました（*6）。Pecha Kuchaは日本語の「ぺちゃくちゃ」に由来しており、ライトニングトーク（*7）の形で、1枚につき20秒で自動的に切り替わる画像イメージで構成された20枚の資料を使って、自分の制作物やアイディアなどを連続的に紹介していく発表形式を表しています（*8）。

今回のPecha Kuchaは、その日の会議が終了した22:30から始められましたが、80名ほどを収容する会場で立ち見が出るほどの人数が参加しており、話題を集めていました。発表者にはIAB Chairを務めるAndrew Sullivan氏をはじめ、インターネットのさまざまな分野で長年にわたって活動している著名人も参加しており、「Bad Attitude」と題されている通りジョークや皮肉などが多用されたさまざまな発表が行われ、会場は笑いと称賛にあふれていました（*9）。

次回の第97回IETF Meeting（IETF 97）は2016年11月13日から18日にかけ、韓国のソウルで開催されます。

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

※更新履歴

• 2016/08/10　一部修正