第91回IETF Meeting報告（前編）

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

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

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

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

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

今回、この提案の実装方法として、各キャッシュDNSサーバーホストのループバックアドレス（*2）でルートゾーンのコピーを保持する権威DNSサーバーを動作させ、名前解決に使用するという提案がありました（draft-wkumari-dnsop-root-loopback）。
提案ではこの方法の利点として、存在しないTLDに対する不在応答の高速化が期待できること、ループバックアドレスを用いるため、外部のシステムに影響を与えないことを挙げています。

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

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

今回、この制限を「リゾルバーは運用上の理由により、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）

といった項目が挙げられています。
この提案には今回の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における話題を中心にお伝えします。

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