バックナンバー：vol.151

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2015/04/21━
                    ◆ FROM JPRS 増刊号 vol.151 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                    第92回IETF Meeting報告（前編）
                    ～dnsop WGにおける話題（1）～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

第92回IETF Meeting（以下、IETF 92）が、2015年3月22日から27日にかけて米
国のダラスで開催されました。FROM JPRSでは今回から2回にわたり、IETF 92
の内容について報告します。

今回の報告ではdnsop WGとdprive WGにおける話題について、以下の内容でお
伝えします。

（前編）
  ・dnsop WGにおける話題（1）
    - 問い合わせ名の最小化（qname minimisation）
    - メタ問い合わせ（Meta-Queries）に対する応答制限
    - ゾーン転送の効率化
（後編）
  ・dnsop WGにおける話題（2）
    - 特殊な名前の取り扱い――.onion
    - EDNS0への対応状況調査
    - DNS用語の明確化
  ・dprive WGにおける話題
    - 実装案の検討状況

          ◇                     ◇                     ◇

■dnsop WGにおける話題（1）

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

▼問い合わせ名の最小化（qname minimisation）

DNSでは、フルリゾルバー（キャッシュDNSサーバー）はクライアント（利用者）
から受け取った問い合わせ名と型（例えば、www.example.jpのAレコード）を
そのまま、権威DNSサーバー群への非再帰問い合わせで使用します。

これはDNSの基本動作の一つであり、DNSは長年にわたりこの形で運用され続け
てきました。しかし、2013年6月に発生したスノーデン事件（*1）以降、さま
ざまなプロトコルを盗聴から守ることの重要性が検討・議論される中で（*2）、
DNSのこの動作が一部関係者の間で問題視されるようになってきました。

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

（*2）2014年11月13日にIAB（*3）が、プロトコル設計者・実装開発者・運用
      者のすべてに対し、インターネットにおける機密性（正当な権限を持つ
      者のみが情報にアクセスできること）の確保を強く要請する声明を発表
      しています（関連URIを参照）。

（*3）Internet Architecture Boardの略称。IETF及びIESGによる標準化プロ
      セスを監督し、RFC編集者の任命及びIANAのプロトコルパラメーターの
      割り当てについて責任を負います。

その理由として、ルートサーバーやTLDの権威DNSサーバーの管理者、あるいは
それらの間の通信を傍受可能な第三者は、対象のフルリゾルバーの利用者がど
んな名前を問い合わせたか、ひいてはどんなサイトやサービスを利用している
のかを知り得る状況にある、という点が挙げられています。

この問題を解決するため、フルリゾルバーが非再帰問い合わせを実行する際の
アルゴリズムを変更し、権威DNSサーバーに送信する情報量を減らすための提
案が2014年3月に発表されました（draft-bortzmeyer-dns-qname-minimisation）。
その後、この提案は2014年10月にWGドキュメントとなり（draft-ietf-dnsop-
qname-minimisation）、WGとして作業を進めることとなりました。

本文書では非再帰問い合わせにおいて「ルートサーバーにはTLDのNS」「TLDの
権威DNSサーバーには2LDのNS」といった形で、権威DNSサーバーに問い合わせ
る情報量を必要最低限のものに「最小化（minimisation）」することが提案さ
れています。また、本文書では従来のDNS標準を変更・更新する形ではなく、
実験仕様（Experimental）としてのRFC化を目指すこととしています。

今回のWGでは、非再帰問い合わせにおける戦略として二つの方式が比較・検討
されました。一つ目はすべての問い合わせを最小化するもので、この方式では
プライバシー保護の効果は最大となりますが、逆引きなどEmpty non-terminal
（*4）が多い名前の場合、必要な非再帰問い合わせの回数が増えてしまうとい
う問題点があります。そのため、最初の非再帰問い合わせには従来の方式を用
い、その応答内容によりどこで委任されているかを学習し、以降の非再帰問い
合わせではより適切な形で最小化した問い合わせを用いる、という第二の方式
が提案されました。

（*4）そのドメイン名にはリソースレコードが一つも存在しないが、一つ以
      上のサブドメインが存在しているドメイン名。詳細はRFC 5155を参照。

今回のWGでは本件に関する明確な結論は出されず、今後メーリングリストで議
論を続けていくこととなりました。

▼メタ問い合わせ（Meta-Queries）に対する応答制限

いくつかのDNS問い合わせ型（QTYPE）は特別な意味を持っています。例えば、
ゾーン転送で用いられるAXFR、保持するすべてのレコードを問い合わせるANY
などがそれに該当します。これらは通常のDNS問い合わせに比べ、より大きな
応答を返すことが多く、DNSリフレクター攻撃（*5）など、DNS応答を用いた
DoS攻撃に悪用される事例が増えています。

（*5）DNSリフレクター攻撃の詳細については、以下の技術解説を参照。
      ■技術解説：「DNS Reflector Attacks（DNSリフレクター攻撃）」につ
      いて
      http://jprs.jp/tech/notice/2013-04-18-reflector-attacks.html

今回のWGで、権威DNSサーバーにおいてこうした「メタ問い合わせ」に対する
応答を制限・拒否するための手法を標準化するための提案が発表されました
（draft-ogud-dnsop-acl-metaqueries）。この提案は当初、ANYに対する問い
合わせのみを対象としていましたが（draft-ogud-dnsop-any-notimp）、その
後、他のメタ問い合わせをも含む、より一般的な内容に対象が広げられました。

提案では、対象とする問い合わせ型としてANY・AXFR・IXFR・RRSIGの四つを含
むとしており、他に該当する問い合わせがあるか、また、問い合わせを制限・
拒否する方法としてどのような選択肢が考えられるかが議論されました。今回
提示された選択肢には、

  ・問い合わせを単に捨てる
  ・TC（切り詰め）ビットをセットした応答を返す
  ・問い合わせ拒否（Refused）エラーを返す
  ・非実装（Not Implemented）エラーを返す
  ・「NODATA」応答（通常応答、かつAnswer secionの数が0）を返す
  ・NULL（TYPE=10）を返す
  ・新しい型を定義し、それを返す

があります。

今回のWGでは本件について活発な議論が行われましたが合意には至らず、今後
メーリングリストで議論を続けていくこととなりました。

▼ゾーン転送の効率化

DNSにおけるゾーン転送には、通常のゾーン転送（AXFR）と差分転送（IXFR）
があります。IXFRはRFC 1995として標準化されており、前回の転送から変化し
た分のみを転送することで必要なデータサイズを小さくし、ゾーン転送の効率
を上げることができます。

ただし、DNSSECを適用した場合、DNSの通常のリソースレコードの内容に変化
がない場合であっても、ゾーンの再署名やソルト（salt）（*6）の変更をした
際に署名（RRSIG）の内容が変化します。そのため、IXFRを適用した場合も転
送量があまり小さくならず、結果としてゾーン転送の効率が上がらないことが
問題点として指摘されました。

（*6）ハッシュ値を計算する際に元の文字列に付加される文字列のこと。文字
      列解読の難度を上げ、暗号の強度を高めるために利用されます。

また、従来のゾーン転送（AXFR・IXFR）では一つのサーバーで管理するゾーン
の数が多くなった場合にスケールしなくなり、DNSの運用に支障を及ぼす可能
性があるという問題も、併せて指摘されました。

このうち、前者の問題を解決するため、ゾーン転送にDNSSECのロジックを追加
することでゾーン転送を効率化（具体的にはRRSIGレコードの転送の省略）す
るための提案が発表されました（draft-mekking-mixfr）。この提案はIXFRの
上位互換（superset）のプロトコルとして、MIXFR（Minimal IXFR）と名付け
られています。

更に、後者の問題を解決するため、複数ゾーンに対応した新しいゾーン転送プ
ロトコルを開発し、従来の53番とは別のポートで動かすことを計画しているこ
とも併せて発表されました。

今回のWGでは、今回の提案ではプロトコルの要開発項目が多く、作業項目が多
くなり過ぎるのではないかという懸念がWG議長から示されました。議論の結果、
標準化作業を進めるためにdnsop WGとは別のWGを作ることも含め、メーリング
リストで議論を継続することとなりました。

■後編の内容について

後編では、dnsop WGの状況の続きと、DNSトランザクションにおける機密性
（confidentiality）の提供を目的とした、dprive WGにおける話題を中心にお
伝えします。

          ◇                     ◇                     ◇

◎関連URI

  - IETF 92 - Dallas, TX, USA
    http://www.ietf.org/meeting/92/
    （IETF 92公式ページ）

  - IETF 92 Meeting Materials
    https://datatracker.ietf.org/meeting/92/materials.html
    （IETF 92発表資料一覧）

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

  - IAB Statement on Internet Confidentiality
    https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/
    （インターネットの秘匿性に関するIABの勧告）

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

当メールマガジンは、Windowsをお使いの方はMSゴシック、Macintoshをお使い
の方はOsaka等幅などの「等幅フォント」で最適にご覧いただけます。

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