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

増刊号

vol.68

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2007-03-30━
                    ◆ FROM JPRS 増刊号 vol.68 ◆
━！ＪＰ━━━━━━━━━━━━━━━━━━━━━━━━━ＪＰＲＳ━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                     第68回IETF Meeting報告（前編）
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

第68回IETF Meeting（以下、「IETF68」）が、2007年3月18日から3月23日にか
けて、チェコ共和国のプラハで開催されました。旧共産圏における初の開催と
なったIETF68には45カ国から1,129人の参加者が集い、インターネットにおけ
る様々な技術の標準化に関する活発な議論が行われました。

IETFではインターネット技術に関する多くの重要な話題が議論されます。FROM
JPRSではIETF68報告を2回に分けてお伝えすることとし、本号ではその前編と
して、各ワーキンググループ（WG）等における議論のうち、特にDNSに関連す
る注目すべき話題を取り上げ、その概要や議論内容についてお伝えします。

          ◇                     ◇                     ◇

■DNSOP

DNSOP（Domain Name System Operations）WGは、DNSの管理運用に関する技術
的課題や手法について議論し、そのための標準的なガイドラインを作成するこ
とを目的としています。

ここでは、前回のミーティング以降に新たに提案された、ネームサーバ間にお
ける通信プロトコルに関する要求事項について議論された内容を報告します。

▼Requirments for the Nameserver Communication protocol
  （ネームサーバ間での通信プロトコルにおける要求事項）

現在のDNSプロトコルでは、あるネームサーバへの新しいゾーンの追加や現在
そのネームサーバの管理下にあるゾーン情報の取得といった、主に権威DNSサー
バ間における設定の同期を行うための仕組みがありません。この提案では、こ
れらを実現するための通信プロトコルを設計する際に必要となる要求事項につ
いて記述しています。

会場ではこのようなプロトコルの必要性、それをDNSプロトコルレベルで実装
することの是非について議論が行われました。その結果、ドキュメントの査読
者が会場で募られ、今後も議論を継続することとなりました。

このような機能は、従来DNSプロトコルの外部で実装・運用されていたもので
あり、今回の取り組みが、特に多くのゾーンを管理する権威DNSサーバの運用
コストを下げられる可能性をもつことから、注目すべきものであると言えます。

◎関連URI

    Requirments for the Nameserver Communication protocol
    http://www.ietf.org/internet-drafts/draft-regnauld-ns-communication-00.txt

■DNSEXT

DNSEXT（DNS Extensions）WGは、DNSの機能拡張に関する議論と標準化を行う
ことを目的としています。今回のミーティングでは、現在作業項目となってい
るインターネットドラフトの状況確認と、WGの今後についての議論が行われま
した。

ここでは、最近注目されているDNAMEの仕様改定における議論内容と、現在も
メーリングリスト上で議論が続いている本WGの今後の活動計画について報告し
ます。

▼DNAME

DNAMEは、DNSによる名前空間の部分木全体を別のドメイン名に対応づけるため
のリソースレコードです。最近、ICANNにおいて国際化TLDの実装案の一つとし
てDNAMEを採用することが検討されており、注目を集めています。

WGではRFC 2672で定義されているDNAMEの標準仕様の改定作業が進行中であり、
これまでに実運用を前提とした多くの改定が行われています。

大きな変更点としては、従来の仕様ではDNAMEにより生成されるCNAMEレコード
のTTL値を常に0としていたものを、キャッシュの有効活用により名前解決の効
率を上げることをねらいとして、新しい仕様では元となるDNAMEレコードと同
じTTL値まで許容するように変更されたことがあげられます。また、新しい仕
様ではDNAMEとDNSSECが共存した場合についても、仕様上の問題が発生しない
ように配慮されています。

また、RFC 2672で言及されていたものの具体的な方法が記述されていなかった
DNSパケット中のDNAME対応フラグについて、今回のWGでDNSSEC-OK bitにより
対応する提案が行われました。しかし、DNSSEC対応とDNAMEの対応は本来異な
ることや、別のbitを使うほうがよいのではないかという意見が出たため、合
意には至らず、メーリングリスト上で議論を継続することとなりました。

◎関連URI

    Update to DNAME Redirection in the DNS
    http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-01.txt

▼DNSEXT WGの今後について

DNSEXT WGはその前身のDNSSEC WG/DNSIND WGから通算して10年以上の長期に渡っ
て活動し続けており（*1）、既に37本のRFCを完成させています。しかし今回、
今後は現在までに上がっている作業項目に注力し、それが終了した時点でWGの
活動を休止、あるいは終了してはどうかという提案がチェアから行われました。

会場からは、DNSプロトコルに関するWGは他にないため、活動を終了するので
はなく休止する方がよいという意見が多く寄せられました。しかし最終的な結
論は出ず、現在もメーリングリスト上で活発な議論が継続されています。

今回のチェアからの提案は本WGの長年の懸案であったDNSSECbis、およびその
改訂版であるNSEC3プロトコルの完成を受けてのものです。関連URIとして、
DNSEXT co-chairsであるOlafur Gudmundsson氏からメーリングリストに出され
たメールを紹介します。

DNSはインターネットを長年にわたって支えている基盤技術の一つであり、そ
の重要性は改めて言うまでもありません。そのため、本WGの扱いも含め、IETF 
全体におけるDNSに関する今後の動きに注目する必要があると言えるでしょう。

◎関連URI

    DNSEXT future    
    http://ops.ietf.org/lists/namedroppers/namedroppers.2007/msg00209.html

（*1）DNSEXT WGで現在使われているメーリングリスト名「namedroppers」は、
      DNSの基本仕様を定めているRFC 1035にもその記述があります。実に20
      年以上の歴史を持っていることになります。

■IEPG

IEPG（Internet Engineering and Planning Group）は、インターネットの運
用についての情報交換を行うグループで、IETF会議に併せて開催されています。

今回は、JPRSが実施したIP Anycastサイトの運用実験の発表を中心に、インター
ネットインフラに関する2件の発表についてご紹介します。

▼A.DNS.JPにおけるIP Anycastの運用実験

JPRSの米谷嘉朗が、2007年2月にJP DNSにおいて実施したIP Anycastの運用実
験の結果報告を行いました。

今回実験に使用したA.DNS.JPでは、2004年からIP Anycastを東京と大阪の2カ
所において既に運用しています（*2）。今回はそれに加え、海外拠点として
ニューヨークのIP Anycastサイトを追加することにより、DNSトラフィックに
どのような変化が生じたかについて実際のインターネット環境で計測を行い、
その結果を国別・地域別にまとめた形で考察しています。

会場からは、今回の結果はISPとのピアリングの状況に依存するのではないか、
A.DNS.JP以外の測定結果もあるとよい、等のコメントが寄せられました。

▼ルートサーバへのA6レコードの問い合わせ

ルートサーバを観測していると、一定の割合（5～6％）でA6レコード（*3）に
対する問合せが発生しているがなぜだろうか、という問いかけと議論が行われ
ました。会場からは、古いBIND 9の挙動が残っているのではないか、Linuxディ
ストリビューションの一つであるDebianのコードが古いためではないか、等の
コメントが寄せられました。

IEPGにはRIRやTLDの運用者が多く参加するため、今回のような実際のインター
ネットにおける挙動に関する発表には、毎回活発なコメントが寄せられます。

◎関連URI

    The IEPG
    http://www.iepg.org/

（*2）JPRSとIIJが運用するJP DNSサービスにIP Anycast技術を導入
      －高品質サービス、耐障害性などJP DNSの信頼性がさらに向上－
      http://jprs.co.jp/press/040202.html

（*3）AAAAレコードに替わるIPv6アドレスの名前解決方式として提案された。
      A6レコードを用いた方式は2001年8月のIETF Meetingにおいて
      Experimental（実験的）とされ、標準プロトコルではなくなっている。

後編となる次号では、JPRSの米谷嘉朗が国際化URIに関する提案を行った
APPAREA BoFと、全体会議（Plenary）における内容を中心にお届けします。

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

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