JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
メールマガジン「FROM JPRS」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2011-08-19━ ◆ FROM JPRS 増刊号 vol.114 ◆ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ 第81回IETF Meeting報告 ～DNS関連、World IPv6 Day関連の話題を中心に～ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 今回のFROM JPRSでは、2011年7月24日から7月29日にかけてカナダのケベック シティで開催された第81回IETF Meeting（以下、IETF81）で議論された話題の 中から、JPRSが特に注目したものについてお伝えします。 ◇ ◇ ◇ ■homenet WGが正式発足 homenet WG（*1）は「Home Networking」に由来する、家庭内LANなどの比較的 小規模なネットワーク内、及びネットワーク間におけるさまざまな技術課題に ついて取り扱うWGです。homenetは従来のhomegate BOF（ブロードバンドルー ターなど、家庭内に置かれるゲートウェイ機器における技術課題について取り 扱う）における活動を引き継ぐ形で、今回のIETF81から正式なWGとなりました。 （*1）FROM JPRSでは前回のIETF80の報告からIETFにおける公式表記に従い、 WG名を小文字で表記しています。 既に、従来からのPCやスマートフォン、ゲーム機などにとどまらず、録音／録 画用の機器やデジタルカメラ／ビデオカメラなど、コンシューマー向けのさま ざまな機器がネットワーク接続機能を標準搭載するようになってきています。 また、IPv4アドレスが在庫枯渇を迎えIPv6の普及促進が図られる中、家庭内 ネットワークにおいてもIPv4／IPv6双方への対応や多種多様なプロトコル／ サービスの円滑な利用が重要な課題となってきています。 このような状況を踏まえhomenet WGでは、家庭内ネットワークの円滑な利用の ために考慮すべきさまざまな技術課題について、IPv6やDNSなどの関連する既 存のWGと協調を図りながら解決していくことを目的としています。 homenet WGでは最初に取り組むべき課題として「基本設計（architecture）」 を挙げ、その後取り組む課題として、 ・ネットワークプレフィックスの設定（prefix configuration） ・経路制御（routing） ・名前解決（name resolution） ・サービス検出（service discovery） ・境界セキュリティ（perimeter security）（*2） （*2）ファイアーウォールなど、ネットワークの境界面におけるセキュリティ 対策全般を表します。 の五つを挙げています。WGでは今後2012年末までの予定で、これらの課題にお ける標準化活動を集中的に進めていく予定です。 ■dnsop WGの動向 DNSの運用における標準化活動を進めているdnsop WGでは、AS112プロジェクト （以下、AS112）におけるIPv6関連ゾーンへの対応、DNSSECにおけるKSK（鍵署 名鍵）ロールオーバーの自動化などについての発表と議論が行われました。 ▼AS112のIPv6関連ゾーンへの対応 AS112は、本来インターネットに送出すべきではないプライベートアドレス （RFC 1918）やIPv4リンクローカルアドレス（RFC 3927）に対するDNS逆引き 検索をまとめて処理することにより、in-addr.arpaゾーンを管理する権威DNS サーバーの負荷を軽減することを目的としています。AS112には専用のAS番号 （112）とIPアドレスブロック（192.175.48.0/24）が割り当てられ（*3）、 IPエニーキャストを用いた世界的な分散運用（*4）が実施されています。 （*3）割り当てられているAS番号がプロジェクト名の由来となっています。 （*4）DNSサービスにおけるIPエニーキャストの利用はAS112において実験され、 その先駆けとなりました。得られた運用経験はルートサーバーを始めと する、その後の広域DNSサービスへのIPエニーキャスト導入に役立てら れました。 IETF81ではAS112が取り扱うDNSゾーンとしてこれまでのIPv4関連ゾーンに加え、 以下に示すIPv6関連ゾーンを追加する提案が示され、WGとして合意されました。 今後、実現のための標準化活動が進められていくことになります。 ・0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa (Unspecified)（*5） ・f.f.ip6.arpa (Multicast) ・8.e.f.ip6.arpa (Link-Local Scope) ・9.e.f.ip6.arpa (Link-Local Scope) ・a.e.f.ip6.arpa (Link-Local Scope) ・b.e.f.ip6.arpa (Link-Local Scope) ・c.e.f.ip6.arpa (Link-Local Scope) ・d.e.f.ip6.arpa (Link-Local Scope) ・e.e.f.ip6.arpa (Link-Local Scope) ・f.e.f.ip6.arpa (Link-Local Scope) ・0.0.c.f.ip6.arpa (Unique Locally Assigned) ・0.0.d.f.ip6.arpa (Unique Locally Assigned) ・0.0.0.0.1.0.0.2.ip6.arpa (Teredo) （draft-michaelson-as112-ipv6-00より引用） （*5）Loopback Address、Unspecified Address及びIPv6 Addresses with Embedded IPv4 Addressesが該当します。 ▼KSKロールオーバーの自動化に関する議論 DNSSECでは、一連の作業が子ゾーン内のみで完結するZSK（ゾーン署名鍵） ロールオーバーの自動化は比較的容易であり、BIND 9.7で導入されたスマート 署名やOpenDNSSECなど、自動化を支援するツール群が作成／導入され始めてい ます。それに対し、KSKのロールオーバーでは親ゾーンが登録／公開するDSレ コード（以下、DS）と子ゾーンが公開するKSKを厳密に同期させる必要がある ことから、完全な自動化は困難であるとされてきました。 IETF81ではKSKロールオーバーの自動化を実現する上での問題点の洗い出しが 行われ、その中で現在提案されている二つの方法が紹介されました。 一つ目の提案（draft-barwood-dnsop-ds-publish-02）は、DSと同じフォー マットを持つ新しいリソースレコードであるCDS（Child DS）を導入し、 ・子は親に登録するためのDSを、CDSにより自分のゾーンで公開 ・親は子のCDSを定期的にチェックし、自分のゾーンのDSに自動的に反映 という手順により、KSKロールオーバーの自動化を実現しようとするものです。 二つ目の提案（draft-mekking-dnsop-auto-cpsync-01）は、RFC 2136で定義さ れているDynamic Updateを用いて親のDSを更新するもので、従来からのNSレ コードやグルーレコードの親子間における同期についても、その対象としてい ます。 これらの提案はいずれも子による親のDSの能動的な更新を実現しようとするも のであり、導入には慎重な検討が必要であるという意見が多く寄せられました。 また、DSの更新ではEPP（*6）やWebインターフェース、あるいは電子メールで の申請などが既に運用されており、導入の際にはそれらとの整合性の考慮が必 要であること、WGにおける議論や提案はそれら既存の方法を置き換えるのでは なく、新しいツールを提供する形が適切であるといった意見などが寄せられま した。 （*6）Extensible Provisioning Protocolの略称。 ドメイン名の登録情報をレジストリとレジストラの間で交換するために 設計されたプロトコルです。拡張性の高さを特長としており、ドメイン 名だけでなくIPアドレスなど、他の情報のレジストリにおける利用も考 慮されています。 ■次世代のWHOISについての議論 ▼weirds bar BOFを開催 IETF81ではWEIRDS（WHOIS-based Extensible Internet Registration Data Service）と呼ばれる、Webサービスを用いた次世代のWHOISについて議論する ためのbar BOF（*7）が開催されました。 （*7）IETFで開催されるBOF（Birds of a Feather）には、担当エリアディレ クターの事前承認を必須とし、将来のWG設立を目指した形で公式に開催 される「BOF」と、周辺会議の形で非公式に開催される「bar BOF」の2 種類があります。 bar BOFのbarは酒場のバーを意味しており、非公式な集まりであること を象徴しています。しかし実際には多くの場合bar BOFは実際のバーで はなく、空いている会議室の割り当てを受けて開催されています。 bar BOFでは現在のWHOISの問題点（標準的な国際化手法がない、構造・フォー マットなどが標準化されていないなど）が挙げられ、かつてWHOISを置き換え るために開発が進められたCRISP／IRIS（RFC 3981として2005年に標準化）が なぜ普及しなかったかについての考察が行われました。 考察では、IRISには満たすべき仕様が多い、いわゆる「ヘビーウェイト」なプ ロトコルであることから実装に工数を要することが理由の一つとして挙げられ、 それを解決するためにWEIRDSではWebベースのプロトコル、いわゆるRESTful （*8）なWebサービスとすることが基本コンセプトとして示されました。 また、bar BOFでは問題点の確認と今後の方向性に関する指針が示され、今後 メーリングリストで議論を継続していくこととなりました。 （*8）REST Representational State Transferの略称。 HTTPのプロトコル仕様を定めた一人であるロイ・フィールディング氏に よって2000年に提唱された、分散システムにおいて複数のソフトウェア を連携させる際の設計原則の集合をいいます。RESTにおいてその原則を 満たした設計様式、特にWebサービスにおける様式のことは「RESTful」 であると呼ばれます。 ■IEPGにおける話題 IEPGは、インターネットサービスオペレーターにより構成される、インター ネット全体に関する運用環境や運用技術に関する技術的調整を円滑に進めるた めのグループです。IEPGでは毎回、IETF Meetingに併設する形で会議を開催し ており、初日（日曜日）の開催が通例となっています。 今回のIEPGでは、2011年6月に実施されたWorld IPv6 Day（*9）における状況 が、関係者から集中的に報告されました。 （*9）世界中のWebサービスの提供者が一斉にある1日（24時間）、自らのサー ビスをIPv6対応させることによりIPv6導入の影響を調べることを目的に、 2011年6月8日の午前0時（協定世界時：日本時間では2011年6月8日午前 9時）から24時間にわたって実施されました。 今回はそれらの中から、RIPE NCCが世界中に設置している観測点（vantage points）における計測結果と、その分析により得られた知見についてご紹介し ます。 ▼RIPE NCCにおける計測結果と得られた知見 RIPE NCCのバート・ウェイネン氏から、今回のWorld IPv6 Dayに参加した主な サイトについて、 ・DNSにおけるA及びAAAAレコードの有無 ・ping／ping6コマンド及びtraceroute／traceroute6コマンドの実行結果 ・IPv4及びIPv6によるHTTP接続の状況の変化 の点に注目、分析した結果と得られた知見について発表がありました。 発表では、DNSの設定について、 ・参加サイトの権威DNSサーバーにおけるキャッシュ／ネガティブキャッ シュのTTL値が大きかったため、World IPv6 Dayへの参加開始／終了が想 定以上に遅れたサイトがあったこと が報告され、それにより得られた知見として、 ・自サイトのTTL値の設定内容と、それによるデータの切り替わりのタイミ ングをあらかじめ把握しておくことが重要 ・障害発生時の切り戻しを円滑に実施できるように、設定変更に当たりTTL 値を可能な範囲で短くしておくことが重要 が発表されました。 また、期間中に実際に発生したトラブル事例として、 ・Webサーバーの設定ミスにより、IPv4では正常に表示されるサイトがIPv6 ではエラー（ページが見つからない：404 Not Found）となった ・期間終了後、AAAAレコードがDNS上やキャッシュ上に残っている間にIPv6 のWebサーバーをシャットダウンしたため、接続障害や遅延が発生した ・IPv6接続をプロトコル変換装置経由で提供したため、すべてのIPv6アクセ スが同一のIPv4アドレスからのアクセスと見なされ、予期しない帯域制限 がかかり、接続障害が発生した などが紹介され、こうした障害発生時における担当者への連絡方法やそのため の連絡先データベースの維持管理、運用者向けメーリングリストやtwitterな どによる、即時性を持った情報交換が重要であることなどが挙げられました。 ■次回のIETFは台北で開催～アジア地域での開催はその後しばらく予定なし 次回の第82回IETF Meeting（IETF82）は2011年11月13日から11月18日にかけて、 台北で開催されます。なお、IETF81の全体会議（Plenary）において、会場確 保の都合などからアジア地域での開催はその後しばらく予定されていないこと が発表されています。 インターネットの標準化活動に直接参加できる機会として、IETF Meetingの場 は貴重です。日本から参加しやすいアジア地域での開催となる、次回のIETF82 にぜひ参加されてみてはいかがでしょうか。 ◇ ◇ ◇ ◎関連URI - IETF 81 - Quebec City, Canada http://www.ietf.org/meeting/81/ （IETF81ホームページ） - IETF 81 Preliminary & Interim Materials https://datatracker.ietf.org/meeting/81/materials.html （IETF81発表資料一覧） - Home Networking (homenet) - Charter http://datatracker.ietf.org/wg/homenet/charter/ （homenet WGチャーター） - AS112 Project | The Nameservers at the End of the Universe http://public.as112.net/ （AS112プロジェクト 公式サイト） - weirds -- WHOIS-based Extensible Internet Registration Data Service (WEIRDS) https://www.ietf.org/mailman/listinfo/weirds （weirdsメーリングリスト） - IEPG Meeting - July 2011 @ IETF 81 http://www.iepg.org/2011-07-ietf81/ （IEPGの発表資料） ━━━━━━━━━━━━━━━━━━━━━━━━━━━【FROM JPRS】━ ■会議報告：http://jpinfo.jp/event/ ■配信先メールアドレスなどの変更：http://jpinfo.jp/mail/henkou.html ■バックナンバー：http://jpinfo.jp/mail/backnumber/ ■ご意見・ご要望：from@jprs.jp 当メールマガジンの全文または一部の文章をホームページ、メーリングリスト、 ニュースグループ、他のメディアなどへ許可なく転載することを禁止します。 また、当メールマガジンには第三者のサイトへのリンクが含まれていますが、 リンク先のサイトの内容などについては、JPRSの責任の範囲外であることに ご注意ください。 その他、ご利用にあたっての注意事項は読者登録規約にてご確認ください。 http://jpinfo.jp/mail/kiyaku.html ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 編集・発行：株式会社日本レジストリサービス（JPRS） http://jprs.jp/ http://日本レジストリサービス.jp/ Copyright(C), 2011 Japan Registry Services Co., Ltd.
Copyright©2001-2024 Japan Registry Services Co., Ltd.
