第63回IETF Meeting報告(前編)

第63回IETF Meetingが2005年7月31日から8月5日にかけて、フランスのパリ国際会議場で開催されました。多くのテーマが議論されるIETFの中から、DNSやENUM、メールアドレスの国際化に関する話題を前編・後編の2回に分けてお届けします。

前編ではDNSに関するテーマについてお伝えします。
後編では全体会議、メールアドレスの国際化、ENUM等についてお伝えします。

DNSチュートリアル

IETF Meetingでは毎回初日に、新規参加者向けの各種トレーニングや、セキュリティやRFCそのものの書き方といった、各専門分野に共通する重要事項についての各種チュートリアルを実施しています。

DNSはインターネットのインフラ技術の一つであり、インターネット上で利用されている各種プロトコル、極端に言えばホスト名やドメイン名を利用しているすべてのプロトコルに関係することになります。そのため、新しいプロトコルの標準化を行う場合、プロトコル設計者はDNSの基本的な動作原理について、きちんと理解しておく必要があります。

今回はチュートリアルの題材として初めてDNSが取り上げられ、DNSEXT WGのチェアの一人であるOlafur Gudmundsson氏とDENIC eG のPeter Koch 氏による「DNS チュートリアル」が開催されました。今回のチュートリアルではDNSの専門家以外のプロトコル設計者を対象に、DNSの基本部分に関する技術的な解説を行うことでDNSに関する理解を深め、新しいプロトコルの標準化を行う際にDNS関連で注意すべき事項について、適切に配慮してもらうことが目的とされました。

そのため、一般的なDNS関連のチュートリアルと比較して、説明の力点がかなり異なっていました。例えばDNSで取り扱い可能なパケットサイズやDNSのパケットフォーマットそのものに関する特徴、ワイルドカードを用いた場合の振る舞い、各リソースレコードのTTLを変化させた場合の影響等について、より具体的な解説がありました。またDNSと他のサービスとを関連づけるプロトコルの例として、SRVレコードおよびNAPTR/DDDSが解説されました。

その他、新たなリソースレコードをIANAに追加登録する際の手順や、未知の資源レコードをゾーンファイルに直接記述する方法といった、プロトコル設計者に特化した事項も解説されました。

このチュートリアルには100名以上の参加があり、会場はほぼ満員の状態でした。

DNSOP(Domain Name System Operations) WG

DNSOP WGは、DNSを運用するにあたっての問題点や手法を議論し、DNS運用に関する標準的手法を確立するためのWGです。

JPRSからは、次の二つの提案を行いました。

一つ目の提案は、ARPAドメインにおけるネームサーバの設定についてです。

ARPAドメインのネームサーバには、通常ns.example.net等の一般的な名前が利用されています。これに対し、ns.10.in-addr.arpaのようなARPAドメインを用いたネームサーバ名を使えば、常にグルーを得られるためARPAドメインのDNS検索を高速化でき、他ドメインから独立させられるので、ARPAドメインのDNSSEC化が行いやすくなるのではないかといった主旨の提案を行いました。

この提案に対しては「DNSSECの署名検証のパフォーマンスについては興味深いので試してみたい」、「実際のキャッシュサーバでは本当にその通りに動くのか」等、多くのコメントが寄せられました。JPRSでは寄せられたコメントの検討および提案内容への反映を行い、次回のDNSOP WGでの発表に続ける予定です。

二つ目の提案は、BGPエニーキャストを適用したネームサーバノードを構築する際に考慮すべき必要条件に関するものです。構築の際に使用するインターネット接続サービスおよびデータセンターを選択する際に考慮すべき事項について、これまでのJPRSでの運用経験に基づいた提案を行いました。提案内容は、接続サービスの選択の際に考慮すべき事項として、
  (1)バックボーンネットワークの信頼性
  (2)外部との接続性
  (3)ピアリング状況
  (4)DNSサービス用のIPアドレスブロック・AS番号に対する接続性
  (5)管理用ネットワークに対する接続性
  (6)IPv6サービスの提供
をあげ、また、データセンターの選択の際に考慮すべき事項として
  (1)セキュリティレベル
  (2)電源の冗長性
  (3)災害に関する耐久性
  (4)ロケーションの多様性
をあげ、それぞれの事項について考察を行っています。

この提案に対しては、内容がGROW (Grobal Routing Operations) WGとDNSOP WGの境界分野を対象としているというコメントがありました。今後は、GROW WGにおけるIP Anycast運用に関する標準化の動向もふまえながら、上記以外の観点についての各項目の考察を追加し、BGPエニーキャストを用いたネームサーバの運用に使用可能なガイドラインとしてまとめ、RFCとすべく提案していく予定です。

JPRSから行った提案は、次のURIで公開しています。


この他には、IABとICANNからの依頼により作成されたTLDゾーンでのDNS運用に関するドキュメントについて議論が行われました。著者より、論点をDNS運用とTLD運用の二つに分けることが提案され、DNS運用については異論なくBCP(*1) を目指すことが合意されました。TLD運用に関する部分はレジストリシステムの運用を含み、DNSOPの範囲を外れているため、DNSOPでは取り扱わないこととなりました。

DNSEXT(DNS Extensions) WG

DNSEXT WGは、DNSの各機能の拡張に関する議論を行うためのWGです。

ここ数年のDNSEXT WGでは新しいDNSSEC(DNSSECbis)の標準化作業に注力しており、この作業の成果としてRFC 4033～4035が2005年3月に発行されました。しかし、この仕様に基づきDNSSECを普及させる際の障害として、zone walkingまたはzone enumerationと呼ばれる課題が提起されています。これは、ゾーン内にデータが存在しないこと(不存在)を証明する際に、ゾーン内のデータの前後のデータを提示する形式をとるため、あるゾーンでDNSSECを運用すると、ドメイン名の一覧等そのゾーンに登録されている全ての情報を誰でも取得できる状態になることを言います。

今回のWGではこの問題を解決するための二つの提案について議論が行われました。

一つは"On-line Signing"と呼ばれるもので、実際の前後のデータを提示する替わりに、問い合わせを受けた権威DNSサーバ側で否定応答(データの不存在を示すための応答)に使用するための前後のデータを動的に生成することにより、この問題を防ぐものです。この方式では権威DNSサーバで管理するデータが多い(問い合わせ数が多くなる)場合に負荷の問題が大きくなり、また存在しない名前を外部から大量に問い合わせるDoS攻撃も成立しうるため、標準化提案として進めるという結論は出ませんでした。

もう一つはハッシュ技術を使用することにより、前後の名前をそのままの形で提示することなくデータの不存在を証明できるように機能を拡張した新しいリソースレコード(NSEC3)を導入するものです。今回のWGでは以前の議論で合意されていなかったopt-in(あるゾーンに対し部分的にDNSSECを導入する機能)をNSEC3に追加するかどうかの議論が行われ、従来のDNSSECbis同様、opt-in機能を入れないことになりました。

いずれの方式もまだ継続して議論が必要であり、どちらかの方式に決めるという状況には至っていません。

また次回のIETF Meetingまでに従来のNSECからの移行も含めたNSEC3の仕様を決めた上でいくつかの実験用ツールを作成し、ワークショップを実施したいという提案が出されました。


DNSSEC以外の話題としては、IPv6に関する技術開発等を行っている日本のTAHI Projectから、DNSの機能をテストするツールの紹介と開発作業の報告がありました。TAHI Projectでは2005年10月にベータバージョンを、2006年4月にバージョン1.0をリリースする予定とのことです。このツールに関する情報は次のURIで公開されています。


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