RFC2826 日本語訳

Network Working Group                        Internet Architecture Board
Request for Comments: 2826                                      May 2000
Category: Informational

コメントを求めるワーキンググループインターネット・アーキテクチャ委員会の要求をネットワークでつないでください: 2826 2000年5月のカテゴリ: 情報

              IAB Technical Comment on the Unique DNS Root

ユニークなDNS根のIABの技術的なコメント

Status of this Memo

この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.

Copyright(C)インターネット協会(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.

世界的なネットワークのままで残るために、インターネットはグローバルにユニークな公共の名前スペースの存在を必要とします。 スペースというDNS名は単一の、そして、グローバルにユニークな根から得られた階層的な名前スペースです。 これはDNSの技術的な規制設計固有です。 したがって、そこには、公共のDNSの1つ以上の根であることが技術的に可能ではありません。 ユニークな命名権威によって管理された1セットの連携ルートサーバーでその1つの根をサポートしなければなりません。

   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.

単に、ウェブページデザイナーの意志に対するウェブページで同じリンクをクリックする異なったISPのユーザが異なった目的地で終わることができた非常に強い可能性をルーツが上げる複数の公共のDNSに配布して、置きます。

   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命名階層構造の連携ルートサーバーからのその情報をとって来なければなりません。

1.  Detailed Explanation

1. 詳説

   There are several distinct reasons why the DNS requires a single root
   in order to operate properly.

DNSが適切に作動するためにただ一つの根に必要とするいくつかの異なった理由があります。

1.1.  Maintenance of a Common Symbol Set

1.1. 一般的なシンボルのメインテナンスはセットしました。

   Effective communications between two parties requires two essential
   preconditions:

2回のパーティーの有効なコミュニケーションは2つの不可欠の前提条件を必要とします:

IAB                          Informational                      [Page 1]

RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

ユニークなDNS根の2000年5月のIABの情報[1ページ]のRFC2826のIABの技術的なコメント

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

最初の条件を満たさない場合、全く交信しないことを含意します、2番目を満たさない場合コミュニケーションの意味が無くなるのを含意しますが。

   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名に関連しているプロトコルアドレス、ネットワーク資源、およびサービスについて説明する1セットのDNS記録であるに違いないので。 アプリケーションのすべてがインターネットでDNSがこれであると仮定するどの使用を配布したか、そして、インターネットユーザはDNS名からそのような振舞いを予想します。 名前は当時の一定のシンボルです。その解釈は明確にどんな個々のパーティーの文脈に関する知識も必要としません。 名前の意味意図を変更しないで、1回のパーティーから別のパーティーまで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

DNSのためのユニークさの要件が、以来DNSが階層的でドメインに構造化されると全体として命名する、ドメインの中で定義されたそれぞれの名前(サブドメイン)でaがユニークになるのを含意します。

IAB                          Informational                      [Page 2]

RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

ユニークなDNS根の2000年5月のIABの情報[2ページ]のRFC2826のIABの技術的なコメント

   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では、そのドメインに関する各サブドメインには適切な記録があるのを確実にするのにだれが責任があるかがそれと交際しました。 これは政治的選択ではなく、技術的要求事項です。

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.

DNSプロトコルの両方の設計と実装はずっしりとあらゆるドメインへの独身の所有者か維持装置があって、ドメインに関連しているリソース記録のどんなセットもただ一つのコピー直列化可能ファッションで変更されるという仮定に基づいています。 すなわち、パーティーを非協力させることによって単一領域をどうにか「共有できるだろう」と仮定さえして、ユーザかクライアントが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.

将来闘争定義を決議するある他の手段を提供できたと思いさえして、それはあらかじめ確立された客観的な規則に基づかなければならないでしょう。 代表として派遣して、キャラクタの奇数、およびその命名権威ZがあるA.Bに関するすべてのサブドメインがそうでした。例えば、ゾーンA.Bが、権威をYと命名するのがあったと宣言できた、キャラクタの偶数でA.Bに関するサブドメインを定義する代理権。 したがって、1セットの規則は、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では、これらの規則は独自に命名階層構造の各部分に確立されます、そして、根のドメインは例外ではありません。 したがって、根のための一般に、同意された1セットの規則があるに違いありません。

IAB                          Informational                      [Page 3]

RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

ユニークなDNS根の2000年5月のIABの情報[3ページ]のRFC2826のIABの技術的なコメント

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.

ルートゾーンが他のすべてのDNSゾーンと異なっている1つの特定の技術的な敬意があります: ルートゾーンへのネームサーバのアドレスは主としてバンドで出ている情報から来ます。 このバンドで出ている情報はしばしば不十分に保守されます、そして、バンドで出ている情報には、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.

いかなる他のゾーンのようにも、ルートゾーンはサーバを記載する1セットの「ネームサーバ」リソース記録を含んでいますが、現在のルートサーバーのための有効なアドレスのないレゾルバはこれらの記録を決して得ることができないでしょう。 より狡猾に、部分的に有効の混合セットを部分的に持っているレゾルバはバンドの外で情報が言うことができない構成を聞き古したです(闘争答えを取り戻すなら、「本当」のルートサーバーです)。 したがって、それは、悪意があるルートサーバーの状態を取り消すのが非常に難しいか、またはバギーのルートサーバーの周りで発送するために同等です。

   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 Security Extensions[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

ユニークな命名と名前を写像するシステムのDNSタイプはそれが決して設計されなかった多くの目的のために理想的でないかもしれません、ユーザがいつ正確に正名を知らないかというそのような場所を見つけている情報。 インターネットが、広がり続けていて、私たちは、ディレクトリシステムが発展すると予想するでしょう(あいまいであるかあいまいな参照に対処するのにユーザを助けることができます)。 DNSの多くの重要な特徴とその複数のレコード種類--インターネットの電話番号の移植性の同等物を含んでいます--私たちがディレクトリルックアップと識別の結果を予想する保護区

IAB                          Informational                      [Page 4]

RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

ユニークなDNS根の2000年5月のIABの情報[4ページ]のRFC2826のIABの技術的なコメント

   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名であるために名前を修正してください。

   There is no getting away from the unique root of the public DNS.

公共の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. IANA問題

   This memo is not intended to create any new issues for IANA.

このメモがIANAのためにどんな新規発行も作成することを意図しません。

5.  References

5. 参照

   [DNS-CONCEPTS]        Mockapetris, P., "Domain Names - Concepts and
                         Facilities", STD 13, RFC 1034, November 1987.

[DNS-概念]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

   [DNS-IMPLEMENTATION]  Mockapetris, P., "Domain Names - Implementation
                         and Specification", STD 13, RFC 1035, November
                         1987.

[DNS-実装]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日

   [DNSSEC]              Eastlake, D., "Domain Name System Security
                         Extensions", RFC 2535, March 1999.

[DNSSEC] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。

6.  Author's Address

6. 作者のアドレス

   Internet Architecture Board

インターネット・アーキテクチャ委員会

   EMail: iab@iab.org

メール: iab@iab.org

IAB                          Informational                      [Page 5]

RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

ユニークなDNS根の2000年5月のIABの情報[5ページ]のRFC2826のIABの技術的なコメント

7.  Full Copyright Statement

7. 完全な著作権宣言文

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

IAB                          Informational                      [Page 6]

IAB情報です。[6ページ]