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

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


          ドメイン名システム中のバイナリラベル

本文書の位置づけ

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

著作権表示

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

1. 導入と用語

   本文書ではドメイン名に現れることのある「ビット列ラベル(Bit-String
   Label)」を定義する。この新しいラベルタイプは連続する"1ビットのラベ
   ル"を簡潔に表現し、ドメイン名木のbinary-namedセクション中の任意のビッ
   ト境界に格納される資源レコードを実現する。

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

2. 動機

   バイナリラベルの作成意図は、下部の名前空間の構造の最も自然な表現が
   バイナリである場合の、データ格納に関する問題および任意の境界におけ
   るオーソリティの委譲に関する問題を効果的に解決することである。

3. ラベル形式

   256個までの1ビットラベル群を単一のビット列ラベルにまとめることがで
   きる。ビット列ラベル内では最も有意なビット("最高位レベル"ビット)が
   最初に置かれる。これはDNSラベル自体の順序、すなわち最も有意でないラ
   ベル("最低位レベル"ラベル)を最初に置くという順序とは異なる。それに
   もかかわらず、バイナリラベルを表現するためにはこの順序が最も自然で
   効果的と考えられる。







Crawford                    Standards Track                     [Page 1]

RFC 2673        Binary Labels in the Domain Name System      August 1999


   ビット列ラベルが連続する場合にはASCIIラベルの順序とまったく同様に、
   最初に現れるラベル内のビットはその後に現れるビット列ラベル中のビッ
   トよりも有意でない、すなわち「低位のレベルに存在する」ことになる。

3.1. 符号化

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2     . . .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
     |0 1|    ELT    |     Count     |           Label...         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+


   (上図の1区切りは1ビットを表している。)

   ELT     000001(2進)。
       ビット列ラベルに割り当てられる6ビット拡張ラベルタイプ[EDNS0]

   Count   Labelフィールド中の有意なビットの数。
       Count値ゼロ(0)は有意ビットが256ビットであることを示す(その
       ためDNSルートを示すヌルラベルはビット列ラベルとしては表現で
       きない)。

   Label   1ビットラベルの連なりを表現するビット列で、
       最も有意なビットを最初に置く。上図で17の位置にある1ビットラ
       ベルが表現するのは、16の位置にある1ビットラベルが表現するド
       メインのサブドメインである。以下のビットについても同様であ
       る。

       ラベルフィールドの右側は0個から7個のビットでパディングされ
       る。パディングする目的はフィールド全体をオクテットの整数に
       することである。これらのパディング用のビットは伝送中はゼロ
       で、受信時には無視されなければならない(MUST)。

   ビット列は2個以上のビット列ラベルに分割してもよいが、分割点は重要で
   はないため保存する必要はない。非常に高性能なサーバ実装ではメッセー
   ジ圧縮[DNSIS]の効果が最大になるようにビット列ラベルを分割するかもし
   れない。もっと単純なサーバは、1ビットラベルの間にたまたまゾーン境界
   があった場合、そのゾーン境界でビット列ラベルを分割するかもしれない。




Crawford                    Standards Track                     [Page 2]

RFC 2673        Binary Labels in the Domain Name System      August 1999

3.2. テキスト表現方法

   ゾーンファイル中などではビット列ラベルはテキストで表現される。ビッ
   ト列ラベルは区切り記号"\["と"]"で<bit-spec>を囲む形式で表現される。
   <bit-spec>はdotted-quad(ドットでつながった四つ組)、もしくは基数
   (base)指示子およびその基数に適した数列、のいずれかである。後ろにス
   ラッシュ(/)とラベル長が付くこともある。基数指示子は二進数、八進数、
   十六進数に対してそれぞれ「b」「o」「x」となっている。ラベル長は有意
   なビットの数を示しており、dotted-quadの場合は1から32までの間でなけ
   ればならない(MUST)。基数指示子を使う形式の場合は全体で1から256まで
   の間でなければならない(MUST)。ラベル長が省略されている場合は、
   dotted-quad形式では32が指定されていることになる。基数指示子による形
   式の場合は、二進数、八進数、十六進数に対してはそれぞれの数の1倍、3
   倍、4倍を示す。

   拡張バッカス・ナウア形式[ABNF]では以下のように表現される:

     bit-string-label =  "\[" bit-spec "]"

     bit-spec         =  bit-data [ "/" length ]
                       / dotted-quad [ "/" slength ]

     bit-data         =  "x" 1*64HEXDIG
                       / "o" 1*86OCTDIG
                       / "b" 1*256BIT

     dotted-quad      =  decbyte "." decbyte "." decbyte "." decbyte

     decbyte          =  1*3DIGIT

     length           =  NZDIGIT *2DIGIT

     slength          =  NZDIGIT [ DIGIT ]

     OCTDIG           =  %x30-37

     NZDIGIT          =  %x31-39

   <length>が存在する場合は、<bit-data>中の数字の数は<length>で定義さ
   れるビット数と同じでなければならない(MUST)。最後の十六進数もしくは
   八進数に無意のビットが含まれている場合は無意のビットはゼロでなけれ
   ばならない(MUST)。<dotted-quad>は関連する<slength>が24以下の場合で
   もドットで区切られた四つの部分をすべて含むが、基数指示子を使う形式
   と同じく無意のビットはゼロでなければならない(MUST)。

   <decbyte>で表現される数はゼロから255までの間でなければならない。

   <length>で表現される数はゼロから256までの間でなければならない。

   <slength>で表現される数は1から32までの間でなければならない。






Crawford                    Standards Track                     [Page 3]

RFC 2673        Binary Labels in the Domain Name System      August 1999


   ビット列ラベルのテキスト形式を計算機で生成する場合はラベル長は省略
   せず明示するべきである(SHOULD)。

3.2.1. 例

   以下の四つのテキスト形式は同じビット列ラベルを表現している。

                             \[b11010000011101]
                             \[o64072/14]
                             \[xd074/14]
                             \[208.116.0.0/14]

   以下のふたつ連続したビット列ラベルは、上の例のビット列ラベルと同じ
   DNS木内の関連位置を示している。

                             \[b11101].\[o640]

3.3. 標準形表現および順序

   バイナリラベルの伝送形式およびテキスト形式のどちらも、バイナリラベ
   ルを複数の連続するビット列ラベルにまとめる処理をある程度自由に行え
   る。DNS署名レコード[DNSSEC]の生成や確認を行うため、バイナリラベルは
   予測できる形式でなければならない。このような場合のために標準形形式
   が定義されている。標準形形式は、可能な限り少ないビット列ラベル群で、
   ビット列ラベルの連なり中のおそらく最初の(最も有意度の低い)ラベルを
   除いたすべてのラベルが最大長となる形式と定義されている。

   たとえば、256個までの1ビットラベル列の標準形は単一のビット列ラベル
   となる。513から768個の1ビットラベル列の標準形は3個のビット列ラベル
   となり、2番目と3番目のビット列ラベルには256個のラベルビットが含まれ
   る。

   ドメイン名の標準的な順序[DNSSEC]はバイナリラベルを含むため以下のよ
   うに拡張される。並べ方は以前と変らずラベル毎で、最も有意なラベルか
   ら最も有意でないラベルの順となる。拡張によってラベルは1ビットラベル
   または標準(コード00)ラベルとなる。1ビットラベルは標準ラベルの前に置
   き、0(ゼロ)ビットは1ビットの前に置く。ラベルがない場合は[DNSSEC]で
   定義されているとおりすべてのラベルの前に置く。












Crawford                    Standards Track                     [Page 4]

RFC 2673        Binary Labels in the Domain Name System      August 1999


  たとえば以下のドメイン名は正しい順序で並んでいる。

                         foo.example
                         \[b1].foo.example
                         \[b100].foo.example
                         \[b101].foo.example
                         bravo.\[b10].foo.example
                         alpha.foo.example

4. 処理規則

   1ビットラベルは他のいかなる種類のラベルとも合致しない。特に、"0"や
   "1"という単一のASCII文字によって表現されるDNSラベルはビット値0や1に
   よって表現される1ビットラベルと同じではない。

5. 議論

   伝送形式でのラベル長ゼロ(0)は256ビット列を示す。これはこの特殊な場
   合を最適化するためにではなく、ゼロビットラベルを付けることを絶対不
   可能にするための定義である。

6. IANAに関する考察

   本文書はビット列ラベルという拡張ラベルタイプを定義し、[EDNS0]で定義
   されている空間にコードポイント000001(2進)を登録することを要求してい
   る。

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

   伝統的なASCII DNSラベルに当てはまるセキュリティに関する考察はすべて
   バイナリラベルにも同じく当てはまる。3.3での標準形および標準的順序に
   従うことで、バイナリラベルをDNSセキュリティ[DNSSEC]で扱えるようにな
   る。


















Crawford                    Standards Track                     [Page 5]

RFC 2673        Binary Labels in the Domain Name System      August 1999


8. 参考文献

   [ABNF]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", RFC 2234, November 1997.

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

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

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

   [KWORD]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels," BCP 14, RFC 2119, March 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 6]

RFC 2673        Binary Labels in the Domain Name System      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 7]

  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/>から入手できる。