第89回IETF Meeting報告（前編）

第89回IETF Meeting（以下、IETF 89）が、2014年3月2日から3月7日にかけて英国のロンドンで開催されました。FROM JPRSでは前編と後編にわたり、IETF 89及びそれに合わせて開催された会議における話題について紹介します。

前編では、DNS関連WG/BOFで報告・議論された内容についてお伝えします。

2013年6月に発生したスノーデン事件（*1）以降、IETFではさまざまなプロトコルを盗聴から守ることの重要性が検討・議論されてきました。

DNSはインターネットにおける基盤サービスとして広く使われています。DNSのプロトコル仕様では問い合わせ／応答は暗号化されないため（*2）、権威DNSサーバーやキャッシュDNSサーバーの運用者はそれぞれのDNSサーバーの利用状況を分析することで、利用者の行動状況をある程度把握・追跡できることになります（*3）。これはDNSサーバーとの間の通信内容を第三者が知り得る場合についても同様です。

こうした背景から今回のIETFでは、DNSからの情報流出を止めることを議論する場としてdnse BOFが開催されました。dnseとはEncryption of DNS requests for confidentialityのことで、機密保持のためのDNS問い合わせの暗号化を意味しています。

今回のBOFでは、

• DNSに機密保持機能がないために発生する一般的な問題の議論
  
• 既存のプロトコルをDNSの機密保持に適用可能かどうかの議論
  
• 今後、どのような問題に着目・対応していくべきかについての合意
  

が当面の目的として示され、dnsop WGに提案されたproblem statement（問題提起文書）の確認と、既に提案されている解決策が説明・議論されました。

今回の議論は、2日後に開催されたdnsop WGでも継続されました。そして、会議終了後の3月17日にこの問題について議論するためのメーリングリスト、dns-privacyが開設されました（関連URIを参照）。

dnsopはDNS Operationsに由来しており、DNSサーバーや登録情報の管理など、DNSの運用全般におけるガイドラインの開発を目的として組織されています。

ここでは今回のdnsop WGにおいて議論された話題のうち、FROM JPRS編集局が特に注目したものを中心にお伝えします。

親に情報を登録するためのリソースレコード

前回のIETF 88から継続して議論されている、DNSにおける親子間の関係を構築するために親ゾーンに登録されるリソースレコード（DS/DNSKEY、NS、グルー）を子ゾーンにおいて記述・公開するための提案は、

• DNSSEC関係のリソースレコード（DS/DNSKEY）を更新対象とする、CDS/CDNSKEYリソースレコードを用いる提案（draft-ietf-dnsop-delegation-trust-maintainance）
  
• DNSSEC関係以外のリソースレコード（NS/グルー）を更新対象とする、CSYNCリソースレコードを用いる提案（draft-ietf-dnsop-child-syncronization）
  

の二つにより標準化されることが合意されました。

標準化により、子が親ゾーンに登録するリソースレコードをDNS経由で受け渡すための枠組みが整備されることになります。

AS112プロジェクトの改善

前回のIETF 88から継続して議論されている、AS112プロジェクト（*4）の運用をDNAMEレコードで効率化するための提案（draft-ietf-dnsop-as112-dname）の標準化作業が継続して進められました。

この提案により、AS112を構成するノードはempty.as112.arpaというゾーンのみを管理し、対象となる各ゾーンはこのゾーンへのDNAMEとして設定されることになります（draft-ietf-dnsop-rfc6304bis）。

標準化作業の再開

数年間にわたり作業が進められたものの、しばらく中断されていた以下の二つの項目の標準化作業が再開されました。これらはいずれもDNS運用の根幹に関わるものであり、必要性が再認識された結果であると言えます。

1）DNSの応答サイズに関する技術的考察
2003年から2012年にかけて標準化作業が進められた、DNSの応答サイズに関する技術的考察をまとめた提案（draft-ietf-dnsop-respsize）。

2）プライミング（*5）に関する技術的考察
2007年から2009年にかけて標準化作業が進められた、プライミングに関する技術的考察をまとめた提案（draft-ietf-dnsop-resolver-priming）。

dnssdとはExtensions for Scalable DNS Service Discovery（スケーラブルなDNSサービス発見のための拡張）のことで、DNSを用いたservice discovery（サービス発見：提供可能なサービスを検索・通知する手法、DNS-SDとしてRFC 6763で定義）の仕様を拡張し、企業や大学などといった大規模なネットワークにおいても動作可能にするための手法の標準化を目的としています。

今回のdnssd WGで議論された主な項目を以下に示します。dnssd WGにおける現在の標準化作業では、DNS-SD/mDNSと既存のDNSとの相互接続性が特に重視されています。

プロトコル拡張の要件定義

前回のIETF 88から継続されているプロトコル拡張の要件定義がほぼ完了し（draft-ietf-dnssd-requirements）、以下の項目が示されました。

• ローカルでは設定なしで動作し（Zero configuration）、グローバルでは最小の設定で動作すること（Minimal configuration）
  
• 使いやすいこと（Usability）
  
• スケーラブルであること（Scalability）
  
• 段階的に展開できること（Deployability）
  
• 認証の仕組みがあること（Security）

さらに、

• 複数の選択肢があった場合、自動選択と選択肢を提示した上で利用者が選ぶ形のいずれも実現できること
  
• 企業や大学などの大規模な組織への適用のため、設定範囲（Scope）を指定できること
  
• 既存のDNS-SD/mDNS（*6）に悪影響を及ぼさないこと
  
• 複数のリンクや数千台のノードが存在した場合も動作すること

などが、項目として挙げられています。

標準化が必要な項目

DNS-SDの仕様拡張にあたり標準化が必要な項目の洗い出しと議論が進められ、以下の候補が示されました。

• mDNS/DNS間のプロキシー（Proxy）
  
• mDNSからDNSへのゾーン情報の展開
  
• 変更の通知
  
• 他のサービス発見プロトコルと既存DNSとの間の相互運用性

今後、WGにおいてこれらの項目に関する標準化作業が進められていくことになります。

国際化ドメイン名における相互運用性の問題

mDNSとDNSの相互運用性の問題として、国際化ドメイン名のドメイン名ラベルの扱いにおける仕様の違いが指摘されました（draft-sullivan-dnssd-mdns-dns-interop）。

mDNSの現在の規格では、ドメイン名の表現形式としてU-Label（*7）の使用を推奨しています。しかし、RFC 6762の定義ではドメイン名の表現形式はU-Labelであれば良く、ホスト名の規格（RFC 952/1123）や国際化ドメイン名の規格（IDNA2008）に厳密に従っている必要がないため、mDNSとDNSを相互運用する場合、名前解決において障害となり得ることが指摘されました。今後、WGにおいてこの問題の解決に向けた取り組みが進められていくことになります。

Webブラウザーなどにおいてクッキーを取り扱う際のドメイン名管理レベル（*8）の判定に使われている「Public Suffix List（*9）」の仕組みを改善する取り組みを進める場として、dbound BOFが開催されました。dboundはDomain Boundariesに由来しています。

今回のBOFでは、Public Suffix Listの現状説明とこれまでに提案されたいくつかの実装案の紹介があり、今後WG設立が必要か、標準化が完了できるかも含めた形で、議論を進めていくことになりました。

後編となる次回のFROM JPRS増刊号では、その他のWGや全体会議（プレナリー）において議論された話題、IETFに併設される形で開催されたIEPG Meetingにおける話題についてお伝えします。

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