[要約] RFC 2826は、IABによるUnique DNS Rootに関する技術的なコメントであり、DNSルートの一意性と安定性を確保するためのガイドラインを提供しています。目的は、インターネットの基盤であるDNSのルートシステムの運用と管理を支援し、信頼性とセキュリティを向上させることです。
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.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
グローバルなネットワークを維持するために、インターネットはグローバルにユニークな公共の名前空間の存在を必要とします。 DNS名前空間は、単一の、グローバルにユニークなルートから派生した階層名前空間です。これは、DNSの設計に固有の技術的な制約です。したがって、公共のDNSに複数のルートがあるために技術的に可能ではありません。それつのルートは、独自の命名機関によって管理協調ルートサーバのセットでサポートされなければなりません。
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.
簡単に言えば、複数のパブリックDNSルートを展開すると、Webページに同じリンクをクリックして異なるISPのユーザーは、Webページの設計者の意思に反して、異なる宛先で終わることができることを非常に強力な可能性を高めるでしょう。
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.
これは、自分のプライベート名前空間を操作するからプライベートネットワークを排除するものではありませんが、彼らは独自にグローバルなインターネットのために定義された名前の利用を希望する場合、彼らはグローバルDNS命名階層からその情報を取得する必要があり、特に協調ルートからグローバルDNS名前階層のサーバ。
There are several distinct reasons why the DNS requires a single root in order to operate properly.
DNSが正常に動作するために、単一のルートを必要とする理由をいくつかの明確な理由があります。
Effective communications between two parties requires two essential preconditions:
2つの当事者間の効果的なコミュニケーションは、2つの本質的な前提条件が必要です。
- 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.
秒を満たすために失敗は通信の意味が失われることを意味しつつ、第1の条件を満たさない場合は、すべての通信に失敗したことを意味します。
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.
DNSは、ネットワークの場所は、プロトコルアドレス以外のラベルを使用して参照できるように、インターネットプロトコル環境内で重要な役割を果たしています。他のそのようなシンボルセットと同じように、DNS名は一意に関連付けられたプロトコルアドレス、ネットワーク・リソースとサービスを記述したDNSレコードの単一のセットが存在する必要があり、任意の時点でいずれかのDNS名のために、つまり、グローバルに一意であるように設計されていますDNS名。 DNSを使用してインターネットにデプロイされたアプリケーションのすべては、このことを前提とし、インターネットユーザーは、DNS名から、そのような行動を期待しています。名前はその後、その解釈は、特に個々の当事者の文脈の知識を必要としない定数記号、です。 DNS名は、名前の意味的な意図を変えることなく、別の関係者から渡すことができます。
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.
DNSは、階層的ドメインに構成されているので、それらの全体がDNS名の一意性の要件は、ドメイン内で定義された名前（サブドメイン）の各々は、そのドメイン内で固有の意味（すなわち、DNSレコードのセット）を有していることを意味します。これは、他のDNSドメインのようルートドメイン用として真実です。ドメイン内の一意性のための要件は、さらに、ドメイン内の名前の衝突を防ぐために、いくつかのメカニズムがあることを意味しています。 DNSには、これは、そのドメインの各サブドメインは、それに関連付けられた適切なレコードを持っていることを保証する責任があるルートドメイン、を含む、すべてのドメインに単一の所有者または保守を割り当てることによって達成されます。これは技術的な要件ではなく、政策の選択です。
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.
設計およびDNSプロトコルの実装の両方が大きく、単一の所有者やメンテナすべてのドメインについて、ドメインに関連付けられたリソースレコードの任意のセットが単一コピー直列化可能な方法で修正されていることがあるという仮定に基づいています。つまり、1つでもドメインは何とかパーティーをuncooperatingによって「共有」することができることを想定している、異なる当事者によって作られたDNS名の定義が競合し、そこにユーザーまたはクライアントが発見できたことにより、DNSプロトコル内には手段ではない、との間で選択。クライアントは、単にそれが要求されたドメインと一致する見つけたリソースレコードの最初のセットを返し、これらが有効であることを前提としています。このプロトコルは、コンピュータシステムの何百万、数百のオペレーティングソフトウェアに組み込まれている、と簡単に共有ドメインのシナリオをサポートするように更新されていません。
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は命名権威Yが奇数文字数でA.Bのすべてのサブドメインを委任し、命名権威Zは、文字の偶数とA.Bのサブドメインを定義するために権限を委任されていたことをされていたことを宣言することができます。このように、ルールの単一のセットは、競合の割り当てを行うことから、YとZを防ぐために合意しなければならないであろう、とアクションのこの列車に単一のユニークなスペースは、どのような場合に作成されています。でも、これは複数の非協力当局が単一のドメイン内の任意のサブドメインを割り当てることができません。
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.
協力と合意された技術的なルールの程度は名前の一意性を保証するために必要とされているようです。 DNSでは、これらのルールは、名前階層のパートごとに独立して設立され、ルートドメインも例外ではありませんされています。このように、根のための規則の一般的合意単一のセットがなければなりません。
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.
ルートゾーンは、他のすべてのDNSゾーンと異なったもので、特定の技術的な点があります：ルートゾーンのネームサーバのアドレスは、アウトオブバンド情報から主に来ます。このアウトオブバンド情報はしばしば不十分DNS内の他のすべてのデータとは異なり、アウトオブバンド情報には自動タイムアウトメカニズムを持っていない、維持しています。この情報は多くのサイトでの日付のうち年とすることは珍しくありません。
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.
直接の結果として、公共ルートゾーンを指定するIPアドレスのリストへの変更は、DNS委譲チェーンの他の側面を変更するよりもはるかに困難です。このため、システムの安定性は公共ルートゾーンの非常に保守的で慎重な管理を求めて：ルートゾーンへの更新の頻度は低く保たなければならないし、ルートゾーンのサーバは、密接に協調しなければなりません。
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.
これらの問題は、DNSセキュリティ拡張[DNSSEC]によりある程度改善することができるが、同様のアウトオブバンド構成の問題は、ルートゾーンへの暗号署名鍵のために存在しているので、ルートゾーンがまだでも密結合と協調管理が必要DNSSECの存在下で行われます。
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.
ユニークなネーミングおよび名前マッピングシステムのDNSタイプは、それが、ユーザーが正確に正しい名前を知らないような位置情報を設計したのなかったいくつかの目的のための理想的ではないかもしれません。インターネットが拡大し続けたように、我々は漠然とまたはあいまいな参照に対処する上でユーザを支援できる進化したディレクトリシステムを期待します。電話番号ポータビリティのインターネットの同等を含む - - DNSとその複数のレコード・タイプの多くの重要な機能を維持するために、我々は、特定の目的のための正しい名前のディレクトリ検索と識別の結果は、そのユニークなDNS名であることを期待しますその後、むしろディレクトリシステムを持つよりも、正常に解決されるDNS「を交換してください」。
There is no getting away from the unique root of the public DNS.
何も離れて公共のDNSの一意のルートからの取得はありません。
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.
このメモはどんな新しいセキュリティ問題を紹介しませんが、それは技術的にナイーブな提案を繰り返しの家族に固有の問題のいくつかを特定しようとしません。
This memo is not intended to create any new issues for IANA.
このメモは、IANAのための新たな問題を作成するものではありません。
[DNS-CONCEPTS] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[DNS-CONCEPTS] Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034、1987年11月。
[DNS-IMPLEMENTATION] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[DNS-IMPLEMENTATION] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[DNSSEC]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
Internet Architecture Board
インターネットアーキテクチャ委員会
EMail: iab@iab.org
メールアドレス：iab@iab.org
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。