RFC2672-JP.txt 2000/09/27 (initial version)
(C)JPNIC RFC-JP project, 2000. All rights reserved.

Network Working Group                                        M. Crawford
Request for Comments: 2672                                      Fermilab
Category: Standards Track                                    August 1999


                   非終端DNS名リダイレクション

本文書の位置づけ

   本文書はインターネットコミュニティに対するインターネット標準化過程
   にあるプロトコルを定義しており、改良のための議論と提案を求めるもの
   である。本プロトコルの標準化の段階と状態については「Internet
   Official Protocol Standards」(STD 1)の最新版を参照していただきたい。
   本文書の配布は制限されない。

著作権表示

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

1.  はじめに

   本文書は「DNAME」という新しいDNSリソースレコードを定義している。
   DNAMEは別のドメインに対してDNS名の部分木全体をマッピングする機能を
   提供する。DNAMEは単一ノードの名前空間をマッピングするCNAMEレコード
   とは異なる。

   本文書中の"…しなければならない(MUST)"、"…してはならない(MUST
   NOT)"、"要求される(REQUIRED)"、"…すべきである(SHALL)"、"…すべきで
   はない(SHALL NOT)"、"…したほうがよい(SHOULD)"、"…しないほうがよい
   (SHOULD NOT)"、"推奨される(RECOMMENDED)"、"してもよい(MAY)"、"オプ
   ションである(OPTIONAL)"は[RFC 2119]に記述されているとおりに解釈する
   こと。

2.  動機

   ここで述べられている資源レコードおよび処理規則群は、ネットワークの
   リナンバリングの際にアドレスから名前へのマッピングを維持する問題を
   解決するための方法として考案された。あるネットワークのアドレスから
   名前へのマッピングを提供する正式DNSサーバでは、DNAMEのような機構が
   存在しない場合を考えると、複数のネットワークのアドレスから名前への
   マッピングを行っているオーサライズされたDNSサーバでは、それらのネッ
   トワークのリナンバリングを行う際に再設定しなければならない。一方、
   DNAME機構を用いれば、ゾーン(zone)を構築できるのでリナンバリング時の
   再設定は必要ない。DNAMEは他にも組織的な単位ごとの名前の付け替えなど
   のさまざまな用途でも活用可能であろう。

3. DNAME リソースレコード

   DNAMEリソースレコード(DNAME RR)のニーモニックはDNAMEで、タイプコー
   ドは10進表記で39である。








Crawford                    Standards Track                     [Page 1]

RFC 2672           Non-Terminal DNS Name Redirection         August 1999


   DNAMEの書式を以下に示す。

      <owner> <ttl> <class> DNAME <target>

   この書式にはクラスの区別はなく、すべてが必須フィールドである。RDATA
   フィールド<target>は<domain-name> [DNSIS] である。

   DNAME RRはNS型の追加セクション処理の原因となる。

   DNAMEレコードの指定によって、ドメイン名のサフィックスとしてレコード
   の<owner>の代りに<target>が用いられるようになる。ゾーン(zone)ファイ
   ル中のDNAMEの使用については以下のように「無派生(no-descendants)」と
   いう制約が課される。

      DNAME RRがノードNに存在する場合には、Nには(CNAMEまたは別のDNAME
      以外の)別のデータがあってもよいが、Nの派生ノードにはいかなるデー
      タも存在してはならない(MUST)。この制約はDNAMEレコードと同一クラ
      スのレコードにのみ適用される。

   この規則によって、DNAMEレコードがそのゾーンに関してオーサライズされ
   ていないDNSサーバによってキャッシュされる場合の結果を予測可能となる。
   オーサライズされたゾーンのデータを読み込む場合には必ずこの規則を適
   用しなければならない(MUST)。この規則とDNSゾーンのオーソリティ
   [DNSCLR]に関する規則を併せると、DNAMEレコードとNSレコードが共存でき
   るのはノードを一つしか含まないゾーンの最上位に限ることが示唆される。

   受信側でDNAMEレコード形式を解釈できることを送信側で知る方法がない限
   り、[NDSIS]の圧縮機構をDNAMEレコードのRDATA部分に適用してはならない
   (MUST NOT)。このような識別を行うためのシグナリング機構は将来のDNS拡
   張の課題だろう。

   CNAMEレコードだけを利用する場合と同様に、DNAMEレコード単体もしくは
   DNAMEレコードとCNAMEレコードの組み合わせにより、名前ループ(Naming
   loop)が発生する可能性がある。リゾルバはDNSサーバに組み込まれている
   ものも含め、問い合わせに用いるリソースに関するなんらかの制限が必要
   である(MUST)。この場合、実装者はDNAMEレコードが非常に長い場合でも有
   効である場合があることに留意すべきであろう。

4.  問い合わせ(query)処理

   DNAME機構を開発するためには、サーバとリゾルバの双方で名前解決アルゴ
   リズム[DNSCF]に対する若干の変更が必要である。

   どちらの場合でもアルゴリズムに対する変更は名前(QNAMEかSNAME)の置換
   をDNAMEレコードで制御する処理を組み込むものである。この処理は
   「DNAME置換」という名称で参照されることになる。






Crawford                    Standards Track                     [Page 2]

RFC 2672           Non-Terminal DNS Name Redirection         August 1999


4.1.  サーバによる処理

   非再帰的サービスを実行するサーバにおいて、4.3.2[DNSCF]のステップ3.c
   およびステップ4は、ワイルドカード(「*」)ラベルを確認する前にDNAMEレ
   コードを確認しゾーンデータおよびキャッシュ内にあるDNAMEレコードを返
   答するように変更される。

   拡張DNS[EDNS0]でバージョン0(ゼロ)の問い合わせまたは非拡張問い合わせ
   を送信してくるDNSクライアントはDNAMEレコードを解釈できないと考えら
   れる。したがって、本仕様が実装されているサーバが拡張されていない問
   い合わせに解答する場合、クライアントが正しいDNSデータに到達するため
   に利用できるように問い合わせ処理中に出現する各DNAMEレコードに対して
   CNAMEレコードを合成すべきである(SHOULD)。バージョンがゼロよりも大き
   い拡張DNSにおけるクライアントとサーバの挙動はそれぞれのバージョンが
   定義される際に定義されるだろう。

   合成CNAME RRを提供する場合は以下の条件を満たさなければならない
   (MUST)。

     問い合わせのQCLASSと同じCLASS

     TTLをゼロ(0)に設定

     DNAME RRが出現する時点で有効であるQNAMEに等しい<owner>

     DNAME置換の結果として生成されたQNAMEを含むRDATAフィールド

   サーバが適切な鍵をオンライン上[DNSSEC, SECDYN]に公開している場合、
   合成CNAME RRに対応するSIG RRを生成して返してもよい(MAY)。

   修正されたサーバアルゴリズムを以下に示す。

   1. 名前サーバが再帰サービスを提供したいかによって、返答中において再
      帰するかを設定する。再帰サービスを利用できるようになっている場合
      に問い合わせにおいてRDビットを用いた明示的要求がある場合はステッ
      プ5に進む。それ以外の場合はステップ2に進む。

   2. 利用可能なゾーンからQNAMEへの上流のうち直近のゾーンを検索する。
      見つかった場合はステップ3に進み、それ以外はステップ4に進む。

   3. 発見したゾーンにおいてラベルごとに合致処理を開始する。合致処理の
      終了条件を以下に示す。







Crawford                    Standards Track                     [Page 3]

RFC 2672           Non-Terminal DNS Name Redirection         August 1999


      a. QNAME全体が合致する場合は、目的のノードを見つけたことになる。

     そのノードのデータがCNAMEでかつQTYPEがCNAMEに合致しない場合は、
     CNAME RRを応答のanswerセクションにコピーしてQNAMEをCNAME RRの
     正規名に変更する。それからステップ1に戻る。

     それ以外の場合は、QTYPEに合致するすべてのRRを解答セクションに
     コピーしてステップ6に進む。

      b. 合致したデータからオーサライズされたデータ以外が得られる場合、
     参照先が存在する。ゾーンの下部に沿って分割されているNS RRsを
     含むノードを対象とする場合にこのような事態が発生する。

     副ゾーン(subzone)に対するNS RRを応答のauthorityセクションにコ
     ピーする。存在するアドレスすべてをadditionalセクションに入れ
     る。これらのアドレスがオーサライズされたデータもしくはキャッ
     シュから取得できない場合には、glue RRsを利用する。ステップ4に
     進む。

      c. 合致させられない(たとえば、対応するラベルが存在しない)ラベル
     が含まれる場合は、合致する最後のラベルがDNAMEレコードを持つか
     確認する。

     その場所にDNAMEレコードが存在するなら、そのレコードをanswerセ
     クションにコピーする。QNAME中の<owner>をこのレコードの
     <target>に置換した結果QNAMEが<domain-name>の許容長を越えてし
     まう場合、RCODEにYXDOMAIN[DNSUPD]を設定して終了する。それ以外
     の場合には置換を行って処理を続ける。DNAMEレコードを識別するバー
     ジョンの[EDNS0]を用いていない問い合わせだった場合、上記で説明
     したようにサーバはCNAMEレコードを合成してanswer部分に入れるべ
     きである(SHOULD)。それからステップ1に戻る。DNAMEレコードがな
     い場合は"*"ラベルが存在するかを確認すること。

     "*"ラベルが存在しないなら、探している名前が問い合わせ中の元の
     QNAMEなのか、それとも次にCNAMEにすべき名前なのかを確かめる。
     名前が元からのものなら応答に"authoritative name error"を設定
     して処理を終える。それ以外の場合は単に処理を終了する。

     "*"ラベルが存在するなら、そのノードのRRをQTYPEに対して合致さ
     せる。合致するレコードはすべてanswerセクションにコピーするが、
     QNAMEには"*"ラベルのノードではなくRRの所有者(owner)を設定する。
     その後ステップ6に進む。






Crawford                    Standards Track                     [Page 4]

RFC 2672           Non-Terminal DNS Name Redirection         August 1999


   4. キャッシュに対する合致処理を開始する。キャッシュ中にQNAMEが発見
      された場合、付属しているRRのうちQTYPEに合致するものすべてを
      answerセクションにコピーする。キャッシュ中にQNAMEが含まれないが、
      DNAMEレコードがQNAMEの上流に存在する場合、そのDNAMEレコードを
      answerセクションにコピーする。オーサライズ・データからの委譲デー
      タが存在しない場合には、キャッシュ中で最も適する値を一つ探して
      authorityセクションに入れる。ステップ6に進む。

   5. 問い合わせに対する解答には、ローカルリゾルバもしくはそのアルゴリ
      ズムのコピー(本文書のリゾルバの項を参照)を用いる。結果は、中間の
      CNAMEやDNAMEすべてを含めて、応答のanswerセクションに格納すること。

   6. 問い合わせのadditionalセクションに役に立つ可能性がある他のRRを追
      加する場合には、ローカルデータのみを用いること。処理を終了する。

   ゾーン内のデータが3章の無派生制約を破らない限り、ステップ4で説明し
   たように、DNAMEには高々一つの上流しか存在しない。この事実は実装する
   際に、ステップ3cおよびステップ4でDNAMEレコードにぶつかったときに検
   索を終了する条件として役立つだろう。

4.2.  リゾルバでの処理

   再帰サービスを提供するリゾルバおよびサーバは、DNAMEをCNAMEに類する
   ものとして扱うための変更を行う必要がある。[DNSCF]の5.3.3のリゾルバ・
   アルゴリズムはステップ4.dをステップ4.eに変更して新しいステップ4.dを
   挿入する変更を行う。変更を加えた完全なアルゴリズムを以下に示す。

   1. ローカル情報中に答えがあるかを確認し、存在する場合はその答えをク
      ライアントに返す。

   2. 問い合わせるために最も適したサーバ群を見つける。

   3. ステップ2で発見したサーバに対し、いずれかが応答を返すまで問い合
      わせを送る。

   4. 応答を分析し、以下のいずれかの処理を行う。

      a. 応答が質問を返すか"name error"を含んでいる場合はデータをキャッ
         シュし、クライアントにもそのデータを返す。

      b. 応答が別のもっとよいサーバへの委譲を含んでいる場合はその委譲
         情報をキャッシュしてステップ2に進む。

      c. 応答がCNAMEを示しているが解答にはなっていない場合には、CNAME
         をキャッシュし、SNAMEをそのCNAME RRの正規名に変更してステップ
         1に進む。





Crawford                    Standards Track                     [Page 5]

RFC 2672           Non-Terminal DNS Name Redirection         August 1999


      d. 応答がDNAMEを示しているが解答にはなっていない場合には、その
         DNAMEをキャッシュする。SNAMEにおいて、DNAMEの<target>をDNAME
         の<owner>に対する代替として利用すると<domain-name>の許容長を
         越えてしまう場合は、アプリケーションに
         "implementation-dependent error"を返す。それ以外の場合は実際
         に置換してからステップ1に進む。

      e. 応答の内容がサーバでの失敗もしくはなんらかの予想外の内容であ
         る場合は、そのサーバをSLISTから削除し、ステップ3に戻る。

   DNAMEレコードを解釈できるが非拡張の問い合わせを送るリゾルバもしくは
   再帰サーバは、応答中に含まれるすべてのDNAMEレコードの<owner>のサブ
   ドメインとなっている<owner>を持つCNAMEが応答に含まれている場合は、
   そのCNAMEレコードをすべて削除するようにステップ4.cを拡張しなければ
   ならない(MUST)。

5.  利用例

5.1.  組織の改名

   FROBOZZ.EXAMPLEというドメイン名の組織がACME.EXAMPLEというドメイン名
   の組織の一部となる場合、前者が古いゾーンで以下のように情報を置き換
   えることで移行が容易になるだろう。

       frobozz.example.  DNAME    frobozz-division.acme.example.
                         MX       10       mailhub.acme.example.

   www.frobozz.exampleに対する拡張再帰問い合わせに対する応答には、その
   answerセクション中に上記に示したDNAMEレコードと
   www.frobozz-division.acme.exampleに対する関連RRを含む。

5.2.  短いプリフィックスに対するクラスレス委譲

   in-addr.arpa委譲[INADDR]のためのクラスレス機構は、DNAMEレコードを使
   うことでプリフィックスを24ビットより短くするように拡張できる。たと
   えば、192.0.8.0/22というプリフィックスは以下のレコードで委譲可能で
   ある。

       $ORIGIN 0.192.in-addr.arpa.
       8/22    NS       ns.slash-22-holder.example.
       8       DNAME    8.8/22
       9       DNAME    9.8/22
       10      DNAME    10.8/22
       11      DNAME    11.8/22








Crawford                    Standards Track                     [Page 6]

RFC 2672           Non-Terminal DNS Name Redirection         August 1999


   192.0.9.33というアドレスのホストに対してリバースゾーンを生成した結
   果できあがる典型的なエントリは以下に示すようになるだろう。

       $ORIGIN 8/22.0.192.in-addr.arpa.
       33.9    PTR     somehost.slash-22-holder.example

   "/"文字の選択に関してはここでも[INADDR]と同じ注意が適用される。

5.3.  ネットワークのアドレス付け替え(リナンバリング)のサポート

   IPv4ネットワークで日常的にリナンバリングが行われるようになれば、NS
   レコードを用いた委譲の代りにDNAMEレコードを利用した委譲を使うことで、
   アドレス空間委譲の管理が簡単にできるようになるだろう。

      $ORIGIN new-style.in-addr.arpa.
      189.190           DNAME    in-addr.example.net.

      $ORIGIN in-addr.example.net.
      188               DNAME    in-addr.customer.example.

      $ORIGIN in-addr.customer.example.
      1                 PTR      www.customer.example.
      2                 PTR      mailhub.customer.example.
      ; etc ...

   これによって"example.net"というISPに割り当てられている
   190.189.0.0/16というアドレス空間を変更する際に、ISPやその利用者によ
   るそのアドレス空間の使用について記述するゾーンファイルを変更する必
   要がなくなる。

   現在においては、IPv4ネットワークのリナンバリングは非常に困難な仕事
   であり、DNSの更新は全体の労力から見ればほんの一部に過ぎないので、こ
   の機構にはあまり価値はないかも知れない。しかしIPv6でのリナンバリン
   グ作業はかなり異なるのでDNAME機構が有用な役目を果たすことになるかも
   しれない。

6.  IANAに関する考察

   本文書はニーモニックDNAMEおよびタイプコード39(10進数)を持つ新しい
   DNSリソースレコードタイプを定義している。名前/ナンバリング空間は
   [DNSIS]に定義されている。この名前および番号はすでにIANAに登録されて
   いる。









Crawford                    Standards Track                     [Page 7]

RFC 2672           Non-Terminal DNS Name Redirection         August 1999


7.  セキュリティに関する考察

   DNAMEレコードはDNSサーバまたはリゾルバへの偽造レコードの挿入という
   問題に関してはCNAMEレコードと同様であるが、DNAMEの効果が名前空間の
   サブ木全体に及ぶという点が異なる。このレコードタイプを認証するため
   には[DNSSEC]の機能を利用できる。

8.  参考文献

   [DNSCF]  Mockapetris, P., "Domain names - concepts and facilities",
            STD 13, RFC 1034, November 1987.

   [DNSCLR] Elz, R. and R. Bush, "Clarifications to the DNS
            Specification", RFC 2181, July 1997.

   [DNSIS]  Mockapetris, P., "Domain names - implementation and
            specification", STD 13, RFC 1035, November 1987.

   [DNSSEC] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
            Security Extensions", RFC 2065, January 1997.

   [DNSUPD] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
            "Dynamic Updates in the Domain Name System", RFC 2136, April
            1997.

   [EDNS0]  Vixie, P., "Extensions mechanisms for DNS (EDNS0)", RFC
            2671, August 1999.

   [INADDR] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
            ADDR.ARPA delegation", RFC 2317, March 1998.

   [KWORD]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels," BCP 14, RFC 2119, March 1997.

   [SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic
            Update", RFC 2137, April 1997.

9.  著者連絡先

   Matt Crawford
   Fermilab MS 368
   PO Box 500
   Batavia, IL 60510
   USA

   Phone: +1 630 840-3461
   EMail: crawdad@fnal.gov




Crawford                    Standards Track                     [Page 8]

RFC 2672           Non-Terminal DNS Name Redirection         August 1999


10.  完全な著作権表示

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   Copyright (C) The Internet Society (1999).  All Rights Reserved.


   本記述とその翻訳は複写し他に提供することができる。また論評を加えた
   派生的製品や、この文書を説明したり、その実装を補助するもので、上記
   の著作権表示およびこの節を付加するものはすべて、全体であってもその
   一部であっても、いっさいの制約を課されること無く、準備、複製、発表、
   配布することができる。しかし、この文書自体にはいかなる方法にせよ、
   著作権表示やインターネットソサエティもしくは他のインターネット関連
   団体への参照を取り除くなどの変更を加えてはならない。インターネット
   標準を開発するために必要な場合は例外とされるが、その場合はインター
   ネット標準化過程で定義されている著作権のための手続きに従わなければ
   ならない。またRFCを英語以外の言語に翻訳する必要がある場合も例外であ
   る。

   以上に述べられた制限は永久的なものであり、インターネットソサエティ
   もしくはその継承者および譲渡者によって破棄されることはない。

   本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ
   トソサエティおよびIETFは、この情報がいかなる権利も侵害していないと
   いう保証、商用利用および特定目的への適合性への保証を含め、また、こ
   れらだけに限らずすべての保証について、明示的もしくは暗黙的の保証は
   行われない。

謝辞

   RFCエディターの職務に関する財政支援は、現在インターネットソサエティー
   によって提供されている。




















Crawford                    Standards Track                     [Page 9]

  RFC-JP日本語翻訳物の著作権に関する告知

  本文書は、インターネット技術の正しい普及と振興を目的として、社団法人
  日本ネットワークインフォメーションセンター(JPNIC)が行っているRFC翻訳
  プロジェクト(RFC-JP)の成果物である。rfc-copyright-storyに従い、
  RFC2220以降のものについては“Full Copyright Statement”を含め、
  RFC2219以前のものについては原著者の了解を得て翻訳している。これによ
  り作成された二次的著作物である本文書の著作権はJPNICが保持するが、こ
  の権利の設定は原文から新たな翻訳を作成し公開することを妨げるものでは
  ない。

  また、RFC-JPとしてこの文書に記載された情報の内容が正確であることに努
  めているが、正確性を含めいっさいの品質についてこれを保証するものでは
  ない。したがって、この文書に記載された情報に基づいて貴方あるいは貴組
  織がとられた行動によって引き起こされる結果に対して、JPNICは何ら保証
  を与えない。

  本文書は、本著作権表示を含めて改変しないことを条件に再配布を許可する。
  ただし日本語訳は固定ではなく、誤りの発見や正確性の向上のために必要に
  応じて適宜更新される可能性がある。常に最新の版を入手するようにしてい
  ただきたい。最新版は<URL:http://rfc-jp.nic.ad.jp/>から入手できる。