RFC2010 日本語訳

Network Working Group                                         B. Manning
Request for Comments: 2010                                           ISI
Category: Informational                                         P. Vixie
                                                                     ISC
                                                            October 1996

コメントを求めるワーキンググループB.マニングの要求をネットワークでつないでください: 2010年のISIカテゴリ: 情報のP.Vixie ISC1996年10月

               Operational Criteria for Root Name Servers

根のネームサーバの操作上の評価基準

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This document specifies the operational requirements of root name
   servers, including host hardware capacities, name server software
   revisions, network connectivity, and physical environment.

このドキュメントは根のネームサーバの操作上の要件を指定します、ホストハードウェア能力、ネームサーバソフトウェア改正、ネットワークの接続性、および物理的環境を含んでいて。

1 - Rationale and Scope

1--原理と範囲

   1.1. Historically, the name servers responsible for the root (".")
   zone have also been responsible for all international top-level
   domains (iTLD's, for example: COM, EDU, INT, ARPA).  These name
   servers have been operated by a cadre of highly capable volunteers,
   and their administration has been loosely coordinated by the NIC
   (first SRI-NIC and now InterNIC).  Ultimate responsibility for the
   correct operation of these servers and for the content of the DNS
   zones they served has always rested with the IANA.

1.1. 歴史的である、根に原因となるネームサーバ、(「」、)、また、ゾーンもすべての国際的な最上位のドメイン(iTLD、例えば、: COM、EDU、INT、アルパ)に原因となっています。 これらのネームサーバは非常に有能なボランティアの枠組みによって操作されました、そして、彼らの管理はNIC(最初に、SRI-NICと現在のInterNIC)によって緩く調整されました。 これらのサーバの正しい操作とそれらが役立ったDNSゾーンの内容への最終責任はいつもIANAに責任がありました。

   1.2. As described in [Postel96], many new TLD's may be created
   shortly.  Servers for all new and existing iTLD's will be subject to
   the operational requirements given in [Postel96].  The set of servers
   for the root (".")  zone is likely to become disjoint from the set of
   servers for any TLD or group of TLD's, including those maintained by
   the InterNIC.

1.2. [Postel96]で説明されるように、新しいTLDの多くのものがまもなく、作成されるかもしれません。 新しくて既存のiTLDのすべてのもののためのサーバは[Postel96]で与えられた操作上の要件を受けることがあるでしょう。 根のためのサーバのセット、(「」、)、ゾーンはどんなTLDのためのサーバのセットかTLDのグループからもばらばらになって、InterNICによって維持されたものを含むようになりそうです。

Manning & Vixie              Informational                      [Page 1]

RFC 2010                    DNSSVR Criteria                 October 1996

[1ページ]RFC2010DNSSVR評価基準1996年10月の情報のマニングとVixie

   1.3. In spite of the similarities in operational requirements between
   the servers for the iTLD's and the servers for the root (".") zone,
   they are in fact different server sets with different administrators
   and slightly different operational requirements. It is likely that
   many contry code tld servers will have even more divergent
   operational requirements. That said, the requirements set down in
   this document could be successfully applied to any name server
   (whether root, top level, or any other level), but may be more
   draconian than necessary for servers other than those of the root
   (".") zone.

1.3. iTLDのもののためのサーバと根のためのサーバの間の操作上の要件の類似性、(「」、)、ゾーン、それらは事実上、異なったサーバが異なった管理者とわずかに異なった操作上の要件でセットするということです。 多くのcontryコードtldサーバには、さらに分岐している操作上の要件がありそうでしょう。 それが言って、置かれる要件が本書では首尾よくどんなネームサーバ(根、トップレベル、またはいかなる他のレベルであることにかかわらず)にも適用できましたが、根のものを除いて、サーバに必要とするより厳しいかもしれない、(「」、)、ゾーン。

   Disclaimer:  The selection of name server locations and
                administrators, and the procedures for addressing
                noncompliance with these stated operational
                requirements, are outside the scope of this document.

注意書き: このドキュメントの範囲の外にネームサーバ位置と管理者の品揃え、およびこれらが述べられている不承諾に操作上の要件を扱うための手順があります。

   Definition:  For the purpose of this document, the term "zone master"
                shall be used to designate the administrative owner of
                the content of a zone.  This person is expected to have
                final responsibility for the selection and correct
                operation of all of the zone's servers.  For the root
                (".") zone, this is the IANA.

定義: このドキュメントの目的において、「ゾーンマスター」という用語は、ゾーンの内容の管理所有者を任命するのに使用されるものとします。 この人にはゾーンのサーバのすべての選択と正しい操作への最終責任があると予想されます。 根、(「」、)、帯状になってください、そして、これはIANAです。

2 - Operational Requirements

2--操作上の要件

   2.1. Name server software.  The zone master shall initially and
   periodically choose a name server package to run on all of the zone's
   servers.  It is expected that the BIND server will be used, at least
   initially, and that new versions or other servers will be specified
   from time to time.

2.1. ネームサーバソフトウェア。 ゾーンマスターは、ゾーンのサーバのすべてで走るために初めは、そして定期的にネームサーバパッケージを選ぶものとします。 BINDサーバが少なくとも初めは、使用されて、新しいバージョンか他のサーバが時々指定されると予想されます。

     Rationale:  This requirement is based on the wide and free
                 availability of BIND's source code, and the active
                 analysis and development it constantly receives from
                 several members of the IETF.

原理: この要件はそれがIETFの数人のメンバーから絶えず受け取るBINDのソースコードの広くて無料の有用性、活動分析、および開発に基づいています。

   Name server software upgrades will be specified and scheduled by the
   zone master, and must occur on all of a zone's servers within a
   specified 96 hour window.

ネームサーバソフトウェアの更新は、ゾーンマスターによって指定されて、予定されて、96時間の指定された窓の中にゾーンのサーバのすべてに起こらなければなりません。

     Rationale:  In some cases it has proven necessary to "cold start" a
                 zone's servers in order to clear out oscillating bad
                 data.  By forcing all software upgrades to happen at
                 about the same time, it will be possible to coordinate
                 a software change with a zone content change.

原理: いくつかの場合、それは、外で振動している悪いデータをクリアするために「という寒さが」 ゾーンのものを始めであるサーバに必要であると判明しました。 すべてのソフトウェアの更新をほぼ同じ頃起こらせることによって、ゾーン内容変化でソフトウェア変化を調整するのは可能でしょう。

Manning & Vixie              Informational                      [Page 2]

RFC 2010                    DNSSVR Criteria                 October 1996

[2ページ]RFC2010DNSSVR評価基準1996年10月の情報のマニングとVixie

   2.2. UDP checksums.  UDP checksums must be generated when sending
   datagrams, and verified when receiving them.

2.2. UDPチェックサムそれらを受けるとき、UDPチェックサムをデータグラムを送るとき、生成されて、確かめなければなりません。

     Rationale:  Some vendors turn off UDP checksums for performance
                 reasons, citing the presence of MAC-level frame checks
                 (CRC, for example) as "strong enough."  This has been
                 a disaster in actual practice.

原理: いくつかのベンダーが性能理由でUDPチェックサムをオフにします、「十分強い」としてMAC-レベルフレームチェック(例えば、CRC)の存在を引用して。 これは実際行なわれているところでは災害です。

   2.3. Dedicated host.  A name server host should have no other
   function, and no login accounts other than for system or network
   administrators.  No other network protocols should be served by a
   name server host (e.g., SMTP, NNTP, FTP, et al).  If login is
   permitted from other than the system console, then the login service
   must be by encrypted channel (e.g., Kerberized and encrypted
   rlogin/telnet, the secure shell (SSH), or an equivilent).

2.3. ひたむきなホスト。 ネームサーバホストには、システムかネットワーク管理者以外に、他の機能がなく、およびログインアカウントが全くあるべきではありません。 ネームサーバホスト(例えば、SMTP、NNTP、FTP、他)は他のネットワーク・プロトコルに全く勤めるべきではありません。 システム操作卓を除いて、ログインから受入れられるなら、暗号化されたチャンネル(例えば、Kerberizedと暗号化されたrlogin/telnetか、セキュア・シェル(SSH)か、equivilent)でログインサービスがあるに違いありません。

     Rationale:  Each additional service performed by a host makes it
                 less reliable and potentially less secure, as well as
                 complicating fault isolation procedures.  While name
                 service does not consume very much in the way of system
                 resources, it is thought best that a host do a few
                 things well rather than many things poorly.

原理: ホストによって実行されたそれぞれの追加サービスで、それは欠点隔離技法を複雑にすることと同様に、それほど信頼できないでまた潜在的により安全でなくなります。 名前サービスがシステム資源の方法でまさしくそのいろいろな事を消費していない間、ホストが不十分にいくつかの多くであるというよりむしろ良いものに事態をするのは最も良いと考えられます。

   2.4. Clock synchronization.  A name server host should synchronize
   its clock using the NTP protocol (currnet version) with
   authentication.  At least two NTP servers should be used.  As an
   exception to section 2.3 above, a name server host can be an NTP
   server as well.

2.4. 同期の時間を計ってください。 ネームサーバホストは、認証があるNTPプロトコル(currnetバージョン)を使用することで時計を連動させるべきです。 少なくとも2つのNTPサーバが使用されるべきです。 セクション2.3への例外として、上では、ネームサーバホストがまた、NTPサーバであるかもしれません。

     Rationale:  For distributed fault isolation reasons, synchronized
                 time stamps in system event logs are quite helpful.
                 NTP is easily spoofed by UDP blast attacks, thus the
                 requirement for authentication between the name server
                 host and its NTP servers.  A name server host is
                 allowed to be an NTP server because it has been
                 observed that a single host running both name service
                 and stratum 1 NTP is still quite reliable and secure.

原理: 分配された欠点分離理由で、システムイベントログの連動しているタイムスタンプはかなり役立っています。 NTPはその結果、UDP爆破攻撃、ネームサーバホストとそのNTPサーバの間の認証のための要件によって容易に偽造されます。 ネームサーバホストは単一のホスト実行がともにサービスと層を1NTPと命名するのが観測されたので、NTPサーバがまだかなり高信頼であって、安全であるということであることが許容されています。

   2.5. Network interfaces.  Name servers must send UDP responses with
   an IP source address (and UDP source port number) equal to the IP
   destination address (and UDP destination port number) of the request.
   Also, a name server might have multiple real interfaces, but only one
   will be advertised in the zone's NS RRset and associated glue A RRs.
   The advertised address should be that of the "best" interface on the
   host, in terms of network performance and reliability to the largest
   number of destinations.

2.5. インタフェースをネットワークでつないでください。 ネームサーバは要求の受信者IPアドレス(そして、UDP目的地ポートナンバー)と等しいIPソースアドレス(そして、UDPソースポート番号)による応答をUDPに送らなければなりません。 また、ネームサーバには、複数の本当のインタフェースがあるかもしれませんが、ゾーンのNS RRsetと関連接着剤A RRsに1つだけの広告を出すでしょう。 広告を出しているアドレスはホストにおける「最も良い」インタフェースのものであるべきです、目的地の最多数へのネットワーク性能と信頼性に関して。

Manning & Vixie              Informational                      [Page 3]

RFC 2010                    DNSSVR Criteria                 October 1996

[3ページ]RFC2010DNSSVR評価基準1996年10月の情報のマニングとVixie

     Rationale:  While not required by [RFC1035], many extant DNS
                 implementations require the source address and port of
                 a reply to match the destination address and port to
                 which the request was sent.  The number of advertised
                 addresses is limited to one (1) so that DNS delegation
                 responses containing this name server can be as short
                 as possible.

原理: [RFC1035]は必要でない間、多くの実在のDNS実装が、要求が送られた送付先アドレスとポートを合わせるために回答のソースアドレスとポートを必要とします。 広告を出しているアドレスの数は、このネームサーバを含むDNS委譲応答ができるだけ短くなるように、1つ(1)に制限されます。

   2.6. Physical environment.  A name server host must be located in a
   secure space such as a locked computer room or a data center with
   restricted access.  The power supply should be redundant, using
   batteries, generators or some other means to protect against utility
   power failures.  Network connectivity should be redundant, so that a
   single wide area line failure cannot completely isolate the name
   server host from the rest of the network.

2.6. 物理的環境。 ネームサーバホストは固定コンピュータ室か制限されたアクセサリーがあるデータセンターなどの安全なスペースに位置しなければなりません。 バッテリー、ジェネレータまたはユーティリティ停電から守るある他の手段を使用して、電源は余分であるべきです。 ネットワークの接続性は余分であるべきです、ただ一つの広い領域系列失敗はネットワークの残りからネームサーバホストを完全に隔離できるというわけではありません。

   2.7. Network security.  The system and network administrators should
   educate themselves about potential threats, and stay current on CERT
   bulletins regarding network breakins.  The system staff should
   periodically audit the name server host's activity logs and be able
   to detect breakins during or after the fact.

2.7. セキュリティをネットワークでつないでください。 システムとネットワーク管理者は、潜在的な脅威に関して独学して、ネットワークbreakinsに関するCERT報告で現在のままであるべきです。 システムスタッフは、定期的にネームサーバホストの活動記録を監査して、事実か事実の後にbreakinsを検出できるべきです。

   2.8. Host performance.  As of the time of this writing, a name server
   must be able to answer 1,200 UDP transactions per second with less
   than 5 milliseconds of average latency.  Because the network is still
   growing at a high rate, the ability to grow to 2,000 transactions per
   second and still support a 5 millisecond latency is highly desirable.
   Note that this requirement affects both the host and the network
   infrastructure to which that host is attached.

2.8. 性能を主催してください。 この書くことの時現在、ネームサーバは5ミリセカンド未満の平均した潜在で1秒あたり1,200のUDPトランザクションに答えることができなければなりません。 ネットワークがまだ高価で成長しているので、1秒あたり2,000のトランザクションまで成長して、まだ5ミリセカンドの潜在をサポートしている能力は非常に望ましいです。 この要件がそのホストが付けているホストとネットワークインフラの両方に影響することに注意してください。

   2.9. Response time.  The administrators responsible for a name server
   will respond to e-mail trouble reports within 24 hours.  Personnel
   issues such as vacations and illness will cause responsibilities to
   be delegated and/or reassigned rather than ignored.  After hours
   telephone numbers must be made available to the zone master for
   nonpublished use in emergencies.  An escalation contact name, e-mail
   address, and telephone number will also be made available to the zone
   master in the event of nonresponse through the normal channel.

2.9. 応答時間。 ネームサーバに責任がある管理者は、24時間以内に問題レポートをメールするために応じるでしょう。 休暇や病気などの人員問題は無視されるよりむしろ代表として派遣しているそして/または、再選任されるべき責任を引き起こすでしょう。 何時間も後に、非常時に電話番号をゾーンマスターに非発行された使用に利用可能にしなければなりません。 また、増大連絡名、Eメールアドレス、および電話番号を「非-応答」の場合、ゾーンマスターに正規販売経路で利用可能にするでしょう。

   2.10. Zone transfer access control.  The name server shall be
   configured so that outbound zone transfers are permitted only to
   destinations on the server's local networks, and to whichever
   networks the zone master designates for remote debugging purposes.

2.10. ゾーン転送アクセスコントロール。 ネームサーバが構成されるものとするので、外国行きのゾーン転送はサーバの企業内情報通信網の目的地だけと、そして、ゾーンマスターが遠隔デバッギング目的のために指定するネットワークに受入れられます。

Manning & Vixie              Informational                      [Page 4]

RFC 2010                    DNSSVR Criteria                 October 1996

[4ページ]RFC2010DNSSVR評価基準1996年10月の情報のマニングとVixie

     Rationale:  Zone transfers can present a significant load on a name
                 server, especially if several transfers are started
                 simultaneously against the same server.  There is no
                 operational reason to allow anyone outside the name
                 server's and zone's administrators to transfer the
                 entire zone.

原理: ゾーン転送はネームサーバにかなりの負荷を提示できます、特に数回の転送が同時に同じサーバに対して始められるなら。ネームサーバとゾーンの管理者の外のだれでも全体のゾーンを移すのを許容するどんな操作上の理由もありません。

   2.11. Zone transfer protocol.  DNS AXFR shall be used in preference
   to FTP or any other non-DNS transfer protocol.  DNS NOTIFY (see
   [NOTIFY]) and DNS IXFR (see [IXFR]) shall be supported and enabled
   when available.

2.11. ゾーン転送プロトコル。 DNS AXFRはFTPかいかなる他の非DNS転送プロトコルに優先して使用されるものとします。 利用可能であるときに、DNS NOTIFY([NOTIFY]を見る)とDNS IXFR([IXFR]を見る)はサポートされて、有効にされるものとします。

     Rationale:  Historically, the common implementations of DNS
                 (a.k.a., BIND) did not support zone transfer of the
                 root (".") zone due to programming errors.  Thus, FTP
                 was used.  In the future, DNS implementations which do
                 not support zone transfer of all zones will not be
                 considered suitable for use as root name servers.  The
                 benefits of [IXFR] and [NOTIFY] should be obvious.

原理: 歴史的に、DNS(通称BIND)の一般的な実装が根のゾーン転送をサポートしなかった、(「」、)、プログラミング・エラーによるゾーン。 したがって、FTPは使用されました。 将来、すべてのゾーンのゾーン転送をサポートしないDNS実装は根のネームサーバとして使用に適していると考えられないでしょう。 [IXFR]と[NOTIFY]の利益は明白であるべきです。

   2.12. Recursion shall be disabled for queries.

2.12. 再帰は質問のために無効にされるものとします。

     Rationale:  Recursion is a major source of cache pollution, and can
                 be a major drain on name server performance.  An
                 organization's recursive DNS needs should be served by
                 some other host than its root name server(s).  An
                 exception is made for missing glue since it's possible
                 that glue needed for some delegations will not be
                 within or beneath any zone for which the server is
                 authoritative.  Such glue must be fetched via
                 recursive lookups to other servers.

原理: 再帰は、キャッシュ汚染の主要な源であり、ネームサーバ性能の主要なドレインであるかもしれません。 DNSが必要とする組織のリカーシブは根のネームサーバよりある他のホストによって勤められるべきです。 ゾーン以内かサーバが正式であるどんなゾーンの下にもいくつかの委譲に必要であるその接着剤がないのが、可能であるので、例外はなくなった接着剤のために作られています。 他のサーバへの再帰的なルックアップでそのような接着剤をとって来なければなりません。

   2.13. Outages shall be reported.  All outages, scheduled or not,
   shall be reported to the zone master via e-mail.  If an outage is
   unscheduled or if an outage is scheduled less than 24 hours in
   advance, then an additional notification of the zone master shall be
   made via telephone.  Extended or repeated outages may beget special
   handling by the zone master.

2.13. 供給停止は報告されるものとします。 すべての予定されている供給停止がメールでゾーンマスターに報告されるものとします。 供給停止が予定外である、または24時間未満早く供給停止を予定しているなら、電話を通してゾーンマスターの追加通知をするものとします。 広げられたか繰り返された供給停止はゾーンマスターによる特別な取り扱いを生み出すかもしれません。

   2.14. Inverse name lookups.  The PTR RR associated with a server's
   primary interface address (that is, the address shown in in the
   zone's delegation) shall have its target specified by the zone
   master.

2.14. 逆さの名前ルックアップ。 サーバの主要インターフェースアドレス(すなわち、ゾーンの委譲で目立つアドレス)に関連しているPTR RRはゾーンマスターに目標を指定させるものとします。

Manning & Vixie              Informational                      [Page 5]

RFC 2010                    DNSSVR Criteria                 October 1996

[5ページ]RFC2010DNSSVR評価基準1996年10月の情報のマニングとVixie

     Rationale:  Since each organization has local control of their
                 network's PTR RRs, and since it is necessary for the
                 correct operation of some software that the forward and
                 reverse lookups have symmetrical results, it is left
                 up to the zone master to select the name for each
                 authority server's primary address.

原理: 各組織にはそれらのネットワークのPTR RRsの現場制御があって、前進の、そして、逆のルックアップに対称の結果があるのが何らかのソフトウェアの正しい操作に必要であるので、それはそれぞれの権威サーバのプライマリアドレスのために名前を選択するのがゾーンマスターに任せられます。

3 - Possible Selection Criteria

3--可能な選択評価基準

   3.1. Host population.  A server's location on the network should be
   such that it has a low IP hop count to a high number of end hosts.
   Duplication of service should be avoided, such that any given set of
   end hosts needs to have a low IP hop count to at most one authority
   server for any given zone.

3.1. 人口を接待してください。 ネットワークのサーバの位置がそのようなものであるべきであるので、低いIPホップはそれで大きい数の終わりのホストまで数えます。 サービスの重複は避けられるべきです、どんな与えられたセットの終わりのホストも、低いIPホップにどんな与えられたゾーンのためにも1つの権威サーバまで高々数えさせる必要があるように。

   3.2. Infrastructure diversity.  A server's location on the network
   should be such that most failures capable of isolating it from a
   large number of end hosts are diverse from the failures capable of
   similarly isolating other authority servers for the same zone(s).

3.2. インフラストラクチャの多様性。 ネットワークのサーバの位置がそのようなものであるべきであるので、多くの終わりのホストからそれを隔離できるほとんどの失敗が同様に他の権威サーバを同じゾーンに隔離できる失敗からさまざまです。

4 - Security Considerations

4--セキュリティ問題

   See section 2.7.

セクション2.7を見てください。

5 - References

5--参照

   [RFC1035]
      Mockapetris, P., "Domain Names - Implementation and Specification",
      STD 13, RFC 1035, USC/Information Sciences Institute, November
      1987.

[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、科学が設けるUSC/情報、11月1987日

   [Postel96]
      Postel, J., "New Registries and the Delegation of International Top
      Level Domains", Work in Progress.

[Postel96] ポステルと、J.と、「国際トップ・レベル・ドメインの新しい登録と委譲」は進行中で働いています。

   [IXFR]
      Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.

[IXFR] 太田、M.、「増加のゾーン転送」、RFC1995、1996年8月。

   [NOTIFY]
      Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
      RFC 1996, August 1996.

[通知します] Vixie、P.、「ゾーン変化の迅速な通知のためのメカニズム」、RFC1996、1996年8月。

6 - Acknowledgements

6--承認

   Constructive comments have been received from:  Jon Postel, Michael
   Patton, Andrew Partan, Michael Dillon, Don Mitchell Steven Doyle,
   Owen DeLong and other members of the internet community.

以下から建設的なコメントを受けました。 ジョン・ポステル、マイケル・パットン、アンドリューPartan、マイケル・ディロン、ドン・ミッチェル・スティーブン・ドイル、オーエンDeLong、およびインターネット共同体の他のメンバー。

Manning & Vixie              Informational                      [Page 6]

RFC 2010                    DNSSVR Criteria                 October 1996

[6ページ]RFC2010DNSSVR評価基準1996年10月の情報のマニングとVixie

7 - Authors' Addresses

7 --作者のアドレス

     Bill Manning
     USC/ISI
     4676 Admiralty Way
     Marina del Rey, CA 90292

ビルマニングUSC/ISI4676海軍本部Wayマリナデルレイ、カリフォルニア 90292

     Phone: +1 310 822 1511
     EMail: bmanning@isi.edu

以下に電話をしてください。 +1 1511年の310 822メール: bmanning@isi.edu

     Paul Vixie
     Internet Software Consortium
     Star Route Box 159A
     Woodside, CA 94062

ポールVixieインターネットソフトウェア共同体星のルート箱の159Aウッドサイド、カリフォルニア 94062

     Phone: +1 415 747 0204
     EMail: paul@vix.com

以下に電話をしてください。 +1 0204年の415 747メール: paul@vix.com

Manning & Vixie              Informational                      [Page 7]

マニングとVixie情報です。[7ページ]