バックナンバー：vol.147

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2014/12/17━
                    ◆ FROM JPRS 増刊号 vol.147 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

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

第91回IETF Meeting（以下、IETF 91）が、2014年11月9日から11月14日にかけ
て米国のホノルルで開催されました。FROM JPRSでは今回から2回にわたり、
IETF 91及びそれに合わせて開催された会議について報告します。

前編では、dnsop WGにおける話題のうち、FROM JPRS編集局が特に注目したも
のを中心にお伝えします。

          ◇                     ◇                     ◇

■dnsop WGにおける話題

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

▼ルートゾーンのスケーリング

前回のIETF 90で、よりスケーラブルなルートゾーンの運用を実現する手法の
一つとして、ルートゾーンのコピーを各キャッシュDNSサーバーに配布・設定
するというコンセプトが発表されました（draft-wkumari-dnsop-dist-root）
（*1）。

（*1）この提案の詳細についてはドメイン名関連会議報告「第90回IETF
      Meeting報告（前編）」を参照。
      http://jprs.jp/related-info/event/2014/0812IETF.html

今回、この提案の実装方法として、各キャッシュDNSサーバーホストのループ
バックアドレス（*2）でルートゾーンのコピーを保持する権威DNSサーバーを
動作させ、名前解決に使用するという提案がありました（draft-wkumari-
dnsop-root-loopback）。

（*2）ネットワークにおいて自分自身を示す仮想的なアドレスです。IPv4では
      通常、127.0.0.0/8が使われます。

提案ではこの方法の利点として、存在しないTLDに対する不在応答の高速化が
期待できること、ループバックアドレスを用いるため、外部のシステムに影響
を与えないことを挙げています。

また、提案では現在のルートサーバーの運用形態を維持したまま実現すること
に重点を置いており（*3）、現在のルートゾーンの入手先・入手方法と主な実
装（BIND 9.9、Unbound 1.4 とNSD 4の組み合わせ、Microsoft Windows
Server 2012）における具体的な設定例が紹介されています。

（*3）前回のIETF 90においてCNNICから出された提案（draft-lee-dnsop-
      scalingroot：現在のルートサーバーの運用形態を大幅に変更するもの）
      が念頭にあるとも考えられます。

この提案はIETF 91終了後の2014年11月30日にWGドキュメントとなり（draft-
ietf-dnsop-root-loopback）、今後WGとして標準化作業を進めていくこととな
りました。

▼DNSクッキー

キャッシュポイズニング攻撃対策として、2006年から2008年にかけて旧dnsext
WGで標準化作業が進められたDNSクッキー（DNS Cookies）の提案が復活し、標
準化作業が再開されることになりました（draft-eastlake-dnsext-cookies）。
この提案は、EDNS0に新たなオプションコードを定義してDNSパケットにHTTPの
ものと同様の「クッキー」を加えることにより、DNS応答の偽造を防止しよう
とするものです。

復活の背景として、第一フラグメント便乗攻撃（1st-fragment piggybacking
attacks）（*4）など、新しいキャッシュポイズニング攻撃手法による脅威が
顕在化してきたことが挙げられます（*5）。

（*4）第一フラグメント便乗攻撃の詳細については、Internet Week 2013の
      JPRSランチセミナーの資料を参照。
      http://jprs.jp/tech/material/iw2013-lunch-L3-01.pdf

（*5）第一フラグメント便乗攻撃が発表されたIETF 87（2013年7～8月にドイ
      ツのベルリンで開催）において、提案の著者であったDonald Eastlake
      氏が標準化作業の復活を発表しました。

DNSクッキーは現在、BIND 9.10のオプション機能であるSIT（Source Identity
Token）として開発・実装が進められていることから、提案の著者として
BIND 9の開発者の一人であるMark Andrews氏が新たに加わっています（*6）。

（*6）Error Codeフィールドがないなど、現在のSITとDNSクッキーには若干の
      相違点があります。

この提案はIETF 91終了後の2014年11月30日にWGドキュメントとなり（draft-
ietf-dnsop-cookies）、今後WGとして標準化作業を進めていくこととなりまし
た。

▼DNSにおけるTCPトランスポートの利用

DNSでは、主な通信プロトコルとしてUDPを採用しています。UDPを採用するこ
とで通信の負荷を低くでき、DNS全体のコストや名前解決の遅延時間を短くで
きたことが、DNSがインターネットの急成長を支えられた大きな理由の一つで
あったことは、よく知られています。

しかし、UDPは送信元の詐称がTCPに比べて容易であり、キャッシュポイズニン
グ攻撃やDNSリフレクター攻撃などにつながりうるという欠点もあります。

DNSではUDPに加え、TCPも使用できます。しかし、現在のDNSの仕様では「正当
な理由がない限り、最初にUDPで問い合わせるべき（SHOULD）（*7）」と定め
られており、依然としてUDPの使用が前提となっています。

（*7）RFC 1123では「最初にUDPで問い合わせなければならない（MUST）」と
      定められていましたが、RFC 5966で緩和されました。

今回、この制限を「リゾルバーは運用上の理由により、TCPまたはUDPのいずれ
かを選べる」に緩和し、TCPとUDPを同列に扱うようにするための要件定義が提
案・議論されました（draft-dickinson-dnsop-5966-bis）。

提案では検討すべき事項として、

・EDNS0を拡張し（*8）、サーバー側からクライアント側にTCP接続の終了を通
  知できるようにする（draft-bellis-dnsop-connection-close）（*9）

・tcpm WG（*10）で標準化作業が進められているTCP Fast Open（draft-ietf-
  tcpm-fastopen）を活用し、接続確立の高速化を図る

・一度開いたTCPコネクションを再利用し、問い合わせを並行処理することで
  効率化を図る（Query Pipelining）

といった項目が挙げられています。

（*8）EDNS0はDNSの機能拡張のための仕組みであり、UDPに限らずTCPにおいて
      も使用されます。

（*9）DNSではTCPによる常時接続を許しており、接続の管理にアイドルタイ
      マーを用いる必要があります。この機能によりそれを用いることなく、
      TCP接続を管理できるようになります。

（*10）TCP Maintenance and Minor Extensionsに由来しており、TCPプロトコ
      ルの保守と小規模な機能拡張を担当しているIETFのWGです。

この提案には今回のdnsop WGの中で最も多くの時間が割かれ、活発な議論が展
開されました。この提案はIETF 91終了後の2014年12月4日にWGドキュメントと
なり（draft-ietf-dnsop-5966bis）、今後WGとして標準化作業を進めていくこ
ととなりました。

▼ネガティブトラストアンカー（Negative Trust Anchors）

ネガティブトラストアンカーは、特定のドメイン名配下のDNSSEC検証をキャッ
シュDNSサーバー側で一時的に無効にすることで、DNSSECの事故発生時に該当
する名前が全く検索できなくなってしまうことを防止するための仕組みです。
今回、ネガティブトラストアンカーの標準化に関する議論が継続して実施され
ました。

ネガティブトラストアンカーに相当する機能は現在、BIND 9、Unbound、
Nominum Vantio CacheServeなどに標準実装されています。しかし、これらは
各キャッシュDNSサーバーの運用者が手動で一時的に設定するためのものであ
り、標準プロトコルとしては確立していません。

今回の会議では標準化の必要性が議論され、肯定的な結論となりました。この
提案はIETF 91終了後の2014年12月15日にWGドキュメントとなり（draft-ietf-
dnsop-negative-trust-anchors）、今後WGとして標準化作業を進めていくこと
となりました。

■後編の内容について

後編となる次回のFROM JPRS増刊号では、dnsop以外のWG・BOFの状況と、IETF
に併設される形で開催されたIEPG Meetingにおける話題を中心にお伝えします。

          ◇                     ◇                     ◇

◎関連URI

　- IETF 91 - Honolulu, Hawaii
    http://www.ietf.org/meeting/91/
　　（IETF 91公式ページ）

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

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━【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), 2014 Japan Registry Services Co., Ltd.