バックナンバー：vol.140

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2014-04-11━
　　　　　　　　　　◆ FROM JPRS 増刊号 vol.140 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　　　　　　　　　第89回IETF Meeting報告（前編）　　　　　　　　　　
                    ～DNS関連WG・BOFにおける話題～                    
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

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

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

■dnse BOFにおける話題

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

（*1）アメリカ国家安全保障局（NSA）の業務を請け負っていたエドワード・
      スノーデン氏が、米国政府による極秘の監視計画「PRISM」を暴露した
      事件。PRISMには数多くのインターネット関連大手企業が極秘裏に参加
      していたため、インターネット全体に関わる大きな問題となりました。

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

（*2）DNSSECは応答の正当性（改ざんされていないこと）を署名で確認するた
      めの技術であり、通信の内容そのものは暗号化されません。

（*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 WGにおける話題

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）
の標準化作業が継続して進められました。

（*4）プライベートアドレスやリンクローカルアドレスなど、逆引きゾーンを
      ルートゾーンから委任することでルートサーバーへのDNS問い合わせの
      数を減らし、負荷軽減を図るために始められました。AS112の名前は、
      使われているAS番号に由来しています。

この提案により、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）。

（*5）プライミング：priming
      キャッシュDNSサーバーが起動時にルートゾーンのDNSサーバー情報
      （NSレコード）をルートサーバーに問い合わせ、自身の情報を初期化す
      ること。

■dnssd WGにおける話題

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）に悪影響を及ぼさないこと
  ・複数のリンクや数千台のノードが存在した場合も動作すること

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

（*6）RFC 6762/6763で定義されるMulticast DNS。現在のDNS-SDでは名前解決
      手段として、mDNSが使われています。

▼標準化が必要な項目

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においてこの問題の解決に向けた取り組みが進められていくことになります。

（*7）正規化されたUnicodeによる表現をいいます。

■dbound BOFにおける話題

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

（*8）登録者がレジストリに登録可能なレベルがどこであるかの判定に用いら
      れています。

（*9）現在、Public Suffix ListはWebブラウザーFirefoxを開発している
      Mozilla Foundationが管理しています。このリストは8,000行以上のテ
      キストファイルであり、保守性の悪さ、各TLDにおけるドメイン名管理
      構造の変化への追随性、新gTLDプログラムによりgTLDが増加した場合の
      対応など、いくつかの要改善・懸念事項が指摘されています。

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

■後編の内容について

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

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

◎関連URI

　- IETF 89 - London, England
　　http://www.ietf.org/meeting/89/
　　（IETF 89ホームページ）

　- IETF 89 Preliminary & Interim Materials
    https://datatracker.ietf.org/meeting/89/materials.html
　　（IETF 89発表資料一覧）

  - Encryption of DNS requests for confidentiality (dnse) - Charter
    http://datatracker.ietf.org/wg/dnse/charter/
    （dnse BOF公式ページ）

  - [dns-privacy] New Non-WG Mailing List: dns-privacy
    http://www.ietf.org/mail-archive/web/dns-privacy/current/msg00002.html
    （dns-privacyメーリングリスト開設のアナウンス）

　- Domain Name System Operations (dnsop) - Charter
　　http://datatracker.ietf.org/wg/dnsop/charter/
　　（dnsop WG公式ページ）

  - Extensions for Scalable DNS Service Discovery (dnssd) - Charter
    http://datatracker.ietf.org/wg/dnssd/charter/
    （dnssd WG公式ページ）

  - Domain Boundaries (dbound) - Charter
    http://datatracker.ietf.org/wg/dbound/charter/
    （dbound BOF公式ページ）

━━━━━━━━━━━━━━━━━━━━━━━━━━━【FROM JPRS】━
■会議報告：http://jprs.jp/related-info/event/
■配信先メールアドレスなどの変更：http://jprs.jp/mail/henkou.html
■バックナンバー：http://jprs.jp/mail/backnumber/
■ご意見・ご要望：from@jprs.jp

当メールマガジンの全文または一部の文章をホームページ、メーリングリスト、
ニュースグループ、他のメディアなどへ許可なく転載することを禁止します。
また、当メールマガジンには第三者のサイトへのリンクが含まれていますが、
リンク先のサイトの内容などについては、JPRSの責任の範囲外であることに
ご注意ください。
その他、ご利用にあたっての注意事項は読者登録規約にてご確認ください。
http://jprs.jp/mail/kiyaku.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
編集・発行：株式会社日本レジストリサービス（JPRS）
http://jprs.jp/
Copyright(C), 2014 Japan Registry Services Co., Ltd.