RFC2870 日本語訳
2870 Root Name Server Operational Requirements. R. Bush, D.Karrenberg, M. Kosters, R. Plzak. June 2000. (Format: TXT=21133 bytes) (Obsoletes RFC2010) (Also BCP0040) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Bush
Request for Comments: 2870 Verio
Obsoletes: 2010 D. Karrenberg
BCP: 40 RIPE NCC
Category: Best Current Practice M. Kosters
Network Solutions
R. Plzak
SAIC
June 2000
コメントを求めるワーキンググループR.ブッシュの要求をネットワークでつないでください: 2870Verioは以下を時代遅れにします。 2010D.Karrenberg BCP: 40の熟しているNCCカテゴリ: 最も良い現在の練習のKostersネットワークソリューションR.Plzak SAIC M.2000年6月
Root Name Server Operational Requirements
ネームサーバの操作上の要件を根づかせてください。
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
As the internet becomes increasingly critical to the world's social and economic infrastructure, attention has rightly focused on the correct, safe, reliable, and secure operation of the internet infrastructure itself. The root domain name servers are seen as a crucial part of that technical infrastructure. The primary focus of this document is to provide guidelines for operation of the root name servers. Other major zone server operators (gTLDs, ccTLDs, major zones) may also find it useful. These guidelines are intended to meet the perceived societal needs without overly prescribing technical details.
インターネットがますます世界の社会的で経済のインフラストラクチャに重要になるのに従って、注意は正しくインターネットインフラストラクチャ自体の正しくて、安全で、信頼できて、安全な操作に焦点を合わせました。 根のドメイン名サーバはその技術インフラの重要な部分と考えられます。 このドキュメントの焦点は根のネームサーバの操作のためのガイドラインを提供することになっています。 また、他の一流のゾーンのサーバオペレータ(gTLDs、ccTLDs、主要なゾーン)は、それが役に立つのがわかるかもしれません。 これらのガイドラインが技術的詳細をひどく定めないで知覚された社会の需要を満たすことを意図します。
1. Background
1. バックグラウンド
The resolution of domain names on the internet is critically dependent on the proper, safe, and secure operation of the root domain name servers. Currently, these dozen or so servers are provided and operated by a very competent and trusted group of volunteers. This document does not propose to change that, but merely to provide formal guidelines so that the community understands how and why this is done.
インターネットにおけるドメイン名の解決は批判的に根のドメイン名サーバの適切で、安全で、安全な操作に依存しています。 現在、これらのおよそダースのサーバは、非常に有能で信じられたボランティア・グループによって提供されて、運用されます。 このドキュメントがそれを変えるために提案するのではなく、単に正式なガイドラインを提供するために提案して、共同体は、これがどのように、なぜ完了しているかを理解しています。
Bush, et al. Best Current Practice [Page 1] RFC 2870 Root Name Server Operational Requirements June 2000
ブッシュ、他 要件2000年6月の操作上の最も良い現在の習慣[1ページ]RFC2870根のネームサーバ
1.1 The Internet Corporation for Assigned Names and Numbers (ICANN)
has become responsible for the operation of the root servers.
The ICANN has appointed a Root Server System Advisory Committee
(RSSAC) to give technical and operational advice to the ICANN
board. The ICANN and the RSSAC look to the IETF to provide
engineering standards.
1.1 アイキャン(ICANN)はルートサーバーの操作に責任があるようになりました。 ICANNは、技術的で操作上のアドバイスをICANNボードに与えるために、Root Server System Advisory Committee(RSSAC)を任命しました。 ICANNとRSSACは、IETFがエンジニアリング基準を提供するのを当てにします。
1.2 The root servers serve the root, aka ".", zone. Although today
some of the root servers also serve some TLDs (top level domains)
such as gTLDs (COM, NET, ORG, etc.), infrastructural TLDs such as
INT and IN-ADDR.ARPA, and some ccTLDs (country code TLDs, e.g. SE
for Sweden), this is likely to change (see 2.5).
1.2 「ルートサーバーは通称根に役立つ」、」、ゾーン。 また、ルートサーバーのいくつかが今日gTLDs(COM、NET、ORGなど)や、INTやIN-ADDR.ARPAなどのインフラストラクチャのTLDsや、いくつかのccTLDs(国名略号TLDs、例えば、スウェーデンへのSE)などのいくつかのTLDs(トップ・レベル・ドメイン)に役立ちますが、これは変化しそうです(2.5を見てください)。
1.3 The root servers are neither involved with nor dependent upon the
'whois' data.
1.3 ルートサーバーはかかわって'whois'に依存しないどちらのデータであるのも。
1.4 The domain name system has proven to be sufficiently robust that
we are confident that the, presumably temporary, loss of most of
the root servers should not significantly affect operation of the
internet.
私たちがドメイン名システムが十分強健であると立証した1.4である、自信がある、それ、おそらく、一時的であることで、ルートサーバーの大部分の損失はインターネットの操作にかなり影響するべきではありません。
1.5 Experience has shown that the internet is quite vulnerable to
incorrect data in the root zone or TLDs. Hence authentication,
validation, and security of these data are of great concern.
1.5 経験は、インターネットがルートゾーンかTLDsの間違ったデータに全く被害を受け易いのを示しました。 したがって、これらのデータの認証、合法化、およびセキュリティは大きな心配のものです。
2. The Servers Themselves
2. サーバ自体
The following are requirements for the technical details of the root servers themselves:
↓これはルートサーバー自体に関する技術的詳細のための要件です:
2.1 It would be short-sighted of this document to specify particular
hardware, operating systems, or name serving software.
Variations in these areas would actually add overall robustness.
2.1 このドキュメントでは、特定のハードウェア、オペレーティングシステム、または名前給仕ソフトウェアを指定するのは近視でしょう。 これらの領域の変化は実際に総合的な丈夫さを加えるでしょう。
2.2 Each server MUST run software which correctly implements the IETF
standards for the DNS, currently [RFC1035] [RFC2181]. While
there are no formal test suites for standards compliance, the
maintainers of software used on root servers are expected to take
all reasonable actions to conform to the IETF's then current
documented expectations.
2.2 各サーバは正しくDNS、現在の[RFC1035][RFC2181]のIETF規格を実装するソフトウェアを動かさなければなりません。 規格コンプライアンスのための形式テストスイートが全くない間、ルートサーバーで使用されるソフトウェアの維持装置がIETFのものに従うためにすべての合理的な行動を取ると予想されて、次に、電流は期待を記録しました。
2.3 At any time, each server MUST be able to handle a load of
requests for root data which is three times the measured peak of
such requests on the most loaded server in then current normal
conditions. This is usually expressed in requests per second.
This is intended to ensure continued operation of root services
should two thirds of the servers be taken out of operation,
whether by intent, accident, or malice.
2.3 いつでも、それぞれのサーバは次に、現在の正常な状態で最もロードされたサーバに関するそのような要求の測定ピークの3倍である根のデータに関する要求の負荷を扱うことができなければなりません。 通常、これは1秒あたりの要求で言い表されます。 サーバの2/3が故意に、操作から取り出された事故、または悪意であるならこれが根のサービスの継続運転を確実にすることを意図します。
Bush, et al. Best Current Practice [Page 2] RFC 2870 Root Name Server Operational Requirements June 2000
ブッシュ、他 要件2000年6月の操作上の最も良い現在の習慣[2ページ]RFC2870根のネームサーバ
2.4 Each root server should have sufficient connectivity to the
internet to support the bandwidth needs of the above requirement.
Connectivity to the internet SHOULD be as diverse as possible.
2.4 各ルートサーバーは帯域幅が上記の要件の必要性であるとサポートすることができるくらいの接続性をインターネットに持つべきです。 接続性、インターネットSHOULDに、できるだけさまざまにしてください。
Root servers SHOULD have mechanisms in place to accept IP
connectivity to the root server from any internet provider
delivering connectivity at their own cost.
ルートサーバーSHOULDは、それら自身の費用における接続性を提供しながらIPの接続性をどんなインターネットプロバイダーからもルートサーバーに受け入れるために適所にメカニズムを持っています。
2.5 Servers MUST provide authoritative responses only from the zones
they serve. The servers MUST disable recursive lookup,
forwarding, or any other function that may allow them to provide
cached answers. They also MUST NOT provide secondary service for
any zones other than the root and root-servers.net zones. These
restrictions help prevent undue load on the root servers and
reduce the chance of their caching incorrect data.
2.5のサーバが単にそれらが役立つゾーンから正式の応答を提供しなければなりません。 サーバは再帰的なルックアップ、推進、またはそれらがキャッシュされた答えを提供できるかもしれないいかなる他の機能も無効にしなければなりません。 また、彼らは根と根-servers.netゾーン以外のどんなゾーンのためのセカンダリサービスも提供してはいけません。 これらの制限は、ルートサーバーで過度の負荷を防ぐのを助けて、間違ったデータをキャッシュするという可能性を小さくします。
2.6 Root servers MUST answer queries from any internet host, i.e. may
not block root name resolution from any valid IP address, except
in the case of queries causing operational problems, in which
case the blocking SHOULD last only as long as the problem, and be
as specific as reasonably possible.
2.6のルートサーバーがどんなインターネットホストからも質問に答えなければなりません、すなわち、その場合、運転上の問題を引き起こす質問、ブロッキングSHOULDに関するケース以外のどんな有効なIPアドレスからのブロック根の名前解決も問題と同じくらい長い間だけ、続きませんように、そして、合理的にできるだけ特定であってください。
2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer,
queries from clients other than other root servers. This
restriction is intended to, among other things, prevent
unnecessary load on the root servers as advice has been heard
such as "To avoid having a corruptible cache, make your server a
stealth secondary for the root zone." The root servers MAY put
the root zone up for ftp or other access on one or more less
critical servers.
2.7はSHOULD NOT答えAXFR、または他のゾーン転送が他のルートサーバー以外のクライアントから質問するサーバを根づかせます。 アドバイスが「腐敗しやすいキャッシュを持っているのを避けるには、サーバをルートゾーンにおける、セカンダリの窃盗にしてください」などのように聞かれたようにこの制限がルートサーバーで不要な負荷を特に防ぐことを意図します。 ルートサーバーはftpか他のアクセスのために1つ以上のそれほど重要でないサーバでルートゾーンを提供するかもしれません。
2.8 Servers MUST generate checksums when sending UDP datagrams and
MUST verify checksums when receiving UDP datagrams containing a
non-zero checksum.
2.8のサーバが、データグラムをUDPに送るとき、チェックサムを生成しなければならなくて、非ゼロチェックサムを含むUDPデータグラムを受けるとき、チェックサムについて確かめなければなりません。
3. Security Considerations
3. セキュリティ問題
The servers need both physical and protocol security as well as unambiguous authentication of their responses.
サーバは物理的、そして、プロトコルセキュリティと彼らの応答の明白な認証の両方を必要とします。
3.1 Physical security MUST be ensured in a manner expected of data
centers critical to a major enterprise.
3.1 大企業に重要なデータセンターに予想された方法で物理的なセキュリティを確実にしなければなりません。
3.1.1 Whether or not the overall site in which a root server is
located has access control, the specific area in which the
root server is located MUST have positive access control,
i.e. the number of individuals permitted access to the
area MUST be limited, controlled, and recorded. At a
すなわち、その領域へのアクセスが受入れられた個体数は、3.1.1 ルートサーバーが位置している総合的なサイトがアクセスコントロールを持っているか否かに関係なく、ルートサーバーが位置している特定の領域が積極的なアクセスコントロールを持たなければならなくて、限られて、制御されて、記録していなければなりません。 aで
Bush, et al. Best Current Practice [Page 3] RFC 2870 Root Name Server Operational Requirements June 2000
ブッシュ、他 要件2000年6月の操作上の最も良い現在の習慣[3ページ]RFC2870根のネームサーバ
minimum, control measures SHOULD be either mechanical or
electronic locks. Physical security MAY be enhanced by
the use of intrusion detection and motion sensors,
multiple serial access points, security personnel, etc.
最小限、コントロールはどちらかが機械的であるか電子の錠であったならSHOULDを測定します。 物理的なセキュリティは侵入検出と運動センサー、複数のシリアルアクセスポイント、保安要員などの使用で高められるかもしれません。
3.1.2 Unless there is documentable experience that the local
power grid is more reliable than the MTBF of a UPS (i.e.
five to ten years), power continuity for at least 48 hours
MUST be assured, whether through on-site batteries, on-
site power generation, or some combination thereof. This
MUST supply the server itself, as well as the
infrastructure necessary to connect the server to the
internet. There MUST be procedures which ensure that
power fallback mechanisms and supplies are tested no less
frequently than the specifications and recommendations of
the manufacturer.
3.1.2 地方の送電網が経験ですが、「ドキュメント-可能」がUPSのMTBFより信頼できる(すなわち、5〜10年)の間ない場合、少なくとも48時間のパワーの連続を保証しなければなりません、現場のバッテリーを通してか否かに関係なく、オンです。サイト発電、またはそれの何らかの組み合わせ。 これはサーバをインターネットに関連づけるのに必要なサーバ自体、およびインフラストラクチャを供給しなければなりません。 パワー後退メカニズムと供給がメーカーの仕様と推薦より頻繁にテストされるのを確実にする手順があるに違いありません。
3.1.3 Fire detection and/or retardation MUST be provided.
3.1.3 火災の感知、そして/または、遅れを提供しなければなりません。
3.1.4 Provision MUST be made for rapid return to operation after
a system outage. This SHOULD involve backup of systems
software and configuration. But SHOULD also involve
backup hardware which is pre-configured and ready to take
over operation, which MAY require manual procedures.
3.1.4 システム機能の停止の後に操作への急速なリターンに備えなければなりません。 このSHOULDはシステム・ソフトウェアと構成のバックアップにかかわります。 しかし、また、SHOULDはあらかじめ設定されて、操作を引き継ぐ準備ができているバックアップハードウェアにかかわります。操作は手作業を必要とするかもしれません。
3.2 Network security should be of the level provided for critical
infrastructure of a major commercial enterprise.
3.2 ネットワークセキュリティは主要な営利事業の重要インフラに提供されたレベルのものであるべきです。
3.2.1 The root servers themselves MUST NOT provide services
other than root name service e.g. remote internet
protocols such as http, telnet, rlogin, ftp, etc. The
only login accounts permitted should be for the server
administrator(s). "Root" or "privileged user" access MUST
NOT be permitted except through an intermediate user
account.
3.2.1 ルートサーバー自体は例えばhttp、telnet、rlogin、ftpなどのリモートインターネットプロトコルを根の名前サービス以外のサービスに提供してはいけません。 アカウントが可能にした唯一のログインがサーバアドミニストレータのためのものであるべきです。 中間的ユーザアカウント以外に、「根」か「特権ユーザ」アクセスを受入れてはいけません。
Servers MUST have a secure mechanism for remote
administrative access and maintenance. Failures happen;
given the 24x7 support requirement (per 4.5), there will
be times when something breaks badly enough that senior
wizards will have to connect remotely. Remote logins MUST
be protected by a secure means that is strongly
authenticated and encrypted, and sites from which remote
login is allowed MUST be protected and hardened.
サーバには、リモート管理アクセスとメインテナンスのための安全なメカニズムがなければなりません。 失敗は起こります。 24×7サポート要件(4.5あたりの)を考えて、何かが先任のウィザードが離れて接続しなければならないほどひどく壊れる回があるでしょう。 強く認証されて、暗号化される安全な手段でリモート・ログインを保護しなければならなくて、リモート・ログインが許容されているサイトを保護されて、堅くしなければなりません。
3.2.2 Root name servers SHOULD NOT trust other hosts, except
secondary servers trusting the primary server, for matters
of authentication, encryption keys, or other access or
または3.2.2 根のネームサーバSHOULD NOTは他のホストを信じます、プライマリサーバを信じるセカンダリサーバを除いて、認証の問題、暗号化キー、または他のアクセスのために。
Bush, et al. Best Current Practice [Page 4] RFC 2870 Root Name Server Operational Requirements June 2000
ブッシュ、他 要件2000年6月の操作上の最も良い現在の習慣[4ページ]RFC2870根のネームサーバ
security information. If a root operator uses kerberos
authentication to manage access to the root server, then
the associated kerberos key server MUST be protected with
the same prudence as the root server itself. This applies
to all related services which are trusted in any manner.
セキュリティ情報。 根のオペレータがルートサーバーへのアクセスを管理するのにkerberos認証を使用するなら、ルートサーバー自体と同じ思慮で関連kerberos主要なサーバを保護しなければなりません。 これはどんな方法でも信じられるすべての関連するサービスに適用されます。
3.2.3 The LAN segment(s) on which a root server is homed MUST
NOT also home crackable hosts. I.e. the LAN segments
should be switched or routed so there is no possibility of
masquerading. Some LAN switches aren't suitable for
security purposes, there have been published attacks on
their filtering. While these can often be prevented by
careful configuration, extreme prudence is recommended.
It is best if the LAN segment simply does not have any
other hosts on it.
3.2.3 LANセグメントがルートサーバーがどれであるかに関して家へ帰った、ホーム「割-可能」ホストもそうしなければなりません。 すなわち、LANセグメントが切り換えられるべきであるか、または発送されるべきであるので、仮装する可能性が全くありません。 いくつかのLANスイッチがセキュリティ目的に適していない、それらのフィルタリングに対する攻撃は発行されました。 しばしば慎重な構成でこれらを防ぐことができますが、極端な思慮はお勧めです。 LANセグメントに他のホストがそれに絶対にいないなら、最も良いです。
3.2.4 The LAN segment(s) on which a root server is homed SHOULD
be separately firewalled or packet filtered to discourage
network access to any port other than those needed for
name service.
3.2.4 ルートサーバーがそうであるLANセグメントは家へ帰りました。firewalledされて、SHOULDは別々にそうかそれら以外のどんなポートへのネットワークアクセスにも水をさしているためにフィルターにかけられたパケットが名前にサービスを必要としました。
3.2.5 The root servers SHOULD have their clocks synchronized via
NTP [RFC1305] [RFC2030] or similar mechanisms, in as
secure manner as possible. For this purpose, servers and
their associated firewalls SHOULD allow the root servers
to be NTP clients. Root servers MUST NOT act as NTP peers
or servers.
3.2.5 根のサーバSHOULDはNTP[RFC1305][RFC2030]か同様のメカニズムでそれらの時計を連動させます、できるだけ安全な方法で。 このために、サーバとそれらの関連ファイアウォールSHOULDは、ルートサーバーがNTPクライアントであることを許容します。 ルートサーバーはNTP同輩かサーバとして機能してはいけません。
3.2.6 All attempts at intrusion or other compromise SHOULD be
logged, and all such logs from all root servers SHOULD be
analyzed by a cooperative security team communicating with
all server operators to look for patterns, serious
attempts, etc. Servers SHOULD log in GMT to facilitate
log comparison.
3.2.6 すべての試み、侵入か他の感染SHOULDでは、すべてのルートサーバーからの登録されて、すべてそのようなログがSHOULDであったならパターン、重大な試みなどを探すためにすべてのサーバオペレータとコミュニケートする協調的安全保障チームによって分析されてください。 サーバSHOULDは、グリニッジ標準時にログ比較を容易にするためにログインします。
3.2.7 Server logging SHOULD be to separate hosts which SHOULD be
protected similarly to the root servers themselves.
3.2.7 SHOULDが切り離すことになっているサーバ伐採はどのSHOULDを接待するか。同様にルートサーバー自体に保護されてください。
3.2.8 The server SHOULD be protected from attacks based on
source routing. The server MUST NOT rely on address- or
name-based authentication.
3.2.8 サーバSHOULD、ソースルーティングに基づく攻撃から、保護されてください。 サーバはアドレスか名前ベースの認証に依存してはいけません。
3.2.9 The network on which the server is homed SHOULD have
in-addr.arpa service.
3.2.9 サーバがそうであるネットワークは家へ帰りました。SHOULDには、addr.arpaでのサービスがあります。
3.3 Protocol authentication and security are required to ensure that
data presented by the root servers are those created by those
authorized to maintain the root zone data.
3.3 プロトコル認証とセキュリティが、ルートサーバーで提示されたデータがルートゾーンデータを保守するのを認可されたものによって作成されたものであることを保証するのに必要です。
Bush, et al. Best Current Practice [Page 5] RFC 2870 Root Name Server Operational Requirements June 2000
ブッシュ、他 要件2000年6月の操作上の最も良い現在の習慣[5ページ]RFC2870根のネームサーバ
3.3.1 The root zone MUST be signed by the Internet Assigned
Numbers Authority (IANA) in accordance with DNSSEC, see
[RFC2535] or its replacements. It is understood that
DNSSEC is not yet deployable on some common platforms, but
will be deployed when supported.
3.3.1 DNSSECに従って、インターネットAssigned民数記Authority(IANA)はルートゾーンに署名しなければならなくて、[RFC2535]かその交換を見てください。 サポートされると、DNSSECがいくつかの一般的なプラットホームでまだ配布可能ではありませんが、配布されるのが理解されています。
3.3.2 Root servers MUST be DNSSEC-capable so that queries may be
authenticated by clients with security and authentication
concerns. It is understood that DNSSEC is not yet
deployable on some common platforms, but will be deployed
when supported.
3.3.2 ルートサーバーは、セキュリティと認証関心を伴うクライアントが質問を認証できるように、DNSSECできなければなりません。 サポートされると、DNSSECがいくつかの一般的なプラットホームでまだ配布可能ではありませんが、配布されるのが理解されています。
3.3.3 Transfer of the root zone between root servers MUST be
authenticated and be as secure as reasonably possible.
Out of band security validation of updates MUST be
supported. Servers MUST use DNSSEC to authenticate root
zones received from other servers. It is understood that
DNSSEC is not yet deployable on some common platforms, but
will be deployed when supported.
3.3.3 ルートサーバーの間のルートゾーンの転送は、認証されて、合理的にできるだけ安全でなければなりません。 バンドセキュリティから、アップデートの合法化をサポートしなければなりません。 サーバは、他のサーバから受け取られたルートゾーンを認証するのにDNSSECを使用しなければなりません。 サポートされると、DNSSECがいくつかの一般的なプラットホームでまだ配布可能ではありませんが、配布されるのが理解されています。
3.3.4 A 'hidden primary' server, which only allows access by the
authorized secondary root servers, MAY be used.
3.3.4 '隠された予備選挙'サーバ(認可された二次根サーバでアクセスを許すだけである)は使用されるかもしれません。
3.3.5 Root zone updates SHOULD only progress after a number of
heuristic checks designed to detect erroneous updates have
been passed. In case the update fails the tests, human
intervention MUST be requested.
3.3.5 多くの誤ったアップデートを検出するように設計された発見的なチェックが通過された後にSHOULDが進行するだけであるゾーンアップデートを根づかせてください。 アップデートがテストに失敗するといけないので、人間の介入を要求しなければなりません。
3.3.6 Root zone updates SHOULD normally be effective no later
than 6 hours from notification of the root server
operator.
3.3.6 通常、ルートゾーンはSHOULDをアップデートします。ルートサーバーオペレータの通知から6時間効果的であってください。
3.3.7 A special procedure for emergency updates SHOULD be
defined. Updates initiated by the emergency procedure
SHOULD be made no later than 12 hours after notification.
3.3.7 非常時の間の特別な手順はSHOULDをアップデートします。定義されます。 アップデートは応急処置法でSHOULDを開始しました。12までには、通知の何時間も後に作られてください。
3.3.8 In the advent of a critical network failure, each root
server MUST have a method to update the root zone data via
a medium which is delivered through an alternative, non-
network, path.
3.3.8 重要なネットワーク失敗の到来では、各ルートサーバーは代替の、そして、非ネットワークの経路を通して提供される媒体でルートゾーンデータをアップデートするメソッドを持たなければなりません。
3.3.9 Each root MUST keep global statistics on the amount and
types of queries received/answered on a daily basis. These
statistics must be made available to RSSAC and RSSAC
sponsored researchers to help determine how to better
deploy these machines more efficiently across the
3.3.9 各根は日課で受けるか、または答える質問の量とタイプにおけるグローバルな統計を保たなければなりません。 RSSACはこれらの統計を入手しなければなりません、そして、RSSACはこれらのマシンをよりよくより効率的に横切って配布する方法を決定するのを助けるために研究者を後援しました。
Bush, et al. Best Current Practice [Page 6] RFC 2870 Root Name Server Operational Requirements June 2000
ブッシュ、他 要件2000年6月の操作上の最も良い現在の習慣[6ページ]RFC2870根のネームサーバ
internet. Each root MAY collect data snapshots to help
determine data points such as DNS query storms,
significant implementation bugs, etc.
インターネット。 各根は、DNS質問嵐、重要な実装バグなどのデータポイントを決定するのを助けるためにデータスナップを集めるかもしれません。
4. Communications
4. コミュニケーション
Communications and coordination between root server operators and between the operators and the IANA and ICANN are necessary.
ルートサーバーオペレータとオペレータの間のコミュニケーションとコーディネート、IANA、およびICANNが必要です。
4.1 Planned outages and other down times SHOULD be coordinated
between root server operators to ensure that a significant number
of the root servers are not all down at the same time.
Preannouncement of planned outages also keeps other operators
from wasting time wondering about any anomalies.
4.1 計画された供給停止で回のSHOULDの下側に他は、多くそれを確実にするためにルートサーバーオペレータの間で調整されて、同時にルートサーバーがすべてダウンであるというわけではないということです。 計画された供給停止の予報によって、また、他のオペレータはどんな例外もいぶかりながら、時間を浪費できません。
4.2 Root server operators SHOULD coordinate backup timing so that
many servers are not off-line being backed up at the same time.
Backups SHOULD be frequently transferred off site.
4.2 ルートサーバーオペレータSHOULDがバックアップタイミングを調整するので、多くのサーバは同時に支援されながら、オフラインではありません。 頻繁にバックアップSHOULDはそうです。サイトでは、移します。
4.3 Root server operators SHOULD exchange log files, particularly as
they relate to security, loading, and other significant events.
This MAY be through a central log coordination point, or MAY be
informal.
特にセキュリティ、ローディング、および他の重大な行事に関連するとき、4.3はサーバオペレータSHOULD交換ログファイルを根づかせます。 これは、主要なログコーディネートポイントを通してあるかもしれないか、または非公式であるかもしれません。
4.4 Statistics as they concern usage rates, loading, and resource
utilization SHOULD be exchanged between operators, and MUST be
reported to the IANA for planning and reporting purposes.
使用率、ローディング、およびリソース利用SHOULDに関係があるとき、4.4の統計をオペレータの間で交換されて、目的を計画して、報告するためにIANAに報告しなければなりません。
4.5 Root name server administrative personnel MUST be available to
provide service 24 hours a day, 7 days per week. On call
personnel MAY be used to provide this service outside of normal
working hours.
4.5 根のネームサーバ管理の人員は1日24時間、1週間あたり7日間サービスを提供できなければなりません。 呼び出しのときに、人員は、正常な労働時間の外にこのサービスを提供するのに使用されるかもしれません。
5. Acknowledgements
5. 承認
The authors would like to thank Scott Bradner, Robert Elz, Chris Fletcher, John Klensin, Steve Bellovin, and Vern Paxson for their constructive comments.
作者は彼らの建設的なコメントについてスコット・ブラドナー、ロバートElz、クリスフレッチャー、ジョンKlensin、スティーブBellovin、およびバーン・パクソンに感謝したがっています。
Bush, et al. Best Current Practice [Page 7] RFC 2870 Root Name Server Operational Requirements June 2000
ブッシュ、他 要件2000年6月の操作上の最も良い現在の習慣[7ページ]RFC2870根のネームサーバ
6. References
6. 参照
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC1305] 工場、D.、「ネットワーク時間プロトコル(バージョン3)仕様、実装」RFC1305、3月1992日
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2030]工場、D.、「IPv4、IPv6、およびOSIのための簡単なネットワーク時間プロトコル(SNTP)バージョン4」、RFC2030、1996年10月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
[RFC2535] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2535, March 1999.
[RFC2535] イーストレークとD.とC.コーフマン、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
Bush, et al. Best Current Practice [Page 8] RFC 2870 Root Name Server Operational Requirements June 2000
ブッシュ、他 要件2000年6月の操作上の最も良い現在の習慣[8ページ]RFC2870根のネームサーバ
7. Authors' Addresses
7. 作者のアドレス
Randy Bush Verio, Inc. 5147 Crystal Springs Bainbridge Island, WA US-98110
ランディブッシュVerio Inc.5147水晶スプリングベーンブリッジ島、ワシントン米国-98110
Phone: +1 206 780 0431 EMail: randy@psg.com
以下に電話をしてください。 +1 0431年の206 780メール: randy@psg.com
Daniel Karrenberg RIPE Network Coordination Centre (NCC) Singel 258 NL-1016 AB Amsterdam Netherlands
ダニエルKarrenbergの熟しているネットワークコーディネートセンター(NCC)Singel258NL-1016ABアムステルダムオランダ
Phone: +31 20 535 4444 EMail: daniel.karrenberg@ripe.net
以下に電話をしてください。 +31 20 535 4444はメールされます: daniel.karrenberg@ripe.net
Mark Kosters Network Solutions 505 Huntmar Park Drive Herndon, VA 22070-5100
Huntmar公園Driveハーンドン、マークKostersネットワークSolutions505ヴァージニア22070-5100
Phone: +1 703 742 0400 EMail: markk@netsol.com
以下に電話をしてください。 +1 0400年の703 742メール: markk@netsol.com
Raymond Plzak SAIC 1710 Goodridge Drive McLean, Virginia 22102 +1 703 821 6535
レイモンドPlzak SAIC1710グッドリッジ・Driveマクリーン、ヴァージニア22102+1 703 821 6535
EMail: plzakr@saic.com
メール: plzakr@saic.com
8. Specification of Requirements
8. 要件の仕様
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 RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
Bush, et al. Best Current Practice [Page 9] RFC 2870 Root Name Server Operational Requirements June 2000
ブッシュ、他 要件2000年6月の操作上の最も良い現在の習慣[9ページ]RFC2870根のネームサーバ
9. Full Copyright Statement
9. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Bush, et al. Best Current Practice [Page 10]
ブッシュ、他 最も良い現在の習慣[10ページ]
一覧
スポンサーリンク
