第87回IETF Meeting報告（前編）

第87回IETF Meeting（以下、IETF 87）が、2013年7月28日から8月2日にかけてドイツのベルリンで開催されました。FROM JPRSでは今回から2回にわたり、IETF 87及びそれに合わせて開催された会議で報告・議論された内容について紹介します。

前編となる今回は、DNS関連WGにおける話題についてお伝えします。特に、DNSの運用技術について取り扱うdnsop WGについては、今回発表された内容にインターネット全体のDNSの運用に影響を与える可能性のあるものを多く含んでいるため、発表項目ごとの具体的な議論内容についても併せて報告します。

dnsext WGが終了

IETF 87開催直前の7月24日、DNSSECをはじめとするDNSの機能拡張に関する標準化活動を進めてきたdnsext WGの終了（Conclusion）が、IETFの活動及び標準化プロセスの技術的管理を担当するIESGから発表されました。IESGでは終了の理由を「チャーターで定めたすべての項目を成功裏に完了した（DNSEXT has successfully completed all items on its charter）」としています。

DNSの機能拡張に関する議論と標準化作業の場は、1987年にジョン・ポステル氏によって始められた「NAMEDROPPERSメーリングリスト」に遡ることができます。その後、1994年に発足しDNSSECの最初の仕様（RFC 2065）を標準化したdnssec WG、同じく1994年に発足しDNSの差分転送（IXFR）、通知（NOTIFY）、動的更新（Dynamic Update）やEDNS0など、数多くの機能を標準化したdnsind WGという、目的別に設置された二つのWGにおける活動を経て、1999年にこれらのWGを統合する形でdnsext WGが誕生しました。

そして、2000年代におけるdnsext WGの活動によりDNSSECの標準化が完了し、2010年にルートサーバーにおける実運用が開始されたことにより、WG設立時に設定された目標を達成しました。

dnsext WGは1999年の発足から15年、源流となるNAMEDROPPERSメーリングリストの発足から数えた場合、実に27年にわたって活動を続けてきたことになります。dnsext WGにおける標準化作業は終了しましたがメーリングリストは残され、DNSのリソースレコードの追加やEDNS0のオプションの追加の際の専門家のレビューの場として使われ続ける予定であることがIESGから発表されています。

dnssdext BOFが開催

人手による操作を介さず、かつDHCPサーバーやDNSサーバーなどの設定用のサーバーを使用することなくIPネットワークに接続された機器を設定するための技法として、IETFでは従来から「Zeroconf」と呼ばれる一連の技術を開発してきました。

その後、米国アップル社がZeroconfをベースに独自技術を加えた「Rendezvous（ランデブー）」を開発しました（後に「Bonjour（ボンジュール）」に改称）。Bonjourはその仕様が無償公開され、現在ではRFC 6760～6763として標準化されています。

Bonjourでは、DNSを用いたservice discovery（サービス発見：提供可能なサービスを検索・通知する手法）が使われます（DNS-SDとしてRFC 6763で定義）。ただし、現在のDNS-SDは一つのネットワークセグメント内のみでの対応であり、複数のネットワークを経由する場合の動作には対応していません。そのため、企業や大学などといった大規模なネットワークにおいても動作するようにBonjourを拡張する必要性が、IETFにおいて解決すべき課題として認識されるようになりました。

そして、そのためのWG設立に向けたBOFが前々回のIETF 85においてmdnsext BOFの名前で開催され、前回のIETF 86における同名の非公式なBar BOFを経て、今回のIETF 87ではdnssdext BOFとして開催されました。

会議では、dnssdext WGの設立が参加者の多くからサポートされました。また、会議終了後にメーリングリストにおいてチャーター案の議論が始まっており、WGの設立に向けた動きが活発化しています。

dnsop WGは活発な活動を継続

IETFでは前述したdnsext WGと共に、DNSの運用技術について取り扱うdnsop WGが長年にわたり活動を続けてきました。前述した通りdnsext WGは2013年7月で活動を終了しましたが、インターネットにおけるDNS運用の重要性はますます高まっており、dnsop WGは現在も活発な活動を続けています。

以降では、今回のdnsop WGにおいて取り上げられた主な話題についてご紹介します。

子から親へのリソースレコードの同期～CDSとCSYNC

DNSには、子の情報を親が設置することで親子間の関係を定義する重要なリソースレコード（DS、NS、グルー）があります。通常、これらのリソースレコードはEPPなど、DNSプロトコル外の方法で親に登録・更新されますが、これをDNSプロトコルで実現するための二つの提案が比較・検討されました。

一つは、CDS（Child DS）という子が設定する新たなリソースレコードを定義し、親のDSレコードをCDSに同期させる提案（draft-kumari-ogud-dnsop-cds）。そしてもう一つは、CDSと同様に子が設定するCSYNCという新たなリソースレコードを定義することで子が指定可能なリソースレコードをDS以外のものにも広げ、かつデータ更新の即時実施の可否の指定をも可能にした提案（draft-hardaker-dnsop-csync）です。

会議では、双方の提案内容の比較と提案の一本化が議論・検討されました。しかし、それぞれの提案内容に長所・短所が存在することから結論は出ず、それぞれの提案の著者同士が協議した上で、WGとしての方式を検討・提案していくことになりました。

権威DNSサーバー側からのキャッシュのフラッシュ（DNS FLUSH）

最近、DNSSECの運用ミスやシステムの不具合、あるいは登録情報の不正書き換えなどにより、TLDのサーバーを含む権威DNSサーバーにおいて不適切なゾーンデータが公開されてしまう事例がしばしば発生しています。

こうした問題は、インターネットにおけるDNSの安定運用に悪影響を及ぼします。かつ、公開されてしまったゾーンデータに長いTTL値が設定されていた場合、権威DNSサーバー側における障害復旧後も障害の影響が長時間にわたって残ることになります。

DNSプロトコルには、キャッシュDNSサーバー内のキャッシュをTTLの満了前に強制的にフラッシュする（無効にする）ための仕組みが存在しません。そのため、権威DNSサーバーの運用ミスなどで不適切なゾーンデータが公開され、それがキャッシュDNSサーバーにキャッシュされてしまった場合、個々のキャッシュDNSサーバーの側で各種実装やシステムの仕様に応じた所定の操作（コマンドの実行やサーバープロセスの再起動など）が必要になります。

このような障害からのより早い復旧を実現するため、権威DNSサーバー側からキャッシュDNSサーバーに対し、キャッシュのフラッシュを促すことを可能にするための仕組み（DNS FLUSH）が提案されました（draft-jabley-dnsop-dns-flush）。提案ではDNS NOFITYの機構を流用しTSIGと組み合わせて使用することにより、キャッシュのフラッシュの必要性をキャッシュDNSサーバーに対し、安全に通知する仕様となっています。

会議では、現在の運用状況におけるこのような機構の必要性は理解されたものの、具体的な実装方式については「worst idea（最悪のアイディア）」であるという発言もあり、今後、更なる検討や改良が必要になりそうです。

AS112プロジェクトに対する二つの改善案

AS112プロジェクト（以下、AS112）は、本来インターネット上には存在しないプライベートアドレスやリンクローカルなどの逆引きゾーンの委任をルートゾーンから受けることにより、本来インターネット上のサーバーに送られるべきではない不正なDNS問い合わせをルートサーバーから分離するために始められました。

ARINがこのプロジェクトのための専用のAS番号として112番を割り当てたことから、AS112と呼ばれるようになりました。AS112の詳細な情報は、RFC 6304に記述されています。

現在、AS112プロジェクトの権威DNSサーバーに関する二つの改善案が提案されています。一つは、AS112で用いる権威DNSサーバーの実装を現在の汎用のものからAS112に特化したものに切り替えることでサーバー運用の効率化を図るもの（draft-wkumari-dnsop-omniscient-as112）です。そして、もう一つの提案は、ゾーン全体に対する別名を定義するための仕組みであるDNAMEをAS112に適用し、ゾーン管理の効率化を図るものです（draft-jabley-dnsop-as112-dname）。

通常のゾーンではなくDNAMEを使用する背景として、AS112プロジェクトではルートゾーンなどとは異なりゾーンのマスターとなるファイルを管理するサーバーが存在しておらず、対応すべきゾーンが増えた場合、AS112を構成する個々のサーバーが同期する形でゾーンを設定・公開することが難しくなるという点が挙げられます。

会議では、二つの提案のいずれについても有効性が合意され、AS112への適用に向けた活動が進められていくこととなりました。実装手順については、まずDNAMEによる対応を進め、その後AS112に特化した実装を開発・導入していくことが合意されました。

キャッシュDNSサーバーの実装方式の工夫～HAMMER

キャッシュDNSサーバーは検索によって得られた名前をキャッシュすることにより、DNSクライアントに対する応答速度の向上と権威DNSサーバーに対する負荷の軽減を実現しています。そして、現在の実装では対象となるキャッシュデータのTTLが満了するまでは権威DNSサーバーに対する検索は実行されず、TTLの満了によりキャッシュデータが期限切れになった後に受けた最初の問い合わせを名前解決する時点で、権威DNSサーバーに対する検索が実行されるようになっています。

このため、その名前が既にキャッシュされている場合とTTLの満了により権威DNSサーバーに対する検索が必要になる場合とで、DNSクライアント側から見た応答時間に大きな差が生じることになります。また、対象となる名前が特に頻繁に検索されるもの（例えば人気のあるWebサイトのホスト名）であった場合、キャッシュが期限切れになってから次にキャッシュが有効になるまでの間に到達した問い合わせについてはキャッシュが効かないことになり、キャッシュヒット率が下がってしまう恐れがあります。

今回、キャッシュDNSサーバーの実装方式を工夫することでこうしたレコードを「キャッシュに存在し続ける（keep popular data in the cache）」状態にし、この問題を解決するための提案が発表されました（draft-wkumari-dnsop-hammer）。

具体的には、キャッシュが満了する直前（提案では2秒を推奨）に受けた問い合わせに対し、キャッシュデータを返す通常の動作に加え権威DNSサーバーに対する検索も併せて実施し、得られた応答によってキャッシュデータを更新することにより、キャッシュが期限切れになることを防止するというものです。

提案ではこの方式を「期限切れレコードのメンテナンスのための高度に自動化された方法（Highly Automated Method for Maintaining Expiring Records）」と名付け、その頭文字にちなんでHAMMERと呼んでいます。

なお、提案では対象となる名前のTTLがきわめて短い値であった場合、常にHAMMER検索を実施してしまう恐れがあるため、それを防止するための制限値（STOP）も併せて定めています。STOPの推奨値は3とされており、TTLがSTOP×HAMMER、つまり6秒よりも短かった場合、その名前に対するHAMMERは無効に設定されます。

この提案のコンセプトは、特に頻繁に検索される名前においてキャッシュの効率を向上させることにより、クライアント側の待ち時間（名前検索にかかる時間）をできる限り短縮させようというものです。

HAMMERと同様、将来必要になると考えられる名前検索をバックグラウンドで事前実行しておくことによりクライアント側の待ち時間を短縮を図る技術として、最近のWebブラウザーに実装されている「DNSプリフェッチ」があります。そして、DNSプリフェッチの導入では大きな効果が期待できる名前が「あまり検索されない名前」であるのに対し、HAMMERではその反対の「特に頻繁に検索される名前」であることは、興味深いポイントであると言えます。

会議では、この方式を実装したキャッシュDNSサーバーが普及することによる権威DNSサーバーの負荷の増大が懸念されました。ただし、増大する負荷の予測を正確に行うためにはこの方式の導入により負荷がどの程度上昇するかを明確にするための計測や評価などが必要であり、今後、これらの結果を踏まえた上で導入のための議論を進めることとなりました。

後編となる次回のFROM JPRS増刊号では、DNS関連以外のWGにおいて議論された注目すべき話題、レジストリ関連WGの話題などについてお伝えします。

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