第93回IETF Meeting報告（前編）

2015年7月19日から24日にかけて、第93回IETF Meeting（以下、IETF 93）がチェコのプラハで開催されました。FROM JPRSでは今回から前編と後編の2回にわたり、IETF 93の内容について報告します。

今回のFROM JPRSでは、以下の項目に沿ってポイントとなった話題をお伝えします。

（前編）

• dnsop WGにおける話題
  - 特殊な名前の取り扱い
  - NSEC/NSEC3の積極的な活用
  - 標準化作業の進行状況
  
• eppext WGにおける話題
  - DNS運用者間におけるDNSSEC鍵の引き継ぎ

（後編）

• dprive WGにおける話題
  - DNS over DTLS
  - TLS for DNS
  - パディングオプション
• IETF全般における話題
  - エドワード・スノーデン氏の登場
  - ITU事務総局長がTechnical Plenaryに登壇
  
• 次回のIETF 94は横浜で開催

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

特殊な名前の取り扱い

今回のdnsop WGでは、例示用ドメイン名のexample.comなど特殊な名前（special names）の取り扱いが主要な話題の一つとなりました。そのきっか けとなったのは、前回の第92回IETF Meeting（以下、IETF 92）で議論された.onion（*1）の予約に関する提案（draft-ietf-dnsop-onion-tld）でした（*2）。

.onionの予約については、IETF 92終了後の2015年5月に開催された関係者による臨時のミーティングで、他の名前とは独立させて作業を進めることが合意されました（影響の大きさを考慮し、特殊用途ドメイン名（Special-Use Domain Names）の一つとして予約）。本件は既にWGでの作業を完了しており、Proposed Standard（標準化への提唱）RFCでの標準化が予定されています。

▽RFC 6761の問題点の洗い出し

今回の.onionの件によって、特殊な名前の予約のための標準的な基準・プロセスが明確になっていないという問題点が、改めて浮き彫りになりました。そして、この問題を集中的に取り扱うため、関係者を集めた少人数のデザインチームが別途組織されることになりました。

インターネット全体で予約される特殊な名前に関する現在の基準・考慮点は、RFC 6761で定義されています（*3）。今回のWGではデザインチームへのインプットとするため、RFC 6761に存在する既存の問題点の洗い出しが進められました。

WGでは、今後デザインチームで議論が必要な問題点として、

• 標準化課程（Standards Track）とすべきか、IESGによる決定とすべきか
• 誰が評価作業を実行すべきか（IESGか、dnsop WGか、WGを別に作るか）
• 予約結果を事前に外部に漏らさないことをどう担保するか
• RFC 6761で挙げられている考慮すべき七つのカテゴリー（*6）は適切か
• 予約解除のプロセスは必要か
• DNS以外の名前空間（*7）の考慮はどの程度必要か
• ICANNとのコーディネーションが必要な項目は何か
• RFC 6761はTLD以外の予約も考慮しているが、それはどう扱うのか
• IETFがプロトコルの分析以上のことを実行できるのか

などが挙げられ、検討が進められることとなりました。しかし、.onionに続くTLDの予約をWGとして進めることについては、会場は否定的な雰囲気でした。

NSEC/NSEC3の積極的な活用

JPRSの藤原が、DNSSECの不在証明の仕組みをより積極的に活用することで、DNS水責め攻撃（*8）の影響緩和を図る提案を発表しました（draft-fujiwara-dnsop-nsec-aggressiveuse）。

本提案では、応答されたNSEC/NSEC3レコードのキャッシュをより積極的に活用することで権威DNSサーバーへの問い合わせ数を減らすと共に、リゾルバーの処理コストを軽減させ、DNS水責め攻撃の影響緩和を図っています。

今回の提案は前回のIETF 92で藤原が発表したものの更新版となっており、WGでは更新部分（問い合わせにおけるAN（Aggressive Negative caching）フラグの追加、CDビットの取り扱いに関する考慮の追加）の内容を中心に議論されました。

本提案については、今後も継続して議論を進めていくことになりました。

標準化作業の進行状況

dnsop WGではここ数年間に数多くの提案と標準化作業が進められ、その一部についてはWGでの作業を完了しています。ここでは、最近の提案の内容と標準化作業の進行状況について、簡単に紹介します。

▽DNSSECの鍵更新（ロールオーバー）のタイミングに関する諸問題（draft-ietf-dnsop-dnssec-key-timing）

DNSSECの鍵更新（ロールオーバー）では、それぞれの手法・段階ごとに細心の注意を払った操作・運用が必要になります。実際、これまでにTLDを含むいくつかのドメイン名において、ロールオーバーの失敗による運用ミスの発生が報告されています。

本提案はDNSSECの鍵更新（ロールオーバー）の各形式について、手法・タイムライン・アルゴリズムなどの考慮点についてまとめ、考察したものです。

本提案はInformational（情報提供）RFCとして、発行待ち（RFC Ed Queue）の状態となっています。

▽ネガティブトラストアンカー（draft-ietf-dnsop-negative-trust-anchors）

DNSSEC署名されたゾーンにおいて運用上の事故や設定ミスが発生した場合、DNSSEC検証を有効に設定しているリゾルバーでは、そのゾーンを含むすべてのドメイン名の名前検索ができなくなってしまう場合があります。

ネガティブトラストアンカーは、特定のドメイン名配下のDNSSEC検証をリゾルバー側で一時的に無効にすることで、こうした事故が発生した場合に該当する名前が検索できなくなってしまうことを防止するための仕組みです。

本提案はInformational（情報提供）RFCとして、発行待ち（RFC Ed Queue）の状態となっています。なお、ネガティブトラストアンカーの機能は主要なリゾルバーには既に実装されており、現在の提案文書にはUnbound、BIND（*9）、Nominum Vantioにおける設定例が記述されています。

▽ルートゾーンのコピーの配布と設定（draft-ietf-dnsop-root-loopback）

よりスケーラブルなルートゾーンの運用を実現する手法の一つとして、各リゾルバーのループバックアドレスでルートゾーンのコピーを保持する権威DNSサーバーを動作させ、名前解決に利用する提案です。

本提案はIETF 92終了後の2015年6月26日にWGでの作業を終了し、Informational RFCとして、発行に向けた作業が進められています。

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

これまでに発行されたDNS関連のRFCで定義されたさまざまな用語を一つのドキュメントにまとめ、明確化するための提案です。なお、本提案はJPRSの藤原が共著者となっています。

本提案はIETF 92終了後の2015年6月24日にWGでの作業を終了し、Informational RFCとして、発行に向けた作業が進められています。

▽問い合わせ名の最小化（draft-ietf-dnsop-qname-minimisation）

フルリゾルバーが非再帰問い合わせを実行する際のアルゴリズムを変更することで権威DNSサーバーに送信する情報量を減らし、利用者がどんな名前を問い合わせたかを外部から推測されにくくするための提案です。

本提案はIETF 93直前の2015年7月13日にWG内の合意事項となり、WG Last Callで出されたコメントを反映する作業が進められています。なお、本提案はExperimental（実験仕様）RFCとして発行される予定です。

eppextはEPP Extensionsに由来しており、レジストリ・レジストラ間の登録情報のやりとりに用いられるEPP（Extensible Provisioning Protocol）の機能拡張を目的として組織されています。

DNS運用者間におけるDNSSEC鍵の引き継ぎ

DNSSECによる保護を維持しながらドメイン名のDNS運用者を変更する場合、変更元と変更先のDNS運用者が協力・連携する形でDNSSECに用いる鍵（以下、DNSSEC鍵）の引き継ぎを含む、所定の手順を実施する必要があります。

しかし、実際のインターネットにおけるレジストラ間のドメイン名の移転（いわゆるドメイン名の引っ越し）では、変更元と変更先のDNS運用者は直接のやりとりを実施しない、いわゆる「非協力的なDNS運用者（Non-Cooperating DNS Operators）」の関係にあることが多く、DNSSECの円滑な運用と普及を妨げる要因の一つとなっていました。

そのため、EPPを拡張してレジストラ間でのDNSSEC鍵の引き継ぎをレジストリ経由で実現することで、この問題を解決する提案が発表されました（draft-ietf-eppext-keyrelay）。

本提案は2013年1月に初版が発表され、オランダ（.nl）のccTLDレジストリであるSIDNにおいて、レジストリシステムへの実装と運用実験が進められました（*10）。その後、2014年1月にWG Draftとなり、SIDNでの運用経験やWG参加者からのフィードバックを取り入れる形で改良が続けられました。

その結果、IETF 93終了後の2015年7月24日にWGでの作業完了に向けたWG Last Callが開始されました。本提案はProposed Standardでの標準化が予定されています。

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

※更新履歴

• 2015/8/25　一部修正