RFC 4343 ドメイン名システム（ＤＮＳ）の大文字小文字無視の説明

この文書はRFC 4343の日本語訳（和訳）です。この文書の翻訳内容の正確さは保障できないため、正確な知識や情報を求める方は原文を参照してください。翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。この文書の配布は元のＲＦＣ同様に無制限です。

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.
この文書はインターネット共同体のためのインターネット標準化中プロトコ
ルを指定して、そして改良のために議論と提案を求めます。このプロトコル
の標準化状態とステータスについては最新の「インターネット公式プロトコ
ル標準」（ＳＴＤ１）の最新の版を見てください。 このメモの配布は無制
限です。

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.
ドメイン名システム（ＤＮＳ）名は大文字小文字の違いを無視します。この文
書はこれが何を意味するかを正確に説明し、規則の明確な仕様を提供します。
この明確な説明はRFC１０３４と１０３５と２１８１を更新します。

Table of Contents
目次

1. Introduction
1. はじめに
2. Case Insensitivity of DNS Labels
2. ＤＮＳラベルの大文字小文字無視
2.1. Escaping Unusual DNS Label Octets
2.1. 異常なＤＮＳラベルオクテットから逃れること
2.2. Example Labels with Escapes
2.2. エスケープラベルの例
3. Name Lookup, Label Types, and CLASS
3. 名前検索、ラベルタイプとクラス
3.1. Original DNS Label Types
3.1. 元々のＤＮＳラベル種別
3.2. Extended Label Type Case Insensitivity Considerations
3.2. ラベル種別の大文字小文字の無視の考察の拡張
3.3. CLASS Case Insensitivity Considerations
3.3. クラスの大文字小文字の無視の考察
4. Case on Input and Output
4. 入力と出力の大文字小文字
4.1. DNS Output Case Preservation
4.1. ＤＮＳ出力時の大文字小文字の保存
4.2. DNS Input Case Preservation
4.2. ＤＮＳ入力の大文字小文字の保存
5. Internationalized Domain Names
5. 国際化ドメイン名
6. Security Considerations
6. セキュリティの考察
7. Acknowledgements
7. 謝辞
Normative References
参照する参考文献

Informative References
有益な参考文献

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].
ドメイン名システム（ＤＮＳ）はインターネットアドレスやメールプロキシ
や他のインフォメーションのための世界的階層的再帰分散データベースシス
テムです。ＤＮＳ木のそれぞれのノードはゼロ個以上のラベル[STD13,
RFC1591, RFC2606]からなる名前を持ち、これらは大文字小文字の違いを無
視する方法で扱われます。この文書はＤＮＳのために「大文字小文字の違い
を無視する」の意味を明確にします。この明確な説明はＲＦＣ１０３４、
１０３５[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"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
[RFC2119]で記述されるように解釈します。

2. Case Insensitivity of DNS Labels
2. ＤＮＳラベルの大文字小文字無視

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,
ＤＮＳは[ASCII]の時代に指定されました。ＤＮＳ名がたいていのホスト名や
インターネット電子メールアドレスの右半分（アットマーク"@"の後半部）や
ＤＮＳ名前空間のaddr.arpa部のように、数であると予想されます。例えば、

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

Case-varied alternatives to the above [RFC3092] would be DNS names
like
上記の大文字小文字が異なる別表記[RFC3092]は以下の様なＤＮＳ名です

Foo.ExamplE.net.
AOL.COM.
WWW.gnu.AI.mit.EDU.
or 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.
しかしながら、ＤＮＳ名の元になるオクテットは正当なASCIIの文字コー
ドに制限されません。これらは８ビットのバイトで、そしてすべての値は
許されます。しかしながら、多くのアプリケーションがこれらをASCII文
字と解釈します。

2.1. Escaping Unusual DNS Label Octets
2.1. 異常なＤＮＳラベルオクテットから逃れること

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]とその他の人間が読み書きできるＡＳＣＩＩ資料
で、ピリオドや0x21( "!")から0x7E("~")以外のオクテット値でエスケープ
が必要です。. すなわち、 0x2Eと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表示可能文字に対応しないオクテットの表示の慣習はバックスラッシュ
に続けて、正確に３桁の１０進数の符号なし整数でオクテットの値を続ける
方法です。

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.
同じ慣習は、ＡＳＣＩＩ文字を印刷する際に、普通のラベル文字として取
り扱うために使うことができます。これは、\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.
たった１つあるいは２つの１０進数が後に続くバックスラッシュが未定義
です。バックスラッシュに続く４つの１０進数は２オクテットを生成し、
最初のオクテットは最初の１０進数の３文字が値のもので、２番目のオク
テットは４番目の１０進数の文字コードです。

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.
下の最初の例はラベルに埋め込まれたスペースとピリオド(".")を示します。
２番目のは５オクテットのラベルで、２番目のオクテットはオールビット
０で、３番目はバックスラッシュで、４番目はオールビット１です。

Donald\032E\.\032Eastlake\0323rd.example.
and a\000\\\255z.example.

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.
元々のＤＮＳの設計によれば、ＤＮＳの問合せの名前検索での比較は大文字
小文字の違いを無視します[STD13]。すなわち、検索文字列オクテット値で
0x41から0x5Aの範囲の大文字ASCII文字は、それ自身と、0x61から0x7Aの
範囲の対応する小文字と一致なければなりません(MUST)。小文字ASCII文字
の検索文字列のオクテットは、それ自身と、対応するASCII範囲の大文字と
一致なければなりません(MUST)。

(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".)
（歴史メモ：用語「uppercase」と「lowercase」は活字ができた後に発明さ
れました。元々の用語は、仕切られた場所に異なる活字を保管した、活字保
管箱の事でした。活字以前には、最も類似の用語は「majuscule」と
「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.
この規則を実施する１つの方法はオクテットを比較する前に0x61から0x7A
の範囲のすべてのオクテットから0x20を引くことです。このような操作は
一般に「大文字変換」として知られています、しかし大文字変換の実装は必
須でありません。ＤＮＳ大文字変換が[ISO-8859-1]や[ISO-8859-2]の大文字
変換に対応しない(NOT)ことに注意してください。例えば、オクテット0xDD
(\221)と0xFD (\253)は、他の文脈でこれらが揚音符付の大文字や小文字の
Ｙと解釈されるかもしれませんが、一致しません(NOT)。

3.1. Original DNS Label Types
3.1. 元々のＤＮＳラベル種別

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.
ワイヤコードのＤＮＳラベルはそれらに関連する種別をもちます。元々のＤ
ＮＳ標準[STD13]は２種類しかありません：長さが０から６３オクテットの
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].)
追加のラベル種別番号が利用可能になるようにＤＮＳは[RFC2671]によって
拡張されました。（これまでの唯一の定義された種別は現在は実験的
[RFC3363]なバイナリ種別[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の大文字小文字の無視の慣習はＡＳＣＩＩらラベルにだけ適用されま
す；すなわち、直接か間接ラベルに呼ばれての、ラベル種別です。

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]で記述されるように、ＤＮＳはクラスと呼ばれるデー
タの場所のための軸を持っています。現在世界的に使用されている唯一の
クラスは「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.
ＤＮＳラベルの大文字小文字の取り扱いはクラスに依存しません。ＤＮＳ
の元々の設計で、再帰的なＤＮＳリゾルバは実装時点で未知であった新し
いクラスを処理することが可能であると意図されました。これはラベルの
大文字小文字の一様な取り扱いを必要とします。もしそれが望ましくない
なら、例えば、「大文字小文字の違いを識別するASCIIラベル」のクラス
を割り当てるために、ラベルに新しいラベルタイプを割り当てることが必
要であるでしょう。

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］は大
文字小文字が出力時に維持され、入力時に使いやすいときは維持されなく
てはならない(MUST)と言います。しかしながら、以下で説明するように、
出力に関する大文字小文字の保存は、間接ラベルの使用による出力最適化
時に必要とされない(NOT)ので、書かれている通りではありません。

4.1. DNS Output Case Preservation
4.1. ＤＮＳ出力時の大文字小文字の保存

[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］はＤＮＳ名前空間をノード木と見なします。ASCII出力は、ノー
ドの名前のラベルを並べ、印刷用のASCII文字列に変換し、木に沿って遭
遇したラベルを出力し、ピリオド(".")に続いてラベルをつないだものです。）
ワイヤ出力は同じシーケンスで、しかしそれぞれのラベルがワイヤコード
化され、そしてピリオドが挿入されません。これらの出力操作で「大文字
小文字変換」や「小文字変換」がが行われず、大文字小文字は「維持」さ
れます。しかしながら、出力を最適化するために、間接ラベルがＤＮＳの
答えの他のところに名前を示すために使われるかもしれません。指し示す
名前（例えばQNAME）が、最適化される名前の残に「一致」するかの決定
は、上で指定した大文字小文字の違いを無視する比較になります。それで、
このような最適化は容易に出力の保存を破壊するかもしれません。この種
類の最適化は一般に「名前圧縮」と呼ばれます。

4.2. DNS Input Case Preservation
4.2. ＤＮＳ入力の大文字小文字の保存

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］で定義されるASCIIのマスターファイルか
ゾーン転送に由来します。ＤＮＳ動的更新と逐次ゾーン転送［RFC1995］が
ＤＮＳデータの情報提供者［RFC2136, RFC3007］として加えられました。Ｄ
ＮＳ名木のノードがこのような入力のいずれかで作成されるとき、大文字小
文字変換がされません。それで、もしノードが作成される時に、ASCIIラベ
ルの大文字小文字は維持されます。しかしながら、保持するＤＮＳデータに
すでに存在するノードに対して入力があると、状況はより複雑です。このよ
うなラベルの最初に読み込まれた大文字小文字を維持するか、新しい入力が
古い大文字小文字を上書きするか、入力の大文字小文字を維持した別のコピー
を作るかは、実装の自由です。

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"）は、ＤＮＳ保管庫
で"BAR"に変更されるかも知れず、されないかもしれません。それで、この
場合"xyz.bar.example"下に保存されたデータを後で検索した場合に、すべ
ての返すデータで"xyz.BAR.example"を使うか、すべての返すデータで
"xyz.bar.example"を使うか、複数の資源レコードが返す時に、これらの２
つを混合して使うことができます。間接ラベルによる解答長の最適化がたっ
た１つの名前最後のコピー（「bar.example」あるいは「BAR.example」）を
すべての返す資源レコードに使う傾向があるので、最後の事例はなさそうで
す。これが返す資源レコードの数や完全性に影響を与えないことに注意して
ください、ただ返す資源レコードの名前の大文字小文字に関するだけです。

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"下に
保存される最初の資源レコードで、次に２番目の"Ａ"レコードが
"XYZ.BAR.example"下に保存されるなら、2番目は最初の名前（小文字の最初
のラベル）で保存されるかも知れず(MAY)、２番目は最初を上書きして大文字
のラベルだけが保存されるかも知れず(MAY)、両方がＤＮＳ保管庫に保存され
るかもしれません(MAY)。.いずれにしても、全ての資源レコードでいずれか
の大文字小文字が返されるでしょう。

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.
マスターファイルに現われるＤＮＳ名木ノードのサーバーデータベース中
への挿入の順序が定義されず、マスターファイルでの大文字小文字が一貫
しない時の結果が予想できないことに注意してください。

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］で記述されるように「国際化ド
メイン名」と「国際化ラベル」の体系が採用されました。これは、国際化
ドメイン名からＤＮＳドメイン名とＤＮＳドメイン名から国際化ドメイン
名への別個のアプリケーションレベル変換により、[UNICODE]の大部分が利
用可能です。国際化ドメイン名とラベルの持つ大文字小文字の無視はスク
リプトに依存し、[RFC3454]と[RFC3491]で記述された変換部分で扱われま
す、詳細は[RFC3454]と[RFC3491]を見てください。これはＳＴＤ１３で標
準化されたＤＮＳの一部ではありません。

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.
大文字小文字の違いがある特定のＤＮＳラベルタイプの比較は、この文書
で明確にされるように、セキュリティー問題に導くことがあります。例え
ば、大文字小文字だけが異なる２つのドメイン名が実際に異なった名前と
信じることで、ユーザが困惑し得ます。

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].
さらに、ドメイン名がＤＮＳ以外の文脈で使われるかもしれません。これ
はあるデータベースやファイルシステムで大文字小文字の違いを識別する
インデックスとして使用できます。あるいはこれはある完全性あるいは認
証コードシステムでバイナリデータと解釈できます。これらの問題は通常、
ＤＮＳのASCII種別ラベルの標準化か「正規化」形式を使うことによって、
対応できます；これはASCIIラベルのASCIIの文字値オクテットを大文字
か、小文字のいずれか事前に決めたものに常に変換することです。ドメイ
ン名のための正規化形式（と同じく正規化順）の例が[RFC4034]の６章に現
われます。同じく[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.
最終的に、非ＤＮＳの名前が大文字小文字が常に維持されるという誤った
期待でＤＮＳの中に保管されるかもしれません。例えば、これが非常に珍
しいであろうけれども、大文字小文字の違いを識別する電子メールアドレ
スローカル部を持つシステムで、大文字小文字だけが違う異なる２つの責
任者（RP）［RFC1183］レコードを保存する試みは、おそらくセキュリティ
問題がある、意図しない結果を引き起こすでしょう。なぜなら、大文字小
文字の違いを識別するローカル部や左の部分を含む、全部の電子メールア
ドレスは、上に記述されるように、ある文字の大文字小文字が出力で変え
られるかもしれない方法でＤＮＳ名でコード化されるからです。

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.
Rob AusteinとOlafur GudmundssonとDaniel J. AndersonとAlan Barrett
とMarc BlanchetとDanaとAndreas GustafssonとAndrew Mainと
Thomas NartenとScott Seligmanのこの文書への貢献に感謝します。

Normative References
参照する参考文献

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

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

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

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

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

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

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

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

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

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-2] International Standards Organization, Standard for
Character Encodings, Latin-2.

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

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

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

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

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

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

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

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

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

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

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

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

[UNICODE] The Unicode Consortium, "The 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

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

Full Copyright Statement
著作権表示全文

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.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。

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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。

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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。

Acknowledgement
謝辞

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。

Japanese translation by Ishida So