JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト

メールマガジン「FROM JPRS」

バックナンバー：vol.135

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2013-09-05━
　　　　　　　　　　◆ FROM JPRS 増刊号 vol.135 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

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

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

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

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

■DNS関連WG全般の動向

▼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において取り上げられた主な話題についてご紹介し
ます。

■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の話題などについてお伝えします。

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

◎関連URI

　- IETF 87 - Berlin, Germany
　　http://www.ietf.org/meeting/87/
　　（IETF 87ホームページ）

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

　- DNS Extensions (dnsext) - Charter (concluded WG)
　　http://datatracker.ietf.org/wg/dnsext/charter/
　　（dnsext WG公式ページ（終了後も保存））

  - [dnsext] WG Action: Conclusion of DNS Extensions (dnsext)
    http://www.ietf.org/mail-archive/web/dnsext/current/msg13220.html
    （dnsext WG終了のアナウンス）

  - Zero Configuration Networking (Zeroconf)
    http://www.zeroconf.org/
    （IETFにおけるzeroconf WGの活動についてまとめられたページ）

　- 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

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