Network Working Group D. Eastlake 3rd
Request for Comments: 4343 Motorola Laboratories
Updates: 1034, 1035, 2181 January 2006
Category: Standards Track
Domain Name System (DNS) Case Insensitivity Clarification
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（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）名は「大文字小文字を区別しない」です。この文書では、それは意味とルールの明確な仕様を提供して正確に何を説明しています。この明確化のRFC 1034、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
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のための「大文字小文字を区別しない」の意味を明確にしています。この明確化のRFC 1034、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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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]の時代に指定されました。 DNS名は、ほとんどのホスト名またはインターネット電子メールアドレスの右半分のように見えることが予想された（一部の後にアットマーク、「@」）またはDNS名前空間のin-addr.arpa部分のように、数値であることを。例えば、
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.edu。または69.2.0.192.in-addr.arpa。
Case-varied alternatives to the above [RFC3092] would be DNS names like
上記[RFC3092]の場合、多様な選択肢のような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.EDU。または69.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文字として解釈します。
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.
0x21での包括的な範囲外のマスターファイル[STD13]と他の読める人間と-writable ASCIIコンテキストでは、エスケープが期間のためのバイト値のために必要とされる（0x2E、「 『）と、すべてのオクテット値（』！」） （ "〜"）0x7Eをします。すなわち、0x2Eとは0x00から0x20のへと0x7Fのから0xFFのには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印刷グラフィックに対応していないオクテットのための一つのタイポグラフィック規約は正確に3桁で表す符号なし整数としてオクテットの値が続くバックスラッシュを使用することです。
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 \092 or \\, and the special label separator period ("."), which can be expressed as and \046 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または\\として表すことができ、この規則自体で使用されるバックスラッシュ文字、及び特殊ラベルセパレータピリオド（「」）046または\と\のように表すことができる含みます。実装の難しさを避けるために、すぐに次の非印刷ASCII文字コードを引用するバックスラッシュの使用を避けることをお勧めします。
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進数として考え最初の3桁の値を有する最初のオクテット、及び第四十進数の文字コードである第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オクテットは全てゼロのビットを有する5オクテットのラベルを示し、そして4番目のオクテットは、すべてのビット一つを有します。
Donald\032E\.\032Eastlake\0323rd.example. and a\000\\\255z.example.
ドナルド\ 032E \。\ 032Eastlakeの\ 0323rd.example。そして、\ 000 \\\ 255z.example。
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文字は、同じ値と一致し、またの0x61から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つのフォントトレイと呼ばれる、最も近い同等の用語でした。 "majuscule" と "非常に小さいです"。）
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.
このルールを実装するための一つの方法は、オクテットを比較する前の0x61から0x7Aのに包含範囲内のすべてのオクテットからの0x20を減算することであろう。そのような操作は、一般に「ケース折り畳み」として知られているが、ケースフォールディングを介して実装が必要とされません。 DNSケース非感受性は[ISO-8859-1]または[ISO-8859-2]で指定された折り畳み場合に対応していないことに留意されたいです。それらは急性アクセントと「Y」の大文字と小文字バージョンとして解釈される他の状況においては、それらはかもしれないが、例えば、オクテット（221 \）0xDDと0xFDで（253 \）は、一致しません。
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ラベルは、それらに関連付けられた型を持っています。 ASCIIゼロ63オクテットの長さとラベル、およびDNSにワイヤエンコーディングの他の場所名の位置へのオフセットポインタから成る間接（または圧縮）ラベル、オリジナルDNS標準は[STD13] 2種類のみでしたメッセージ。 （長さゼロのASCIIラベルは、名前ツリーのルートノードの名前として使用するために予約されている。）ASCIIラベルは、実際に任意のバイト値を含むことができ、上述したようにASCIIケース規則は、本明細書に記載および以下。間接的なラベルは、実際には、この文書に記載されている場合、非感受性のルールで処理され、彼らが指し示す先の名前に置き換えています。
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]によって拡張されました。 （これまでに定義された唯一のそのようなタイプは、現在の実験的な[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の、と言うことです。
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は、データの場所と呼ばれるクラスのための追加の軸を有します。この時点でのグローバル使用中の唯一のクラスは、「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リゾルバは、その実装の時点で知られていなかった新しいクラスを扱うことができることを意図していました。これは、ラベルケース非感受性の均一な処理が必要です。それが望ましいとなるべき、例えば、「大文字と小文字を区別ASCIIラベル」を持つクラスを割り当てるために、これらのラベルのための新しいラベルタイプを割り当てることが必要であろう。
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]の場合は、入力の際に便利な出力に保存し、保存されなければならないと言います。以下に説明するように、出力は、間接的なラベルの使用によって最適化されたときに、出力の例保存が必要とされていないので、これは、それが表示されるよりも少ないことを意味します。
[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出力でありますピリオド（ ""）。ワイヤ出力は、同じシーケンスに従うが、各ラベルは、ワイヤは、符号化され、そしていかなる期間が挿入されていません。 NO「の場合の変換」または「場合フォールディング」は、したがってケースを「維持」は、出力動作中に行われます。ただし、出力を最適化するために、間接的なラベルは、他の場所でDNS応答内の名前を指すために使用することができます。名前が指されるべきかどうかを決定する際に（例えば、QNAME）名前の残りの部分が最適化されるように、上記指定された大文字と小文字を区別しない比較が行われ、「同じ」です。したがって、そのような最適化を容易にケースの出力保全を破壊することができます。この種の最適化は、一般的に「名前の圧縮」と呼ばれています。
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.
ゾーン転送または[STD13]で定義されているようもともと、DNSデータは、ASCIIマスターファイルから来ました。 DNS動的更新と差分ゾーン転送[RFC1995]は[RFC2136、RFC3007] DNSデータのソースとして追加されています。 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 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.
例えば、所有者名「foo.bar.example」[RFC3092]のデータがロードされ、その後、所有者名「xyz.BAR.example」の後のデータが「bar.example」ノードの入力、ラベルの名前である場合（すなわち、「バー」）またはDNS格納されたデータでは、「BAR」に変更されない場合があります。したがって、この場合には「xyz.bar.example」で保存されたデータの後の検索は、すべての「xyz.BAR.example」を使用することができるデータを戻した、全ての「xyz.bar.example」を使用し、データを返さ、あるいは、場合より1つのRRが返されるよりも、これらの二つの総額の混合物を使用します。間接的なラベルによる解答の長さの最適化は、すべて返されたRRのために使用する名前テール（「bar.example」または「BAR.example」）のコピーを1つだけ引き起こす傾向があるので、この最後のケースは、ほとんどありません。これのどれも返さ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.
のみの場合には異なる所有者名を持つ複数のデータレコードを入力するときと同じ考慮事項が適用されます。例えば、「A」レコードは、最初のリソースレコード所有者名「xyz.BAR.example」の下に格納された後、第2の「A」レコードが「XYZ.BAR.example」の下に格納され、第二ので格納することができるである場合第一（下部ケース初期ラベル）名、第二のみ大文字の最初のラベルが保持されている、またはその両方総額がDNS格納されたデータに保持することができるように、最初に無効にすることができます。いずれにせよ、どちらかの大文字と小文字検索は、どちらかの大文字と小文字すべてのRRを取得します。
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.
マスターファイルで矛盾した総額の結果は予測できない出力総額になるようにマスターファイルに表示されるDNS名のツリーノードのサーバーのデータベースへの挿入の順序が定義されていないことに注意してください。
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ドメイン名からの国際化ドメイン名とは別のアプリケーション・レベル変換によって[UNICODE]利用可能のほとんどになります。国際化ドメイン名とラベルがスクリプトに依存して変化しており、詳細については見なければならない[RFC3454]及び[RFC3491]に記載の形質転換の一部として完全に処理されていることをどのような場合でも非感受性。 STD 13で標準化、これはDNSの一部ではありません。
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の「正規」の形式を使用して処理することができます
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に格納することができます。これは非常にまれでしょうが、たとえば、大文字と小文字を区別した電子メールアドレスのローカル部分を持つシステム上で、場合にのみ異なっ2つの責任者（RP）[RFC1183]レコードを格納しようとする試みは、おそらくセキュリティに影響がある可能性があります予期しない結果を生成します。おそらく、大文字と小文字が区別ローカルまたは左側部分を含む全体の電子メールアドレスは、上述したように、いくつかの文字の場合は、出力に変更される可能性が読み取り可能な様式でDNS名に符号化されるためです。
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と、オラフルグドムンソン、ダニエル・J・アンダーソン、アラン・バレット、マルク・ブランシェ、ダナ、アンドレアス・グスタフソン、アンドリュー・メイン、トーマスNarten氏、スコット・セリグマンすることによって、この文書への貢献は深く感謝しています。
Normative References
引用規格
[ASCII] ANSI, "USA Standard Code for Information Interchange", X3.4, American National Standards Institute: New York, 1968.
[ASCII] ANSI、「情報交換用米国標準コード」、X3.4、米国規格協会：ニューヨーク、1968年。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC1995]太田、M.、 "DNSにおける増分ゾーン転送"、RFC 1995、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、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.
[RFC2136]いるVixie、P.、トムソン、S.、Rekhter、Y.、およびJ.バウンド、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、1997年4月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、RFC 2181、1997年7月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B.、RFC 3007、2000年11月 "ドメインネームシステム（DNS）動的更新をセキュア"。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]グスタフソン、A.、 "未知のDNSリソースレコード（RR）の取扱いタイプ"、RFC 3597、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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、RFC 4034、2005年3月。
[STD13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[STD13] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
Informative References
参考文献
[ISO-8859-1] International Standards Organization, Standard for Character Encodings, Latin-1.
[ISO-8859-1]国際標準化機構、標準文字エンコーディングのため、ラテン-1。
[ISO-8859-2] International Standards Organization, Standard for Character Encodings, Latin-2.
[ISO-8859-2]国際標準化機構、標準文字エンコーディングのため、ラテン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の定義"、RFC 1183、1990年10月。
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC1591]ポステル、J.、 "ドメインネームシステムの構造と委任"、RFC 1591、1994年3月。
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]イーストレーク第3、D.とA. Panitz、 "予約トップレベルDNS名"、BCP 32、RFC 2606、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の考慮事項"、BCP 42、RFC 2929、2000年9月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]いるVixie、P.、 "DNS用拡張メカニズム（EDNS0）"、RFC 2671、1999年8月。
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[RFC2673]クロフォード、M.、 "ドメインネームシステムにおけるバイナリラベル"、RFC 2673、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.レイモンド、フー " "" の語源"、RFC 3092、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.、フィンク、B.、グドムンソン、O.、およびT.ハイン、RFC 3363 "ドメインネームシステム（DNS）にインターネットプロトコルバージョン6（IPv6）アドレスを表します" 、2002年8月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、RFC 3454、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）"、RFC 3490、2003年3月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491]ホフマン、P.とM.ブランシェ、 "NAMEPREP：国際化ドメイン名のためのstringprepプロフィール（IDN）"、RFC 3491、2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]コステロ、A.、 "ピュニコード：アプリケーションにおける国際化ドメイン名のUnicodeのブートストリングのエンコード（IDNA）"、RFC 3492、2003年3月。
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/unicode/standard/standard.html>.
[UNICODE]ユニコードコンソーシアム、 "Unicode規格"、<http://www.unicode.org/unicode/standard/standard.html>。
Author's Address
著者のアドレス
Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレーク第3モトローラ研究所155ビーバー通りミルフォード、MA 01757 USA
Phone: +1 508-786-7554 (w) EMail: Donald.Eastlake@motorola.com
電話：+1 508-786-7554（ワット）メール：Donald.Eastlake@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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エディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。