RFC4343 日本語訳

Network Working Group                                    D. Eastlake 3rd
Request for Comments: 4343                         Motorola Laboratories
Updates: 1034, 1035, 2181                                   January 2006
Category: Standards Track

コメントを求めるワーキンググループのD.イーストレーク第3要求をネットワークでつないでください: 4343のモトローラ研究所アップデート: 1035、2181 1034、年2006年1月のカテゴリ: 標準化過程

       Domain Name System (DNS) Case Insensitivity Clarification

ドメインネームシステム(DNS)大文字小文字の同一視明確化

Status of This 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 (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   Domain Name System (DNS) names are "case insensitive".  This document
   explains exactly what that means and provides a clear specification
   of the rules.  This clarification updates RFCs 1034, 1035, and 2181.

ドメインネームシステム(DNS)名は「大文字と小文字を区別しないです」。 このドキュメントは、それがまさに何を意味するかを説明して、規則の明確な仕様を前提とします。 この明確化はRFCs1034、1035、および2181をアップデートします。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Case Insensitivity of DNS Labels ................................2
      2.1. Escaping Unusual DNS Label Octets ..........................2
      2.2. Example Labels with Escapes ................................3
   3. Name Lookup, Label Types, and CLASS .............................3
      3.1. Original DNS Label Types ...................................4
      3.2. Extended Label Type Case Insensitivity Considerations ......4
      3.3. CLASS Case Insensitivity Considerations ....................4
   4. Case on Input and Output ........................................5
      4.1. DNS Output Case Preservation ...............................5
      4.2. DNS Input Case Preservation ................................5
   5. Internationalized Domain Names ..................................6
   6. Security Considerations .........................................6
   7. Acknowledgements ................................................7
   Normative References................................................7
   Informative References..............................................8

1. 序論…2 2. DNSラベルの大文字小文字の同一視…2 2.1. エスケープの珍しいDNSは八重奏をラベルします…2 2.2. ミッドナイト・ゾーンがある例のラベル…3 3. ルックアップ、ラベル形式、およびクラスを命名してください…3 3.1. オリジナルのDNSはタイプにレッテルを貼ります…4 3.2. ラベル形式大文字小文字の同一視問題を広げています…4 3.3. クラス大文字小文字の同一視問題…4 4. 入出力のときに、ケースに入れます。5 4.1. DNSはケース保存を出力しました…5 4.2. DNSはケース保存を入力しました…5 5. 国際化ドメイン名…6 6. セキュリティ問題…6 7. 承認…7 標準の参照…7 有益な参照…8

Eastlake 3rd                Standards Track                     [Page 1]

RFC 4343          DNS Case Insensitivity Clarification      January 2006

イーストレーク第3規格はDNS大文字小文字の同一視明確化2006年1月にRFC4343を追跡します[1ページ]。

1.  Introduction

1. 序論

   The Domain Name System (DNS) is the global hierarchical replicated
   distributed database system for Internet addressing, mail proxy, and
   other information.  Each node in the DNS tree has a name consisting
   of zero or more labels [STD13, RFC1591, RFC2606] that are treated in
   a case insensitive fashion.  This document clarifies the meaning of
   "case insensitive" for the DNS.  This clarification updates RFCs
   1034, 1035 [STD13], and [RFC2181].

ドメインネームシステム(DNS)はインターネットアドレシング、メールプロキシ、および他の情報のグローバルな階層的な模写された分散データベースシステムです。 DNS木の各ノードは大文字と小文字を区別しないファッションで扱われるゼロから成る名前か、より多くのラベル[STD13、RFC1591、RFC2606]を持っています。 このドキュメントはDNSに「大文字と小文字を区別しないこと」の意味をはっきりさせます。 この明確化はRFCs1034、1035[STD13]、および[RFC2181]をアップデートします。

   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 [RFC2119].

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

2.  Case Insensitivity of DNS Labels

2. DNSラベルの大文字小文字の同一視

   DNS was specified in the era of [ASCII].  DNS names were expected to
   look like most host names or Internet email address right halves (the
   part after the at-sign, "@") or to be numeric, as in the in-addr.arpa
   part of the DNS name space.  For example,

DNSは[ASCII]の時代で指定されました。 ほとんどのホスト名やインターネットEメールアドレスのように正しい半分(サインだったことの後の部分、"@")を見るか、またはDNS名が数値であると予想されました、addr.arpaのスペースというDNS名の部分のように。 例えば

       foo.example.net.
       aol.com.
       www.gnu.ai.mit.edu.
   or  69.2.0.192.in-addr.arpa.

foo.example.net. aol.com. www.gnu.ai.mit.edu69.2.0.192.in-addr.arpa。

   Case-varied alternatives to the above [RFC3092] would be DNS names
   like

DNS名が同様であったように上の[RFC3092]へのケースで様々な代替手段はそうするでしょう。

       Foo.ExamplE.net.
       AOL.COM.
       WWW.gnu.AI.mit.EDU.
   or  69.2.0.192.in-ADDR.ARPA.

Foo.ExamplE.net。 AOL.COM。 WWW.gnu.AI.mit.EDU69.2.0.192.in-ADDR.ARPA。

   However, the individual octets of which DNS names consist are not
   limited to valid ASCII character codes.  They are 8-bit bytes, and
   all values are allowed.  Many applications, however, interpret them
   as ASCII characters.

しかしながら、DNS名が成る個々の八重奏は有効なASCII文字コードに制限されません。 それらは8ビットのバイトです、そして、すべての値が許容されています。 しかしながら、多くのアプリケーションがASCII文字としてそれらを解釈します。

2.1.  Escaping Unusual DNS Label Octets

2.1. 珍しいDNSラベル八重奏から逃げます。

   In Master Files [STD13] and other human-readable and -writable ASCII
   contexts, an escape is needed for the byte value for period (0x2E,
   ".") and all octet values outside of the inclusive range from 0x21
   ("!") to 0x7E ("~").  That is to say, 0x2E and all octet values in
   the two inclusive ranges from 0x00 to 0x20 and from 0x7F to 0xFF.

「Master Files[STD13]と他の人間読み込み可能で書き込み可能なASCII文脈では、エスケープが期間のためのバイト値に必要である、(0x2E、」、」、)、そして、八重奏が包括的な0×21(“!")から0x7E(「~」)までの範囲の外で評価するすべて。 すなわち、0x2Eと2つの包括的な0×00から0×20まで0x7Fから0xFFまでの範囲のすべての八重奏値。

Eastlake 3rd                Standards Track                     [Page 2]

RFC 4343          DNS Case Insensitivity Clarification      January 2006

イーストレーク第3規格はDNS大文字小文字の同一視明確化2006年1月にRFC4343を追跡します[2ページ]。

   One typographic convention for octets that do not correspond to an
   ASCII printing graphic is to use a back-slash followed by the value
   of the octet as an unsigned integer represented by exactly three
   decimal digits.

ASCII印刷グラフィックと食い違っている八重奏のための1つの印刷のコンベンションがバックスラッシュを使用することになっています、続いて、まさに3つの10進数字によって表された符号のない整数として八重奏の値を使用します。

   The same convention can be used for printing ASCII characters so that
   they will be treated as a normal label character.  This includes the
   back-slash character used in this convention itself, which can be
   expressed as %%BODY%%92 or \\, and the special label separator period
   ("."), which can be expressed as and %%BODY%%46 or \.  It is advisable to
   avoid using a backslash to quote an immediately following non-
   printing ASCII character code to avoid implementation difficulties.

彼らが普通のラベルキャラクタとして扱われて、印刷ASCII文字に同じコンベンションを使用できます。 これが092円か\円として言い表すことができるこのコンベンション自体に使用されるバックスラッシュキャラクタと特別なラベル分離符の期間を含んでいる、(「」、)、実装困難を避けるためにすぐに次の非印刷しているASCII文字コードを引用するのにバックスラッシュを使用するのを避けるのにおいて\同じくらいそして、どれを046円言い表すことができるか、そして、それが賢明です。

   A back-slash followed by only one or two decimal digits is undefined.
   A back-slash followed by four decimal digits produces two octets, the
   first octet having the value of the first three digits considered as
   a decimal number, and the second octet being the character code for
   the fourth decimal digit.

1か2つの10進数字だけがあとに続いたバックスラッシュは未定義です。 4つの10進数字があとに続いたバックスラッシュは2つの八重奏(10進数と、4番目の10進数字のためのキャラクタコードである2番目の八重奏であると最初の3ケタの値をみなす最初の八重奏)を起こします。

2.2.  Example Labels with Escapes

2.2. ミッドナイト・ゾーンがある例のラベル

   The first example below shows embedded spaces and a period (".")
   within a label.  The second one shows a 5-octet label where the
   second octet has all bits zero, the third is a backslash, and the
   fourth octet has all bits one.

ショーの下における最初の例が空間と期間を埋め込んだ、(「」、)、ラベルの中に。 2番目の人は、2番目の八重奏がどこにビットが合っているゼロすべてを持っているかを5八重奏のラベルに示します、そして、3番目はバックスラッシュです、そして、4番目の八重奏には、すべてのビット1があります。

         Donald%%BODY%%32E\.%%BODY%%32Eastlake%%BODY%%323rd.example.
   and   a%%BODY%%00\\\255z.example.

ドナルド032円E\%%BODY%%32Eastlake\323番目の.example a000円\\\255z.、例。

3.  Name Lookup, Label Types, and CLASS

3. 名前ルックアップ、ラベル形式、およびクラス

   According to the original DNS design decision, comparisons on name
   lookup for DNS queries should be case insensitive [STD13].  That is
   to say, a lookup string octet with a value in the inclusive range
   from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the
   identical value and also match the corresponding value in the
   inclusive range from 0x61 to 0x7A, the lowercase ASCII letters.  A
   lookup string octet with a lowercase ASCII letter value MUST
   similarly match the identical value and also match the corresponding
   value in the uppercase ASCII letter range.

オリジナルのDNSデザイン決定によると、DNS質問のための名前ルックアップにおける比較は大文字と小文字を区別しないはずです[STD13]。 すなわち、値が包括的な0×41から0x5Aまでの範囲にあるルックアップストリング八重奏(大文字しているASCII手紙)は、同じ値を合わせて、また、包括的な0×61から0x7A(小文字のASCII手紙)までの範囲で換算値に合わなければなりません。 小文字のASCII手紙価値があるルックアップストリング八重奏は、同様に同じ値を合わせて、また、大文字しているASCII手紙範囲で換算値に合わなければなりません。

   (Historical note: The terms "uppercase" and "lowercase" were invented
   after movable type.  The terms originally referred to the two font
   trays for storing, in partitioned areas, the different physical type
   elements.  Before movable type, the nearest equivalent terms were
   "majuscule" and "minuscule".)

(歴史的な注意: 「大文字し」て、「小文字で印刷する」という用語は組み替え可能な活字の後に発明されました。 用語は元々、仕切られた領域に異なった物理的なタイプ・エレメントを保存するための2個のフォントトレーについて言及しました。 組み替え可能な活字の前では、最も近い同義語は、「大文字」で「小さかったです」。)

Eastlake 3rd                Standards Track                     [Page 3]

RFC 4343          DNS Case Insensitivity Clarification      January 2006

イーストレーク第3規格はDNS大文字小文字の同一視明確化2006年1月にRFC4343を追跡します[3ページ]。

   One way to implement this rule would be to subtract 0x20 from all
   octets in the inclusive range from 0x61 to 0x7A before comparing
   octets.  Such an operation is commonly known as "case folding", but
   implementation via case folding is not required.  Note that the DNS
   case insensitivity does NOT correspond to the case folding specified
   in [ISO-8859-1] or [ISO-8859-2].  For example, the octets 0xDD (\221)
   and 0xFD (\253) do NOT match, although in other contexts, where they
   are interpreted as the upper- and lower-case version of "Y" with an
   acute accent, they might.

この規則を実装する1つの方法は八重奏を比較する前に包括的な0×61から0x7Aまでの範囲ですべての八重奏から0×20を引き算するだろうことです。 そのような操作は「ケースの折り重なり」として一般的に知られていますが、ケースの折り重なりを通した実装は必要ではありません。 DNS大文字小文字の同一視が[ISO-8859-1]か[ISO-8859-2]で指定されたケースの折り重なりに対応しないことに注意してください。 例えば、八重奏の0xDD(221円)と0xFD(253円)は合っていません、他の文脈、それらがどこで、より上側であると解釈されるか、そして、および鋭アクセントがある「Y」の小文字のバージョンでそうするかもしれませんが。

3.1.  Original DNS Label Types

3.1. オリジナルのDNSラベル形式

   DNS labels in wire-encoded names have a type associated with them.
   The original DNS standard [STD13] had only two types: ASCII labels,
   with a length from zero to 63 octets, and indirect (or compression)
   labels, which consist of an offset pointer to a name location
   elsewhere in the wire encoding on a DNS message.  (The ASCII label of
   length zero is reserved for use as the name of the root node of the
   name tree.)  ASCII labels follow the ASCII case conventions described
   herein and, as stated above, can actually contain arbitrary byte
   values.  Indirect labels are, in effect, replaced by the name to
   which they point, which is then treated with the case insensitivity
   rules in this document.

ワイヤでコード化された名前のDNSラベルには、それらに関連しているタイプがあります。 元のDNS規格[STD13]に、2つのタイプしかありませんでした: オフセット指針から成るゼロ〜63の八重奏、および間接的な(または、圧縮)ラベルからDNSメッセージでのワイヤコード化におけるほかの場所の名前位置までの長さがあるASCIIラベル。 (長さゼロのASCIIラベルは使用のために木という名前の根のノードの名前として予約されます。) 上で述べられるとして、ASCIIラベルは、ここに説明されたASCIIケースコンベンションに続いて、実際に任意のバイト値を含むことができます。 事実上、間接的なラベルをそれらが指す名前に取り替えて、次に、どれが大文字小文字の同一視で扱われるかは本書では統治されます。

3.2.  Extended Label Type Case Insensitivity Considerations

3.2. 拡張ラベル形式大文字小文字の同一視問題

   DNS was extended by [RFC2671] so that additional label type numbers
   would be available.  (The only such type defined so far is the BINARY
   type [RFC2673], which is now Experimental [RFC3363].)

DNSは、追加ラベル形式数が有効であるように、[RFC2671]によって広げられました。 (そのようなタイプが今までのところ定義した唯一は現在Experimental[RFC3363]であるBINARYタイプ[RFC2673]です。)

   The ASCII case insensitivity conventions only apply to ASCII labels;
   that is to say, label type 0x0, whether appearing directly or invoked
   by indirect labels.

ASCII大文字小文字の同一視コンベンションはASCIIラベルに適用されるだけです。 すなわち、直接現れるか、または間接的なラベルによって呼び出されることにかかわらずタイプ0x0にレッテルを貼ってください。

3.3.  CLASS Case Insensitivity Considerations

3.3. クラス大文字小文字の同一視問題

   As described in [STD13] and [RFC2929], DNS has an additional axis for
   data location called CLASS.  The only CLASS in global use at this
   time is the "IN" (Internet) CLASS.

[STD13]と[RFC2929]で説明されるように、DNSにはCLASSと呼ばれるデータ位置への追加軸があります。 今回のグローバルな使用における唯一のCLASSが「IN」(インターネット)のクラスです。

   The handling of DNS label case is not CLASS dependent.  With the
   original design of DNS, it was intended that a recursive DNS resolver
   be able to handle new CLASSes that were unknown at the time of its
   implementation.  This requires uniform handling of label case
   insensitivity.  Should it become desirable, for example, to allocate
   a CLASS with "case sensitive ASCII labels", it would be necessary to
   allocate a new label type for these labels.

DNSラベルケースの取り扱いはCLASS扶養家族ではありません。 DNSの当初の設計で、再帰的なDNSレゾルバが実装時点で未知である新しいCLASSesを扱うことができることを意図しました。 これはラベル大文字小文字の同一視の一定の取り扱いを必要とします。 「大文字と小文字を区別するASCIIラベル」に応じて例えば、CLASSを割り当てるのにおいて望ましくなるなら、これらのラベルのために新しいラベル形式を割り当てるのが必要でしょう。

Eastlake 3rd                Standards Track                     [Page 4]

RFC 4343          DNS Case Insensitivity Clarification      January 2006

イーストレーク第3規格はDNS大文字小文字の同一視明確化2006年1月にRFC4343を追跡します[4ページ]。

4.  Case on Input and Output

4. 入出力でのケース

   While ASCII label comparisons are case insensitive, [STD13] says case
   MUST be preserved on output and preserved when convenient on input.
   However, this means less than it would appear, since the preservation
   of case on output is NOT required when output is optimized by the use
   of indirect labels, as explained below.

ASCIIラベル比較は大文字と小文字を区別しないのですが、[STD13]は入力のときに便利であるときに、ケースを出力のときに保存されて、保存しなければならないと言います。 しかしながら、これは現れるだろうより少ないことを意味します、出力が間接的なラベルの使用で最適化されるとき、出力のケースの保存が必要でないので、以下で説明されるように。

4.1.  DNS Output Case Preservation

4.1. DNS出力ケース保存

   [STD13] views the DNS namespace as a node tree.  ASCII output is as
   if a name were marshaled by taking the label on the node whose name
   is to be output, converting it to a typographically encoded ASCII
   string, walking up the tree outputting each label encountered, and
   preceding all labels but the first with a period (".").  Wire output
   follows the same sequence, but each label is wire encoded, and no
   periods are inserted.  No "case conversion" or "case folding" is done
   during such output operations, thus "preserving" case.  However, to
   optimize output, indirect labels may be used to point to names
   elsewhere in the DNS answer.  In determining whether the name to be
   pointed to (for example, the QNAME) is the "same" as the remainder of
   the name being optimized, the case insensitive comparison specified
   above is done.  Thus, such optimization may easily destroy the output
   preservation of case.  This type of optimization is commonly called
   "name compression".

[STD13]はDNS名前空間をノードツリーであるとみなします。 ASCII出力がまるで名前が取りながら整理されるかのように、名前がことである出力である各ラベルを出力しながら木を歩いて、印刷上でコード化されたASCIIストリングにそれを変換して、ノードの上のラベルが期間ですべてのラベルに先行して、遭遇して、1番目に先行したということである、(「」、)。 各ラベルはコード化されたワイヤです、そして、ワイヤ出力は同じ順序に従いますが、期間は全く挿入されません。 そのような出力操作の間、「ケース変換」かどんな「ケースの折り重なり」もしても、その結果、ケースを「保存しません」。 しかしながら、出力を最適化するなら、間接的なラベルは、DNS答えにおけるほかの場所に名前を示すのに使用されるかもしれません。 最適化されていて、向けられる名前(例えば、QNAME)が名前の残りへの「同じこと」であるかどうか決定する際に、上で指定された大文字と小文字を区別しない比較をします。 したがって、そのような最適化は容易にケースの出力保存を破壊するかもしれません。 このタイプの最適化は一般的に「名前圧縮」と呼ばれます。

4.2.  DNS Input Case Preservation

4.2. DNS入力ケース保存

   Originally, DNS data came from an ASCII Master File as defined in
   [STD13] or a zone transfer.  DNS Dynamic update and incremental zone
   transfers [RFC1995] have been added as a source of DNS data [RFC2136,
   RFC3007].  When a node in the DNS name tree is created by any of such
   inputs, no case conversion is done.  Thus, the case of ASCII labels
   is preserved if they are for nodes being created.  However, when a
   name label is input for a node that already exists in DNS data being
   held, the situation is more complex.  Implementations are free to
   retain the case first loaded for such a label, to allow new input to
   override the old case, or even to maintain separate copies preserving
   the input case.

元々、DNSデータは[STD13]かゾーン転送で定義されるようにASCII Master Fileから来ました。 DNS Dynamicアップデートと増加のゾーン転送[RFC1995]はDNSデータ[RFC2136、RFC3007]の源として加えられます。 木というDNS名のノードがそのような入力のどれかで作成されるとき、変換が完了しているのは、ケースではありません。 したがって、ASCIIラベルに関するケースはそれらが作成されるノードのためのものであるなら保存されます。 しかしながら、ネームラベルが保持されるDNSデータに既に存在するノードのために入力されるとき、状況は、より複雑です。 実装で、新しい入力は、最初にそのようなラベルのためにロードされたケースを保有して、再来患者をくつがえすか、または自由に入力ケースを保存する別々のコピーを維持さえできます。

   For example, if data with owner name "foo.bar.example" [RFC3092] is
   loaded and then later data with owner name "xyz.BAR.example" is
   input, the name of the label on the "bar.example" node (i.e., "bar")
   might or might not be changed to "BAR" in the DNS stored data.  Thus,
   later retrieval of data stored under "xyz.bar.example" in this case
   can use "xyz.BAR.example" in all returned data, use "xyz.bar.example"
   in all returned data, or even, when more than one RR is being
   returned, use a mixture of these two capitalizations.  This last case

例えば、所有者名前"foo.bar.example"[RFC3092]があるデータがロードしていて、次に、所有者名前"xyz.BAR.example"がある後のデータを入力するなら、"bar.example"ノード(すなわち、「バー」)の上のラベルの名前を変えるか、またはDNSで記憶されたデータを「禁じる」ために変えないかもしれません。 1RRを返しているとき、したがって、この場合"xyz.bar.example"の下に保存されている後のデータ検索は、すべての返されたデータで"xyz.BAR.example"を使用するか、すべての返されたデータで"xyz.bar.example"を使用するか、またはこれらの2つの資源化の混合物を使用さえできます。 この最後のケース

Eastlake 3rd                Standards Track                     [Page 5]

RFC 4343          DNS Case Insensitivity Clarification      January 2006

イーストレーク第3規格はDNS大文字小文字の同一視明確化2006年1月にRFC4343を追跡します[5ページ]。

   is unlikely, as optimization of answer length through indirect labels
   tends to cause only one copy of the name tail ("bar.example" or
   "BAR.example") to be used for all returned RRs.  Note that none of
   this has any effect on the number or completeness of the RR set
   returned, only on the case of the names in the RR set returned.

ありそうもないです、間接的なラベルを通した答えの長さの最適化が、名前テール("bar.example"か"BAR.example")のあるコピーだけを引き起こす傾向があるので、すべてに使用されるのはRRsを返しました。 返されたRRセットの名前に関するケースだけの上でこのなにもRRセットの数か完全性へのどんな効果も返させないことに注意してください。

   The same considerations apply when inputting multiple data records
   with owner names differing only in case.  For example, if an "A"
   record is the first resource record stored under owner name
   "xyz.BAR.example" and then a second "A" record is stored under
   "XYZ.BAR.example", the second MAY be stored with the first (lower
   case initial label) name, the second MAY override the first so that
   only an uppercase initial label is retained, or both capitalizations
   MAY be kept in the DNS stored data.  In any case, a retrieval with
   either capitalization will retrieve all RRs with either
   capitalization.

所有者名が場合だけにおいて異なって複数のデータレコードを入力するとき、同じ問題は適用されます。 例えば、記録が所有者名の下で保存した最初のリソースが"xyz.BAR.example"であるという記録と次に1記録あたり1秒が"XYZ.BAR.example"の下に保存されるなら、2番目が最初(小文字の初期のラベル)の名前で保存されるかもしれませんか、2番目が1番目をくつがえすかもしれないので、大文字している初期のラベルだけが保有されるか、または両方の資源化はDNS記憶されたデータに保たれるかもしれません。 どのような場合でも、資源化による検索は資源化ですべてのRRsを検索するでしょう。

   Note that the order of insertion into a server database of the DNS
   name tree nodes that appear in a Master File is not defined so that
   the results of inconsistent capitalization in a Master File are
   unpredictable output capitalization.

Master Fileの無節操な資源化の結果がMaster Fileに現れるDNS名前木のノードに関するサーバデータベースへの挿入の注文を定義しないので予測できない出力資源化であることに注意してください。

5.  Internationalized Domain Names

5. 国際化ドメイン名

   A scheme has been adopted for "internationalized domain names" and
   "internationalized labels" as described in [RFC3490, RFC3454,
   RFC3491, and RFC3492].  It makes most of [UNICODE] available through
   a separate application level transformation from internationalized
   domain name to DNS domain name and from DNS domain name to
   internationalized domain name.  Any case insensitivity that
   internationalized domain names and labels have varies depending on
   the script and is handled entirely as part of the transformation
   described in [RFC3454] and [RFC3491], which should be seen for
   further details.  This is not a part of the DNS as standardized in
   STD 13.

体系は「国際化ドメイン名」と「国際化しているラベル」のために[RFC3490、RFC3454、RFC3491、およびRFC3492]で説明されるように採用されました。 それはアプリケーションの別々のレベル変換を通して国際化ドメイン名からDNSドメイン名まで利用可能な[ユニコード]とDNSからの大部分国際化ドメイン名へのドメイン名にします。 完全に変換の一部が[RFC3454]と[RFC3491](さらに詳しい明細については見られるべきである)で説明したように、国際化ドメイン名とラベルが持っているどんな大文字小文字の同一視も、スクリプトによって、異なって、扱われます。 これはSTD13で標準化されるようにDNSの一部ではありません。

6.  Security Considerations

6. セキュリティ問題

   The equivalence of certain DNS label types with case differences, as
   clarified in this document, can lead to security problems.  For
   example, a user could be confused by believing that two domain names
   differing only in case were actually different names.

本書でははっきりさせられるケース差がある、あるDNSラベル形式の等価性は警備上の問題につながることができます。例えば、場合だけにおいて異なる2つのドメイン名が実際に異なった名前であったと信じていることによって、ユーザは混乱できるでしょう。

   Furthermore, a domain name may be used in contexts other than the
   DNS.  It could be used as a case sensitive index into some database
   or file system.  Or it could be interpreted as binary data by some
   integrity or authentication code system.  These problems can usually
   be handled by using a standardized or "canonical" form of the DNS

その上、ドメイン名はDNS以外の文脈で使用されるかもしれません。 大文字と小文字を区別するインデックスとして何らかのデータベースかファイルシステムにそれを使用できました。 または、何らかの保全か認証によるバイナリ・データがシステムをコード化するとき、それを解釈できました。 通常、DNSの標準化されたか「正準な」フォームを使用することによって、これらの問題を扱うことができます。

Eastlake 3rd                Standards Track                     [Page 6]

RFC 4343          DNS Case Insensitivity Clarification      January 2006

イーストレーク第3規格はDNS大文字小文字の同一視明確化2006年1月にRFC4343を追跡します[6ページ]。

   ASCII type labels; that is, always mapping the ASCII letter value
   octets in ASCII labels to some specific pre-chosen case, either
   uppercase or lower case.  An example of a canonical form for domain
   names (and also a canonical ordering for them) appears in Section 6
   of [RFC4034].  See also [RFC3597].

ASCIIタイプラベル。 それはいつもASCIIラベルにおけるASCII手紙値の八重奏を何らかの特定のあらかじめ選ばれたケースに写像することでの大文字しているか低いそうです。 ドメイン名(そして、それらのための正準な注文も)のための標準形に関する例は[RFC4034]のセクション6に現れます。 また、[RFC3597]を見てください。

   Finally, a non-DNS name may be stored into DNS with the false
   expectation that case will always be preserved.  For example,
   although this would be quite rare, on a system with case sensitive
   email address local parts, an attempt to store two Responsible Person
   (RP) [RFC1183] records that differed only in case would probably
   produce unexpected results that might have security implications.
   That is because the entire email address, including the possibly case
   sensitive local or left-hand part, is encoded into a DNS name in a
   readable fashion where the case of some letters might be changed on
   output as described above.

最終的に、非DNS名は誤った期待でDNSとして保存されて、そのケースがいつも保存されるということであるかもしれません。 例えば、これは大文字と小文字を区別するEメールアドレス地方の部分があるシステムの上でかなりまれでしょうが、場合だけにおいて異なった2Responsible Person(RP)[RFC1183]記録を保存する試みはたぶんセキュリティ意味を持っているかもしれない予期しなかった結果を生産するでしょう。 それはことによると大文字と小文字を区別する地方の、または、左手の部分を含む全体のEメールアドレスがいくつかの手紙に関するケースが出力のときに上で説明されるように変えられるかもしれない読み込み可能なファッションでDNS名にコード化されるからです。

7.  Acknowledgements

7. 承認

   The contributions to this document by Rob Austein, Olafur
   Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
   Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
   are gratefully acknowledged.

ロブAustein、Olafurグドムンソン、ダニエル・J.アンダーソン、アラン・バーレット、マークBlanchet、ダナ、アンドレアス・グスタファソン、アンドリューMain、トーマスNarten、およびスコット・セリグマンによるこのドキュメントへの貢献は感謝して承諾されます。

Normative References

引用規格

   [ASCII]      ANSI, "USA Standard Code for Information Interchange",
                X3.4, American National Standards Institute: New York,
                1968.

[ASCII]ANSI、「米国の標準の情報交換用符号」、X3.4、American National Standards Institut: ニューヨーク、1968。

   [RFC1995]    Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
                August 1996.

[RFC1995] 太田、M.、「DNSの増加のゾーン転送」、RFC1995、1996年8月。

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

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

   [RFC2136]    Vixie, P., Thomson,  S., Rekhter, Y., and J. Bound,
                "Dynamic Updates in the Domain Name System (DNS
                UPDATE)", RFC 2136, April 1997.

Vixie、P.、トムソン、S.、Rekhter、Y.、およびJ.が縛った[RFC2136]、「ドメインネームシステムにおけるダイナミックなアップデート(DNSアップデート)」、RFC2136(1997年4月)。

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

[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。

   [RFC3007]    Wellington, B., "Secure Domain Name System (DNS) Dynamic
                Update", RFC 3007, November 2000.

[RFC3007]ウェリントン、2000年11月のB.、「安全なドメインネームシステム(DNS)ダイナミック・アップデート」RFC3007。

Eastlake 3rd                Standards Track                     [Page 7]

RFC 4343          DNS Case Insensitivity Clarification      January 2006

イーストレーク第3規格はDNS大文字小文字の同一視明確化2006年1月にRFC4343を追跡します[7ページ]。

   [RFC3597]    Gustafsson, A., "Handling of Unknown DNS Resource Record
                (RR) Types", RFC 3597, September 2003.

[RFC3597]グスタファソン、A.、「未知のDNSリソース記録(RR)タイプの取り扱い」、RFC3597、2003年9月。

   [RFC4034]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "Resource Records for the DNS Security
                Extensions", RFC 4034, March 2005.

[RFC4034] Arends、R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.が上昇したと「リソースはDNSセキュリティ拡張子のために記録します」、RFC4034、2005年3月。

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

[STD13]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

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

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

Informative References

有益な参照

   [ISO-8859-1] International Standards Organization, Standard for
                Character Encodings, Latin-1.

文字符号化、ラテン-1における、標準の[ISO-8859-1]世界規格組織。

   [ISO-8859-2] International Standards Organization, Standard for
                Character Encodings, Latin-2.

文字符号化、ラテン-2における、標準の[ISO-8859-2]世界規格組織。

   [RFC1183]    Everhart, C., Mamakos, L., Ullmann, R., and P.
                Mockapetris, "New DNS RR Definitions", RFC 1183, October
                1990.

[RFC1183] エバーハートとC.とMamakosとL.とウルマン、R.とP.Mockapetris、「新しいDNS RR定義」、RFC1183、1990年10月。

   [RFC1591]    Postel, J., "Domain Name System Structure and
                Delegation", RFC 1591, March 1994.

[RFC1591] ポステルと、J.と、「ドメインネームシステム構造と委譲」(RFC1591)は1994を行進させます。

   [RFC2606]    Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
                Names", BCP 32, RFC 2606, June 1999.

[RFC2606] イーストレーク3番目とD.とA.パニツ、「予約された最高平らなDNS名」、BCP32、RFC2606、1999年6月。

   [RFC2929]    Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
                "Domain Name System (DNS) IANA Considerations", BCP 42,
                RFC 2929, September 2000.

[RFC2929] イーストレーク3番目、D.、ブルンナー-ウィリアムズ、E.、およびB.マニング、「ドメインネームシステム(DNS)IANA問題」、BCP42、RFC2929、2000年9月。

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

[RFC2671] Vixie、P.、「DNS(EDNS0)のための拡張機能」、RFC2671、1999年8月。

   [RFC2673]    Crawford, M., "Binary Labels in the Domain Name System",
                RFC 2673, August 1999.

[RFC2673] クロフォード、M.、「ドメインネームシステムにおける2進のラベル」、RFC2673、1999年8月。

   [RFC3092]    Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology
                of "Foo"", RFC 3092, 1 April 2001.

[RFC3092]イーストレーク3番目、D.とManros、C.とE.レイモンド、「"Foo"の語源」RFC3092、2001年4月1日。

   [RFC3363]    Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
                Hain, "Representing Internet Protocol version 6 (IPv6)
                Addresses in the Domain Name System (DNS)", RFC 3363,
                August 2002.

[RFC3363] ブッシュ、R.、ジュランド、A.、Fink、B.、グドムンソン、O.、およびT.ハイン、「インターネットプロトコルバージョン6(IPv6)を表すと、(DNS)はドメインネームシステムで扱われます」、RFC3363、2002年8月。

Eastlake 3rd                Standards Track                     [Page 8]

RFC 4343          DNS Case Insensitivity Clarification      January 2006

イーストレーク第3規格はDNS大文字小文字の同一視明確化2006年1月にRFC4343を追跡します[8ページ]。

   [RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
                Internationalized Strings ("stringprep")", RFC 3454,
                December 2002.

[RFC3454] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、2002年12月。

   [RFC3490]    Faltstrom, P., Hoffman, P., and A. Costello,
                "Internationalizing Domain Names in Applications
                (IDNA)", RFC 3490, March 2003.

[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。

   [RFC3491]    Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
                Profile for Internationalized Domain Names (IDN)", RFC
                3491, March 2003.

[RFC3491] ホフマン、P.、およびM.Blanchet、「Nameprep:」 「国際化ドメイン名(IDN)のためのStringprepプロフィール」、RFC3491、2003年3月。

   [RFC3492]    Costello, A., "Punycode: A Bootstring encoding of
                Unicode for Internationalized Domain Names in
                Applications (IDNA)", RFC 3492, March 2003.

[RFC3492]コステロ、A.、「Punycode:」 「Applications(IDNA)のInternationalized Domain Namesのためにユニコードをコード化するBootstring」、RFC3492、2003年3月。

   [UNICODE]    The Unicode Consortium, "The Unicode Standard",
                <http://www.unicode.org/unicode/standard/standard.html>.

[ユニコード] ユニコード共同体、「ユニコード規格」、<http://www.unicode.org/ユニコード/規格/standard.html>。

Author's Address

作者のアドレス

   Donald E. Eastlake 3rd
   Motorola Laboratories
   155 Beaver Street
   Milford, MA 01757 USA

ドナルドE.イーストレーク第3モトローラ研究所155ビーバー通りMA01757ミルフォード(米国)

   Phone: +1 508-786-7554 (w)
   EMail: Donald.Eastlake@motorola.com

以下に電話をしてください。 +1 508-786-7554 (w) メールしてください: Donald.Eastlake@motorola.com

Eastlake 3rd                Standards Track                     [Page 9]

RFC 4343          DNS Case Insensitivity Clarification      January 2006

イーストレーク第3規格はDNS大文字小文字の同一視明確化2006年1月にRFC4343を追跡します[9ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Eastlake 3rd                Standards Track                    [Page 10]

イーストレーク第3標準化過程[10ページ]