[要約] RFC 4343は、DNSの大文字小文字の区別に関する説明と明確化を提供するものであり、DNSの実装と運用に関するガイドラインを提供します。このRFCの目的は、DNSの大文字小文字の扱いに関する混乱を解消し、一貫性のある動作を確保することです。
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
ドメイン名システム（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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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）名は「ケース非感受性」です。このドキュメントは、それが何を意味するかを正確に説明し、ルールの明確な仕様を提供します。この説明は、RFCS 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の「ケースの鈍感」の意味を明確にします。この説明は、RFCS 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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
マスターファイル[STD13]およびその他の人間が読み取る可能性のあるASCIIコンテキストでは、期間（0x2e、 "）のバイト値に脱出が必要です。0x7e（ "〜"）に。つまり、0x2Eと2つの包括的範囲のすべてのオクテット値は、0x00から0x20、および0x7Fから0xffです。
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桁の数字で表される署名されていない整数として使用することです。
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または\\として表現できます。バックスラッシュを使用して、プリントされていない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つの小数桁のみが続くバックスラッシュは未定義です。バックスラッシュに続いて4桁の数桁が2オクテットを生成します。最初の3桁の値は10進数と見なされ、2番目のオクテットは4桁目のキャラクターコードです。
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番目の1つは5オクテットラベルを示しています。2番目のオクテットにはすべてビットゼロがあり、3番目はバックスラッシュ、4番目のオクテットにはすべてビットがあります。
Donald\032E\.\032Eastlake\0323rd.example. and a\000\\\255z.example.
donald \ 032e \。\ 032eastlake \ 0323rd.example。およびa \ 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]。つまり、0x41から0x5aの範囲の値を持つルックアップ文字列オクテット、大文字のASCII文字は同一の値と一致し、0x61から0x7aの包括的範囲の対応する値と一致する必要があります。。小文字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".) 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.
（歴史的注：「大文字」と「小文字」という用語は、移動可能なタイプの後に発明されました。もともと、分割された領域、異なる物理タイプの要素を保存するための2つのフォントトレイを呼び出しました。可動型の前に、最も近い同等の用語は「Majuscule」と「Minuscule」。）このルールを実装する1つの方法は、オクテットを比較する前に、0x61から0x7aの包括的な範囲のすべてのオクテットから0x20を差し引くことです。このような操作は一般に「ケースフォールディング」として知られていますが、ケースフォールディングによる実装は必要ありません。DNSの場合、[ISO-8859-1]または[ISO-8859-2]で指定された折りたたみ式に対応していないことに注意してください。たとえば、オクテット0xdd（\ 221）および0xfd（\ 253）は一致しませんが、他のコンテキストでは、鋭いアクセントを持つ「y」の上限版と低ケースバージョンとして解釈されます。
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]には、ゼロから63オクテットの長さのASCIIラベルと、DNS上のエンコードの他の場所の名前の場所へのオフセットポインターで構成される間接（または圧縮）ラベルの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]によって拡張されたため、追加のラベルタイプ番号が利用可能になりました。（これまでに定義されている唯一のタイプは、バイナリタイプ[RFC2673]であり、現在は実験的である[RFC3363]です。）
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ラベルケースの処理はクラスに依存していません。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文字列に変換し、遭遇する各ラベルを出力するツリーを歩くこと、および最初のラベルの前にあるツリーを上に変換することにより、名前がマーシャルされたかのようです。期間 （"。"）。ワイヤ出力は同じシーケンスに従いますが、各ラベルはワイヤエンコードされており、期間は挿入されていません。このような出力操作中に「ケース変換」または「ケースフォールディング」は行われないため、「保存」ケースは行われません。ただし、出力を最適化するために、間接的なラベルを使用して、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.
もともと、DNSデータは、[STD13]またはゾーン転送で定義されているASCIIマスターファイルから来ました。DNS動的更新および増分ゾーン転送[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 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」ノードのラベルの名前は入力されています。（つまり、「bar」）は、DNS保存データの「bar」に変更される場合とされない場合があります。したがって、この場合、「xyz.bar.example」の下に保存されたデータの後の取得は、すべての返されたデータで「xyz.bar.example」を使用できます。すべての返されたデータで「xyz.bar.example」を使用します。1つのRRが返されているよりも、これら2つの大文字の混合物を使用します。この最後のケースは、間接的なラベルを介した回答長の最適化により、名前のテールのコピー（ "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」の下に保存されます。最初の（小文字の初期ラベル）名前、2番目は最初の名前をオーバーライドして、大文字の初期ラベルのみが保持されるか、両方の大文字が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]に記載されているように、「国際化ドメイン名」および「国際化ラベル」にスキームが採用されています。[Unicode]の大部分は、国際化ドメイン名からDNSドメイン名、およびDNSドメイン名から国際化ドメイン名への個別のアプリケーションレベル変換を通じて利用可能になります。国際化されたドメイン名とラベルは、スクリプトによって異なり、[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 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].
さらに、ドメイン名は、DNS以外のコンテキストで使用できます。一部のデータベースまたはファイルシステムへのケースに敏感なインデックスとして使用できます。または、何らかの整合性または認証コードシステムによってバイナリデータとして解釈される可能性があります。これらの問題は通常、DNS 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.
この文書への貢献は、ロブ・アウスタイン、オラファー・グドムンソン、ダニエル・J・アンダーソン、アラン・バレット、マーク・ブランシェ、ダナ、アンドレアス・グスタフソン、アンドリュー・メイン、トーマス・ナルテン、スコット・セリグマンに感謝しています。
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 Institute：New York、1968。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC1995] OHTA、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメイン名システム（DNSアップデート）の動的更新」、RFC 2136、1997年4月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「セキュアドメイン名システム（DNS）動的更新」、RFC 3007、2000年11月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597] Gustafsson、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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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.
Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
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] Everhart、C.、Mamakos、L.、Ullmann、R。、およびP. Mockapetris、「新しいDNS RR定義」、RFC 1183、1990年10月。
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC1591] Postel、J。、「ドメイン名システム構造と委任」、RFC 1591、1994年3月。
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606] EastLake 3rd、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] Eastlake 3rd、D.、Brunner-Williams、E.、およびB. Manning、「ドメイン名システム（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] Crawford、M。、「ドメイン名システムのバイナリラベル」、RFC 2673、1999年8月。
[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology of "Foo"", RFC 3092, 1 April 2001.
[RFC3092] EastLake 3rd、D.、Manros、C。、およびE. Raymond、「Foo」の語源、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] Bush、R.、Durand、A.、Fink、B.、Gudmundsson、O.、およびT. Hain、「インターネットプロトコルバージョン6（IPv6）を表すドメイン名システム（DNS）」、RFC 3363、2002年8月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454] Hoffman、P。およびM. Blanchet、「国際化された文字列の準備（「StringPrep」）」、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.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（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] Hoffman、P。およびM. Blanchet、「NamePrep：Internationalized Domain Name（IDN）のStringPrepプロファイル」、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] Costello、A。、「Punycode：Applications（IDNA）の国際化ドメイン名のUnicodeのブートストリングエンコーディング」、RFC 3492、2003年3月。
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/unicode/standard/standard.html>.
[Unicode] Unicode Consortium、「Unicode Standard」、<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ビーバーストリートミルフォード、マサチューセッツ州01757 USA
Phone: +1 508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。