この文書はRFC2826の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group Internet Architecture Board
Request for Comments: 2826 May 2000
Category: Informational
IAB Technical Comment on the Unique DNS Root
一意なＤＮＳルートについてのＩＡＢ技術コメント
Status of this Memo
この文書の状態
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
このメモはインターネット共同体のための情報を供給します。これはインター
ネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Summary
要約
To remain a global network, the Internet requires the existence of a
globally unique public name space. The DNS name space is a
hierarchical name space derived from a single, globally unique root.
This is a technical constraint inherent in the design of the DNS.
Therefore it is not technically feasible for there to be more than
one root in the public DNS. That one root must be supported by a set
of coordinated root servers administered by a unique naming
authority.
グローバルなネットワークでいるために、インターネットはグローバルにユ
ニークな公共名前空間の存在を必要とします。ＤＮＳ名前空間はひとつのグ
ローバルにユニークなルートから得られた階層的な名前空間です。これはＤ
ＮＳ設計に固有の技術的な制約です。それ故に公共ＤＮＳで複数のルートは
可能でありません。その１つのルートは唯一の名前の権威によって運営され
た整合したルートサーバ群で支えられなくてはなりません。
Put simply, deploying multiple public DNS roots would raise a very
strong possibility that users of different ISPs who click on the same
link on a web page could end up at different destinations, against
the will of the web page designers.
簡単に言うと、多数の公共のＤＮＳルートを実装することはウェブページ上
の同じリンクをクリックする異なるＩＳＰのユーザがウェブデザイナーの意
思に反して異なる宛先に接続する非常に強い可能性を生じるでしょう。
This does not preclude private networks from operating their own
private name spaces, but if they wish to make use of names uniquely
defined for the global Internet, they have to fetch that information
from the global DNS naming hierarchy, and in particular from the
coordinated root servers of the global DNS naming hierarchy.
これは自身のプライベート名前空間を持つプライベートネットワークの運営
を不可能にしませんが、しかしもし彼らがユニークにグローバルなインター
ネットのために定義された名前を利用することを望むなら、グローバルなＤ
ＮＳ名前階層から、特にグローバルなＤＮＳ名前階層のルートサーバから情
報を得なければなりません。
1. Detailed Explanation
1. 詳細な説明
There are several distinct reasons why the DNS requires a single root
in order to operate properly.
なぜＤＮＳが正確に稼働するためにひとつのルートを必要とするかについて、
いくつかの理由があります。
1.1. Maintenance of a Common Symbol Set
1.1. 共通記号集合の維持管理
Effective communications between two parties requires two essential
preconditions:
２者間で通信ができるには、２つの必要条件を要求します：
- The existence of a common symbol set, and
- 共通の記号集合の存在。
- The existence of a common semantic interpretation of these
symbols.
- これらの記号の共通の意味の解釈の存在。
Failure to meet the first condition implies a failure to communicate
at all, while failure to meet the second implies that the meaning of
the communication is lost.
最初の条件を満たさなければ完全な通信の失敗を意味し、第２の条件を満た
さなければ通信の意味が失われます。
In the case of a public communications system this condition of a
common symbol set with a common semantic interpretation must be
further strengthened to that of a unique symbol set with a unique
semantic interpretation. This condition of uniqueness allows any
party to initiate a communication that can be received and understood
by any other party. Such a condition rules out the ability to define
a symbol within some bounded context. In such a case, once the
communication moves out of the context of interpretation in which it
was defined, the meaning of the symbol becomes lost.
公共の通信システムの場合、この共通の意味の解釈を持つ共通記号集合の状
態はさらに、一意に意味が解釈される一意な記号で強固にされなくてはなり
ません。この一意性の状態は任意の者が任意の他者に受信できて理解ができ
る連絡を始めることを許します。このような条件はある境界内での文脈での
記号を定義する能力を除外します。このような場合、通信が定義された文脈
解釈の範囲から出ると、記号の意味は失われます。
Within public digital communications networks such as the Internet
this requirement for a uniquely defined symbol set with a uniquely
defined meaning exists at many levels, commencing with the binary
encoding scheme, extending to packet headers and payload formats and
the protocol that an application uses to interact. In each case a
variation of the symbol set or a difference of interpretation of the
symbols being used within the interaction causes a protocol failure,
and the communication fails. The property of uniqueness allows a
symbol to be used unambiguously in any context, allowing the symbol
to be passed on, referred to, and reused, while still preserving the
meaning of the original use.
インターネットのような公共のデジタル通信ネットワークの中で、この一意
に定義された意味を持つ一意に定義された記号のための必要条件は、バイナ
リコーディング方式とパケットヘッダとペイロードフォーマットの拡張とア
プリケーションが相互作用するために使うプロトコルにまで、多数のレベル
で存在します。相互作用でのそれぞれの場合に記号集合の違いと記号解釈の
違いはプロトコル誤りと通信誤りを生じます。一意性の性質は、記号がどん
な文脈でも明瞭に使用される事を許し、元の意味を維持したまま記号を渡し
参照し再利用することを許します。
The DNS fulfills an essential role within the Internet protocol
environment, allowing network locations to be referred to using a
label other than a protocol address. As with any other such symbol
set, DNS names are designed to be globally unique, that is, for any
one DNS name at any one time there must be a single set of DNS
records uniquely describing protocol addresses, network resources and
services associated with that DNS name. All of the applications
deployed on the Internet which use the DNS assume this, and Internet
users expect such behavior from DNS names. Names are then constant
symbols, whose interpretation does not specifically require knowledge
of the context of any individual party. A DNS name can be passed
from one party to another without altering the semantic intent of the
name.
ＤＮＳはプロトコルアドレス以外のラベルを使ってネットワークの場所の参
照を許しているインターネット・プロトコル環境の中で不可欠な役割を満た
します。この他の記号集合同様に、ＤＮＳ名がグローバルに一意であるよう
意図されます、すなわち、ある時点でのあるＤＮＳ名に対して一意にプロト
コルアドレスとネットワーク資源とサービスを記述する１つのＤＮＳ資源集
合が存在するに違いありません。ＤＮＳを使うインターネット上に実装する
アプリケーションのすべてがこれを想定し、そしてインターネットユーザが
ＤＮＳ名からこのような行動を期待します。名前はその解釈が個別の参加者
の文脈の知識を必要としない時に、不変の記号です。ＤＮＳ名が名前の意味
の意図を変えないで、ある人から他の人に渡すことができます。
Since the DNS is hierarchically structured into domains, the
uniqueness requirement for DNS names in their entirety implies that
each of the names (sub-domains) defined within a domain has a unique
meaning (i.e., set of DNS records) within that domain. This is as
true for the root domain as for any other DNS domain. The
requirement for uniqueness within a domain further implies that there
be some mechanism to prevent name conflicts within a domain. In DNS
this is accomplished by assigning a single owner or maintainer to
every domain, including the root domain, who is responsible for
ensuring that each sub-domain of that domain has the proper records
associated with it. This is a technical requirement, not a policy
choice.
ＤＮＳがドメインを階層的に構造化するので、その項目のＤＮＳ名の一意性
の必要条件は、ドメインがそのドメイン内で定義された各名前（サブドメイ
ン）が一意な意味（すなわち、ＤＮＳレコードの集合）を持つことを意味し
ます。これは他のＤＮＳドメインについてもルートドメイン同様に本当です。
ドメイン内の一意性の必要条件はドメイン内の名前の競合を妨ぐなんらかの
メカニズムがあることを意味します。ルートドメインを含めてＤＮＳでこれ
は各ドメインに一人の所有者または維持者を割り当てることによって達成さ
れています、この者はそれぞれのドメインのサブドメインが関連した適切な
レコードを持っていることを保証することに責任があります。これは、ポリ
シーの選択ではなく、技術的な必要条件です。
1.2. Coordination of Updates
1.2. 更新の調整
Both the design and implementations of the DNS protocol are heavily
based on the assumption that there is a single owner or maintainer
for every domain, and that any set of resources records associated
with a domain is modified in a single-copy serializable fashion.
That is, even assuming that a single domain could somehow be "shared"
by uncooperating parties, there is no means within the DNS protocol
by which a user or client could discover, and choose between,
conflicting definitions of a DNS name made by different parties. The
client will simply return the first set of resource records that it
finds that matches the requested domain, and assume that these are
valid. This protocol is embedded in the operating software of
hundreds of millions of computer systems, and is not easily updated
to support a shared domain scenario.
設計とＤＮＳプロトコル実装の両方は、すべてのドメインに一人の所有者あ
るいは維持者がいて、ドメインに関連した資源レコードは１組を連続して修
正する形式である、の仮定に強く基づきます。これは、ひとつのドメインが
どうにかして協調していない者達によって所有される場合でもそうで、ＤＮ
Ｓプロトコルは異なる者により作られた矛盾した定義をユーザやクライアン
トが発見できる手段はありません。クライアントは求められたドメインに合
う見つかった資源レコードの最初のセットを返して、そしてこれらが正当で
あると想定するでしょう。このプロトコルは何億というコンピュータシステ
ムの運営上のソフトウェアに埋め込まれて、そして共有されたドメインシナ
リオサポートするための更新は容易でありません。
Moreover, even supposing that some other means of resolving
conflicting definitions could be provided in the future, it would
have to be based on objective rules established in advance. For
example, zone A.B could declare that naming authority Y had been
delegated all subdomains of A.B with an odd number of characters, and
that naming authority Z had been delegated authority to define
subdomains of A.B with an even number of characters. Thus, a single
set of rules would have to be agreed to prevent Y and Z from making
conflicting assignments, and with this train of actions a single
unique space has been created in any case. Even this would not allow
multiple non-cooperating authorities to assign arbitrary sub-domains
within a single domain.
さらに、何か他の矛盾する定義を解決する手段が将来供給できたとしてさえ、
それは前もって確立された客観的な規則に基づいていなければならないでしょ
う。例えば、ゾーン地域A.Bで、権威ＹがA.Bの全部の偶数文字のサブドメイ
ンを委任されたと宣言し、権威ＺがA.Bの定義された奇数文字のサブドメイン
を委任されたと宣言したします。それで、ＹとＺの矛盾する割当を阻止する
ことに同意していなければならないでしょう、そしてこの一連の行動でどん
な場合でも一意な場所が作られます。これでも多数の協力しない権威がひと
つのドメイン内に任意のサブドメインを割り当てることを許さないでしょう。
It seems that a degree of cooperation and agreed technical rules are
required in order to guarantee the uniqueness of names. In the DNS,
these rules are established independently for each part of the naming
hierarchy, and the root domain is no exception. Thus, there must be
a generally agreed single set of rules for the root.
適度な協調と承認された技術的規則が名前の一意性を保証するために必要と
思われます。ＤＮＳでこれらの規則は、それぞれの名前階層部分で独立して
確立されます、そしてルートドメインも例外ではありません。それで、ルー
トにも一般に承認された単一規則があるに違いありません。
1.3. Difficulty of Relocating the Root Zone
1.3. ルートゾーンを移動させることの困難
There is one specific technical respect in which the root zone
differs from all other DNS zones: the addresses of the name servers
for the root zone come primarily from out-of-band information. This
out-of-band information is often poorly maintained and, unlike all
other data in the DNS, the out-of-band information has no automatic
timeout mechanism. It is not uncommon for this information to be
years out of date at many sites.
ルートゾーンは他のすべてのＤＮＳゾーンと違う１つの特定の技術的重要性
があります：ルートゾーンのネームサーバのアドレスは主に外から与えられ
た情報によります。この外から与えられた情報はしばしば不完全に維持され、
そして、ＤＮＳの他のすべてのデータと異なり、外から与えられた情報は自
動タイムアウトメカニズムを持っていません。多くのサイトにおいてこれが
何年も時代遅れの情報であることは珍しくありません。
Like any other zone, the root zone contains a set of "name server"
resource records listing its servers, but a resolver with no valid
addresses for the current set of root servers will never be able to
obtain these records. More insidiously, a resolver that has a mixed
set of partially valid and partially stale out-of-band configuration
information will not be able to tell which are the "real" root
servers if it gets back conflicting answers; thus, it is very
difficult to revoke the status of a malicious root server, or even to
route around a buggy root server.
他のゾーンのようにも、ルートゾーンはサーバーリストアップする「ネーム
サーバ」資源レコード集合を含んでいますが、現在のルートサーバの正当な
アドレスがわからないリゾルバは決してこれらのレコードを得ることが可能
ではないでしょう。より賢く、部分的に正しいく部分的に古い情報を持つリ
ゾルバは、矛盾した応答を得るとどれが「本当」のルートサーバかわからな
いでしょう；それで、意があるルートサーバ、あるいはバグルートサーバに
経路を決める状態を無効にすることは非常に難しいです。
In effect, every full-service resolver in the world "delegates" the
root of the public tree to the public root server(s) of its choice.
実際、すべての世界中の完全サービスリゾルバが、その選択として公共ツリー
のルートを公共ルートサーバに「委任」します。
As a direct consequence, any change to the list of IP addresses that
specify the public root zone is significantly more difficult than
changing any other aspect of the DNS delegation chain. Thus,
stability of the system calls for extremely conservative and cautious
management of the public root zone: the frequency of updates to the
root zone must be kept low, and the servers for the root zone must be
closely coordinated.
直接の結果として、どんな公共ルートゾーンを指定するＩＰアドレスのリス
トに対する変更は、他のＤＮＳ委任鎖を変えるとても難しいです。それで、
システムの安定性は公共ルートゾーンの非常に保守的で、そして用心深い管
理を必要とします：ルートゾーンへの更新の頻度は低くしておかなくてはな
りません、そしてルートゾーンのサーバは注意深く協調しているに違いあり
ません。
These problems can be ameliorated to some extent by the DNS Security
Extensions [DNSSEC], but a similar out-of-band configuration problem
exists for the cryptographic signature key to the root zone, so the
root zone still requires tight coupling and coordinated management
even in the presence of DNSSEC.
これらの問題はＤＮＳセキュリティ拡張[DNSSEC]によってある程度改善され
ることができますが、類似の外から与えられた情報の設定問題がルートゾー
ンの鍵の暗号署名に存在します、それでルートゾーンはＤＮＳＳＥＣでも固
い結合と協調管理を必要とします。
2. Conclusion
2. 結論
The DNS type of unique naming and name-mapping system may not be
ideal for a number of purposes for which it was never designed, such
a locating information when the user doesn't precisely know the
correct names. As the Internet continues to expand, we would expect
directory systems to evolve which can assist the user in dealing with
vague or ambiguous references. To preserve the many important
features of the DNS and its multiple record types -- including the
Internet's equivalent of telephone number portability -- we would
expect the result of directory lookups and identification of the
correct names for a particular purpose to be unique DNS names that
are then resolved normally, rather than having directory systems
"replace" the DNS.
一意に命名されたＤＮＳ種別と名前対応システムは、ユーザが正確に正しい
名前を知らない時に場所を示すなどの、設計になかったいくつもの目的では、
理想的ではないかもしれません。インターネットが拡張し続けるように、我
々ははっきりしないかあるいはあいまいな参照を扱うことでユーザを支援す
ることができる発展ディレクトリシステムを期待するでしょう。ＤＮＳの多
くの重要な特徴と多種のレコードタイプの維持のため−インターネットの、
電話番号ポータビリティの同等物を含めて−、我々はディレクトリシステム
がＤＮＳを「置き換える」より、通常我々は一意なＤＮＳ名の目的で普通に
解決するディレクトリ検索と正しい名前の身元確認の結果を期待するでしょ
う。
There is no getting away from the unique root of the public DNS.
公共のＤＮＳの一意なルートから逃がれることはできません。
3. Security Considerations
3. セキュリティの考察
This memo does not introduce any new security issues, but it does
attempt to identify some of the problems inherent in a family of
recurring technically naive proposals.
このメモは新しいセキュリティ問題を発生しませんが、再発している技術に
疎い提案に固有のある問題の識別しようと試みます。
4. IANA Considerations
4. ＩＡＮＡの考慮
This memo is not intended to create any new issues for IANA.
このメモはＩＡＮＡに新しい課題を作るように意図されません。
5. References
5. 参考文献
[DNS-CONCEPTS] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[DNS-IMPLEMENTATION] Mockapetris, P., "Domain Names - Implementation
and Specification", STD 13, RFC 1035, November
1987.
[DNSSEC] Eastlake, D., "Domain Name System Security
Extensions", RFC 2535, March 1999.
6. Author's Address
6. 著者のアドレス
Internet Architecture Board
EMail: iab@iab.org
7. Full Copyright Statement
7. 著作権表示全文
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（Ｃ）インターネット学会（２００３）。すべての権利は保留される。
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
上に与えられた限定された許可は永久で、インターネット学会やその後継者
や譲渡者によって無効にされません。
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含む情報は無保証で供給され、そしてインターネット学会
とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、すべての保証を拒否します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。