RFC2673 日本語訳

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

コメントを求めるワーキンググループM.クロフォードの要求をネットワークでつないでください: 2673年のフェルミ国立加速研究所カテゴリ: 標準化過程1999年8月

                Binary Labels in the Domain Name System

ドメインネームシステムにおける2進のラベル

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

Copyright(C)インターネット協会(1999)。 All rights reserved。

1.  Introduction and Terminology

1. 序論と用語

   This document defines a "Bit-String Label" which may appear within
   domain names.  This new label type compactly represents a sequence of
   "One-Bit Labels" and enables resource records to be stored at any
   bit-boundary in a binary-named section of the domain name tree.

このドキュメントはドメイン名の中に現れるかもしれない「ビット列ラベル」を定義します。 この新しいラベル形式は、コンパクトに「1ビットのラベル」の系列を表して、リソース記録がドメイン名木のバイナリーで命名されたセクションのどんなビット境界にも格納されるのを可能にします。

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [KWORD].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[KWORD]で説明されるように本書では解釈されることであるべきですか?

2.  Motivation

2. 動機

   Binary labels are intended to efficiently solve the problem of
   storing data and delegating authority on arbitrary boundaries when
   the structure of underlying name space is most naturally represented
   in binary.

2進のラベルが効率的に、基本的な名前スペースの構造がバイナリーで最も自然に表されるとき、任意の境界でデータを格納して、権限を委ねるという問題を解決することを意図します。

3.  Label Format

3. ラベル形式

   Up to 256 One-Bit Labels can be grouped into a single Bit-String
   Label.  Within a Bit-String Label the most significant or "highest
   level" bit appears first.  This is unlike the ordering of DNS labels
   themselves, which has the least significant or "lowest level" label
   first.  Nonetheless, this ordering seems to be the most natural and
   efficient for representing binary labels.

最大256One-ビットLabelsを独身のBit-ストリングLabelに分類できます。 中に、Bit-ストリングのLabelの最も重要であるか「最高水準」ビットは最初に、見えます。 これはラベル自体、どれが最少を重要にするか、そして、または「最も低いレベル」が最初にラベルするDNSの注文と異なっています。 それにもかかわらず、この注文は2進のラベルを表すのに最も自然であって、効率的であるように思えます。

Crawford                    Standards Track                     [Page 1]

RFC 2673        Binary Labels in the Domain Name System      August 1999

RFC2673バイナリーが1999年8月にドメインネームシステムでラベルするクロフォード標準化過程[1ページ]

   Among consecutive Bit-String Labels, the bits in the first-appearing
   label are less significant or "at a lower level" than the bits in
   subsequent Bit-String Labels, just as ASCII labels are ordered.

その後のBit-ストリングLabelsのビットより連続したBit-ストリングLabelsの中ではそれほど重要でないか、または「下のレベル」で最初に現れているラベルのビット、ちょうどASCIIラベルが注文されるように。

3.1.  Encoding

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 ...         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+

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| カウント| ラベルします。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+

   (Each tic mark represents one bit.)

(それぞれのチックマークは1ビットを表します。)

   ELT       000001 binary, the six-bit extended label type [EDNS0]
             assigned to the Bit-String Label.

ELT000001バイナリー、Bit-ストリングLabelに割り当てられた6ビットの拡張ラベル形式[EDNS0]。

   Count     The number of significant bits in the Label field.  A Count
             value of zero indicates that 256 bits are significant.
             (Thus the null label representing the DNS root cannot be
             represented as a Bit String Label.)

Label分野の重要なビットの数を数えてください。 ゼロのCount値は、256ビットが重要であることを示します。 (その結果、Bit String LabelとしてDNS根を表すヌルラベルは表すことができません。)

   Label     The bit string representing a sequence of One-Bit Labels,
             with the most significant bit first.  That is, the One-Bit
             Label in position 17 in the diagram above represents a
             subdomain of the domain represented by the One-Bit Label in
             position 16, and so on.

最初に最も重要なビットでOne-ビットLabelsの系列を表すビット列をラベルしてください。 上のダイヤグラムによる位置17のすなわち、One-ビットLabelはOne-ビットLabelによって位置16、などに表されたドメインに関するサブドメインを表します。

             The Label field is padded on the right with zero to seven
             pad bits to make the entire field occupy an integral number
             of octets.  These pad bits MUST be zero on transmission and
             ignored on reception.

Label分野は右でゼロ〜7パッドビットで水増しされて、全体の分野に整数の八重奏を占領させます。 これらのパッドビットはトランスミッションであってレセプションで無視されるところのゼロであるに違いありません。

   A sequence of bits may be split into two or more Bit-String Labels,
   but the division points have no significance and need not be
   preserved.  An excessively clever server implementation might split
   Bit-String Labels so as to maximize the effectiveness of message
   compression [DNSIS].  A simpler server might divide Bit-String Labels
   at zone boundaries, if any zone boundaries happen to fall between
   One-Bit Labels.

ビットの系列が2Bit-ストリングLabelsに分けられるかもしれませんが、分割ポイントは、意味を全く持たないで、保持される必要はありません。 過度に賢明なサーバ実現は、メッセージ圧縮[DNSIS]の有効性を最大にするためにBit-ストリングLabelsを分割するかもしれません。 どれかゾーン境界がOne-ビットLabelsの間でたまたま低下するなら、より簡単なサーバはゾーン境界でBit-ストリングLabelsを分割するかもしれません。

3.2.  Textual Representation

3.2. 原文の表現

   A Bit-String Label is represented in text -- in a zone file, for
   example -- as a <bit-spec> surrounded by the delimiters "\[" and "]".
   The <bit-spec> is either a dotted quad or a base indicator and a
   sequence of digits appropriate to that base, optionally followed by a

そして、「例えば、Bit-ストリングLabelは>がデリミタで囲んだ<ビット仕様としてテキスト、ゾーンファイルに表され」\、[「」、]、」 <ビット仕様>は点を打たされた回路かベースインディケータのどちらかとそのベースに適切で、aが任意にあとに続くケタの系列です。

Crawford                    Standards Track                     [Page 2]

RFC 2673        Binary Labels in the Domain Name System      August 1999

RFC2673バイナリーが1999年8月にドメインネームシステムでラベルするクロフォード標準化過程[2ページ]

   slash and a length.  The base indicators are "b", "o" and "x",
   denoting base 2, 8 and 16 respectively.  The length counts the
   significant bits and MUST be between 1 and 32, inclusive, after a
   dotted quad, or between 1 and 256, inclusive, after one of the other
   forms.  If the length is omitted, the implicit length is 32 for a
   dotted quad or 1, 3 or 4 times the number of binary, octal or
   hexadecimal digits supplied, respectively, for the other forms.

スラッシュと長さ。 それぞれベース2、8、および16を指示して、ベースインディケータは、「b」と、「o」と「x」です。 長さは、1〜重要なビットを数えて、32であるに違いありません、包括的です、1〜点を打たされた回路、または256の後に、包括的です、他のフォームの1つの後に。長さが省略されるなら、暗黙の長さはそれぞれ他のフォームに供給された数の点を打たされた回路か1倍か3倍か4倍のバイナリー、8進または16進数字のための32です。

   In augmented Backus-Naur form [ABNF],

中では、BN記法[ABNF]は増大しました。

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

「噛み付いているストリングラベルは」 \[「ビット仕様」]と等しいです」

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

点を打たされたビット仕様=ビット・データ[「/」の長さ]/回路[「/」slength]

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

ビット・データは「x」1*64HEXDIG/「o」1*86OCTDIG/「b」1*256BITと等しいです。

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

. 」 「点を打たされた回路=は」 . 」 decbyteをdecbyteする」decbyte、」 . 」 decbyte

     decbyte          =  1*3DIGIT

decbyteは1*3DIGITと等しいです。

     length           =  NZDIGIT *2DIGIT

長さはNZDIGIT*2DIGITと等しいです。

     slength          =  NZDIGIT [ DIGIT ]

slengthはNZDIGITと等しいです。[ケタ]

     OCTDIG           =  %x30-37

OCTDIG=%x30-37

     NZDIGIT          =  %x31-39

NZDIGIT=%x31-39

   If a <length> is present, the number of digits in the <bit-data> MUST
   be just sufficient to contain the number of bits specified by the
   <length>.  If there are insignificant bits in a final hexadecimal or
   octal digit, they MUST be zero.  A <dotted-quad> always has all four
   parts even if the associated <slength> is less than 24, but, like the
   other forms, insignificant bits MUST be zero.

<長さの>が存在しているなら、<ビット・データ>のケタの数は、<の長さの>によって指定されたビットの数を含むようにただ十分でなければなりません。 最終的な16進か8進数字にわずかなビットがあれば、それらはゼロであるに違いありません。 <の点を打たされた回路の>には、すべての4つの部品が関連<slength>が24未満であってもいつもありますが、他のフォームのように、わずかなビットはゼロであるに違いありません。

   Each number represented by a <decbyte> must be between 0 and 255,
   inclusive.

<decbyte>によって表された各数が0と255の間あるに違いありません。包括的。

   The number represented by <length> must be between 1 and 256
   inclusive.

1〜256が包括的であったなら、<の長さの>によって表された数はそうしなければなりません。

   The number represented by <slength> must be between 1 and 32
   inclusive.

1〜32が包括的であったなら、<slength>によって表された数はそうしなければなりません。

Crawford                    Standards Track                     [Page 3]

RFC 2673        Binary Labels in the Domain Name System      August 1999

RFC2673バイナリーが1999年8月にドメインネームシステムでラベルするクロフォード標準化過程[3ページ]

   When the textual form of a Bit-String Label is generated by machine,
   the length SHOULD be explicit, not implicit.

Bit-ストリングの原文のフォームであるときに、マシン、長さのSHOULDによって、Labelを発生させます。暗黙であるのではなく明白であってください。

3.2.1.  Examples

3.2.1. 例

   The following four textual forms represent the same Bit-String Label.

以下の4つの原文のフォームが同じBit-ストリングLabelを表します。

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

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

   The following represents two consecutive Bit-String Labels which
   denote the same relative point in the DNS tree as any of the above
   single Bit-String Labels.

以下は上の独身のBit-ストリングLabelsのいずれとしてもDNS木で同じ相対的なポイントを指示する2連続したBit-ストリングLabelsを表します。

                             \[b11101].\[o640]

\[b11101]\[o640]

3.3.  Canonical Representation and Sort Order

3.3. 正準な表現とソート順序

   Both the wire form and the text form of binary labels have a degree
   of flexibility in their grouping into multiple consecutive Bit-String
   Labels.  For generating and checking DNS signature records [DNSSEC]
   binary labels must be in a predictable form.  This canonical form is
   defined as the form which has the fewest possible Bit-String Labels
   and in which all except possibly the first (least significant) label
   in any sequence of consecutive Bit-String Labels is of maximum
   length.

それらが複数の連続したBit-ストリングLabelsに分類する際にワイヤフォームと2進のラベルのテキストフォームの両方が1段階の柔軟性を持っています。 DNS署名記録[DNSSEC]を発生して、チェックするために、2進のラベルは予測できるフォームにあるに違いありません。 この標準形は最もわずかな可能なBit-ストリングLabelsを持って、ことによると連続したBit-ストリングLabelsのどんな系列でも最初に(最も重要でない)のラベル以外のすべてが最大の長さのものであるフォームと定義されます。

   For example, the canonical form of any sequence of up to 256 One-Bit
   Labels has a single Bit-String Label, and the canonical form of a
   sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of
   which the second and third contain 256 label bits.

例えば、最大256One-ビットLabelsのどんな系列の標準形ではも独身のBit-ストリングLabelがあります、そして、513〜768One-ビットLabelsの系列の標準形には、2番目と3番目がそれのLabelsを256ラベルビット含む3Bit-ストリングがあります。

   The canonical sort order of domain names [DNSSEC] is extended to
   encompass binary labels as follows.  Sorting is still label-by-label,
   from most to least significant, where a label may now be a One-Bit
   Label or a standard (code 00) label.  Any One-Bit Label sorts before
   any standard label, and a 0 bit sorts before a 1 bit.  The absence of
   a label sorts before any label, as specified in [DNSSEC].

ドメイン名[DNSSEC]の正準なソート順序は、以下の2進のラベルを取り囲むために広げられます。 まだソーティングがラベルであることごとに大部分から最も重要にならないまで、現在ラベルがOne-ビットLabelか標準(コード00)のラベルであるかもしれないところで。 どんなOne-ビットLabelも以前、どんな標準ラベル、および0ビット前でも種類を1ビット分類します。 どんな前の種類も[DNSSEC]で指定されるようにラベルするラベルの不在。

Crawford                    Standards Track                     [Page 4]

RFC 2673        Binary Labels in the Domain Name System      August 1999

RFC2673バイナリーが1999年8月にドメインネームシステムでラベルするクロフォード標準化過程[4ページ]

   For example, the following domain names are correctly sorted.

例えば、以下のドメイン名は正しく分類されます。

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

foo.example\[b1].foo.example\[b100].foo.example\[b101].foo.example喝采の叫び\[b10].foo.example alpha.foo.example

4.  Processing Rules

4. 処理規則

   A One-Bit Label never matches any other kind of label.  In
   particular, the DNS labels represented by the single ASCII characters
   "0" and "1" do not match One-Bit Labels represented by the bit values
   0 and 1.

A One-ビットLabelはいかなる他の種類のラベルにも決して合っていません。 特に、DNSラベルが単独のASCII文字で表した、「0インチと「1インチはビット値0と1によって表された1ビットのラベルに合いません」。

5.  Discussion

5. 議論

   A Count of zero in the wire-form represents a 256-bit sequence, not
   to optimize that particular case, but to make it completely
   impossible to have a zero-bit label.

ワイヤフォームでのゼロのCountは、その特定のケースを最適化するのではなく、無ビットラベルを持っているのを完全に不可能にするように256ビットの系列を表します。

6.  IANA Considerations

6. IANA問題

   This document defines one Extended Label Type, termed the Bit-String
   Label, and requests registration of the code point 000001 binary in
   the space defined by [EDNS0].

このドキュメントはBit-ストリングLabelと呼ばれた、1Extended Label Type、およびスペースでのコード・ポイント000001バイナリーの登録が[EDNS0]で定義した要求を定義します。

7.  Security Considerations

7. セキュリティ問題

   All security considerations which apply to traditional ASCII DNS
   labels apply equally to binary labels.  he canonicalization and
   sorting rules of section 3.3 allow these to be addressed by DNS
   Security [DNSSEC].

伝統的なASCII DNSラベルに適用されるすべてのセキュリティ問題が等しく2進のラベルに適用される、彼、セクション3.3のcanonicalizationとソーティング規則は、これらがDNS Security[DNSSEC]によって記述されるのを許容します。

Crawford                    Standards Track                     [Page 5]

RFC 2673        Binary Labels in the Domain Name System      August 1999

RFC2673バイナリーが1999年8月にドメインネームシステムでラベルするクロフォード標準化過程[5ページ]

8.  References

8. 参照

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

[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。

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

[DNSIS]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日

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

[DNSSEC] イーストレーク、D.、3番目、C.コーフマン、「ドメインネームシステムセキュリティ拡大」、RFC2065、1997年1月

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

[EDNS0] Vixie、P.、「DNS(EDNS0)のための拡大メカニズム」、RFC2671、1999年8月。

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

[KWORD] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

9.  Author's Address

9. 作者のアドレス

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

バタビア、マットクロフォードフェルミ国立加速研究所MS368私書箱500イリノイ60510米国

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

以下に電話をしてください。 +1 630 840-3461 メールしてください: crawdad@fnal.gov

Crawford                    Standards Track                     [Page 6]

RFC 2673        Binary Labels in the Domain Name System      August 1999

RFC2673バイナリーが1999年8月にドメインネームシステムでラベルするクロフォード標準化過程[6ページ]

10.  Full Copyright Statement

10. 完全な著作権宣言文

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

Copyright(C)インターネット協会(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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Crawford                    Standards Track                     [Page 7]

クロフォード標準化過程[7ページ]