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

増刊号

vol.41

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2005-08-24━
                       ◆ FROM JPRS 増刊号 vol.41 ◆
━！ＪＰ━━━━━━━━━━━━━━━━━━━━━━━━━ＪＰＲＳ━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                       第63回IETF Meeting報告(前編)
                       ～DNS関連テーマ報告～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

第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で公開しています。

◎関連URI

     Using In-Bailiwick Namesevers in .ARPA
     http://www.ietf.org/internet-drafts/draft-minda-dnsop-using-in-bailiwick-nameservers-01.txt

     BGP Anycast Node for Authotitative Name Server Requirements
     http://www.ietf.org/internet-drafts/draft-morishita-dnsop-anycast-node-requirements-01.txt

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

  (注1) BCP(Best Current Practice)。現時点におけるインターネットの運用
        において最適と考えられる手法を、遵守すべきガイドラインとしてま
        とめたもの。RFCのステータスの一つであり、RFC番号のほかにBCP番
        号が割り当てられる。

■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の仕様を
決めた上でいくつかの実験用ツールを作成し、ワークショップを実施したいと
いう提案が出されました。

◎関連URI

     Clarifications and Implementation Notes for DNSSECbis
     http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-01.txt

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

◎関連URI

     TAHI Project
     http://www.tahi.org/dns/

    ◇                     ◇                     ◇

━！ＪＰ━━━━━━━━━━━━━━━━━━━━━━━━━ＪＰＲＳ━━
              編集・発行：株式会社日本レジストリサービス(JPRS)
                            http://jprs.jp/
                            http://日本レジストリサービス.jp/
                会議報告：  http://jpinfo.jp/event/
  メールニュース配信解除：  http://jpinfo.jp/mail/
          ご意見・ご要望：  from@jprs.jp

当メールマガジンの全文または一部の文章をホームページ、メーリングリスト、
ニュースグループまたは他のメディア等へ許可なく転載することを禁止します。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Copyright(C), 2005 Japan Registry Services Co., Ltd. 2005年08月24日