この文書はRFC2870の日本語訳です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


  • Status of this Memo (この文書の状態 )
  • Copyright Notice (著作権表示)
  • Abstract (概要)
  • 1. Background (背景)
  • 2. The Servers Themselves (サーバ自身)
  • 3. Security Considerations (セキュリティ考慮)
  • 4. Communications (通信)
  • 5. Acknowledgements (謝辞)
  • 6. References (参考文献)
  • 7. Authors' Addresses (著者のアドレス)
  • 8. Specification of Requirements (条件指定)
  • 9. Full Copyright Statement (著作権表示全文)
  • Acknowledgement (謝辞)

  • 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
    
    
                   Root Name Server Operational Requirements
                          ルートネームサーバー運用条件
    
    Status of this 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.
       このドキュメントはインターネット共同体のために現インターネット最良実
       践を指定して、そして改良のために議論と提案を求めます。このメモの配布
       は無制限です。
    
    Copyright Notice 
    著作権表示
    
       Copyright (C) The Internet Society (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.
       インターネットの上のドメイン名の解決はルートドメインネームサーバーの
       適切で確実で安全な運用にかなり依存しています。現在、1ダースほどのサー
       バーが有能で信頼できるボランティアのグループにより提供され運用されま
       す。この書類はこれを変更することを提案しませんが、共同体がどのように
       なぜこれがされるかを理解できる様に正式のガイドラインを供給します。
    
       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 はルートサー
           バーシステム諮問委員会(RSSAC)にICANN委員会に専門的なて操作上の
           アドバイスを与えるように指定しました。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のような基盤TLDや、いくつかのccTLD(国番号TLD、例えば
           スウェーデンではSE)のような、いくつかのTLD(最上位ドメイン)をサ
           ポートするが、これは変わる可能性が高いです(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 経験的にインターネットがルートゾーンやTLDの間違ったデータで非常に
           被害をうけやすいことがわかっています。したがってこれらのデータの
           認証と承認と安全は重要です。
    
    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のIETF標準を実装するソフトウェアを動
           かさなければなりません、現在の標準は[RFC1035] [RFC2181]です(MUST)。
           標準遵守のために公式テストセットがないので、ルートサーバーで使う
           ソフトウェアのメンテナンス者はは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倍のルートデータの要求を処理できなければなりません
           (MUST)。これは通常、毎秒のリクエストで表現されます。もしルートサー
           バーの3分の2が、意識的にか事故か悪意かなどで、運用が止まった際
           にルートサービスの継続的運用を保証するように意図されます。
    
       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.
           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.
       2.4 それぞれのルートサーバーが上記条件を満たすのに十分なインターネッ
           トとの帯域の接続性を持つべきです。インターネットへの接続性は可能
           な限り多様であるべきです(SHOULD)。ルートサーバーがどんなインター
           ネットプロバイダからの接続をインターネットプロバイダ自身のコスト
           でするIP接続性を受け入れる適した機構を持つべきです(SHOULD)。
    
       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 サーバーが提供するゾーンについてだけ正式回答を提供しなくてはなり
           ません(MUST)。サーバーは再帰的検索、転送、その他のキャッシュの回]
           答をするような事に障害を与えなくてはなりません(MUST)。ルートと
           root-servers.netゾーン以外のゾーンのサービスを提供してはなりませ
           ん(MUST NOT)。これらの制限はルートサーバーに過度の負荷を発生させ
           ないのに役立ち、ルートサーバが誤ったデータをキャッシュする可能性
           を減らします。
    
       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 ルートサーバーが全てのインターネットホストからの問合せに答えなく
           てはなりません、つまり全ての正しいIPアドレスからのルートネーム解
           決を止めてはなりません(MUST)。運用上の問題がある場合を例外です。
           この場合も、止めるのは問題発生している期間と合理的に必要な期間に
           限るべきです(SHOULD)。
    
       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 ルートサーバーがルートサーバ以外のクライアントからのAXFRやその他
           のゾーン転送要求に答えるべきではありません(SHOULD NOT)。この制限
           は、特に「誤りやすいキャッシュを持つのを避けるため、あなたのサー
           バーをルートゾーンの見えないセカンダリしてください」というアドバ
           イスが聞かれるので、ルートサーバーの不必要な負荷を妨げるように意
           図されます。ルートサーバーはいくつかのあまり重要でないサーバーに
           ルートゾーンをftpや他の手段で提供してもよいです(MAY)。
    
       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データグラムを送る時チェックサムを生成し(MUST)、ゼロ
           以外のチェックサムを含むUDPデータグラムを受け取った時チェックサム
           を検証しなくてはなりません(MUST)。
    
    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 サーバーは回答の明確な認証と同様に、物理的なセキュリティとプロト
           コル的セキュリティを必要とします(MUST)。
    
            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
                  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.
            3.1.1 ルートサーバーが属するサイトでサイト全体のアクセス制御があ
                  るか否かにかかわらず、ルートサーバーが属する特定のエリアで
                  は積極的なアクセス制御が必要です(MUST)。すなわちその区域に
                  アクセスを許可される個人番号は、限定され、制御され、記録さ
                  れます(MUST)。最小限、制御手段は機械鍵か電子鍵をすべきです
                  (SHOULD)。物理的なセキュリティが侵入発見と運動センサーや多
                  数の連続的なアクセスポイントや警備員などの使用で強化される
                  かもしれません(MAY)。
    
            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時間の電力供給
                  が保証されなくてはなりません(MUST)。電力はサーバー自身とサー
                  バをインターネットと接続する設備へ供給しなくてはなりません
                  (MUST)。予備電力機構と供給が、製造業者の仕様や推薦に従い、
                  劣化していないか、しばしばテストされることを保証する手順が
                  あるに違いありません(MUST)。
    
            3.1.3 Fire detection and/or retardation MUST be provided.
            3.1.3 火災発見と阻止が用意されなくてはなりません(MUST)。
    
            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 システム停電後に運用状態へ早く復帰する準備がされなくてはな
                  りません(MUST)。これはシステムソフトウェアと設定のバックアッ
                  プを伴うべきです(SHOULD)。同じく事前設定されたバックアップ
                  ハードウェアがあり運用を引き継ぐ準備ができてるべきです
                  (SHOULD)、運用開始には手動の手順を必要とするかもしれません
                  (MAY)。
    
       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などのような遠隔インターネッ
                  ト・プロトコルを用意してはなりません(MUST NOT)。認められた
                  唯一のログインアカウントはサーバー管理者であるべきです。ユー
                  ザアカウントを通る場合を除き、「ルート」や「特権ユーザー」
                  アクセスは認めらません(MUST NOT)。
    
                  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.
                  サーバーが遠隔管理者アクセスとメンテナンスのためのセキュリ
                  ティメカニズムを持っていなくてはなりません(MUST)。故障発生
                  時;24時間365日サポート条件(4.5参照)で、何かがひ
                  どく壊れて、上級ウィザードが遠隔から接続する事があるでしょ
                  う。遠隔ログインが強力な認証や暗号化といった安全手段で守ら
                  れなくてはなりません(MUST)、そして遠隔ログインが許されるサ
                  イトが保護され確証されなくてはなりません(MUST)。
    
            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
                  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.
            3.2.2 ルート名前サーバーが認証や暗号化鍵や他のアクセスやセキュリ
                  ティ情報ででも、セカンダリサーバがプライマリサーバを信頼す
                  る場合を除き、他のホストを信頼するべきではありません
                  (SHOULD NOT)。もしルートオペレーターがルートサーバーのアク
                  セス管理にケルベロス認証を使うなら、使用するケルベロスキー
                  サーバーはルートサーバー自身と同じくらい慎重に守られなくて
                  はなりません(MUST)。これは信頼が必要な関連したサービスに当
                  てはまります。
    
            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セグメントにはばかなホストが
                  いてはなりません(MUST NOT)。すなわち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セグメントは個別にファイアウォール
                  かパケットフィルタリングが行われ、ネームサービスで必要な
                  ポート以外のネットワークアクセスを止めるべきです(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 ルートサーバーはセキュリティを確保した方法で、NTP[RFC1305]
                  [RFC2030]か類似の方法で時計を合わせておくべきです(SHOULD)。
                  この目的のために、サーバーに関連したファイアウォールはルー
                  トサーバーがNTPクライアントになることを可能にするべきです
                  (SHOULD)。ルートサーバーがNTPピアやサーバーの役を務めては
                  なりません(MUST NOT)。
    
            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)。
                  サーバーがログの比較を容易にするためGMTをログに使用するべ
                  きです(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)。サーバーはアドレスや名前の基づく認証に頼って
                  はなりません(MUST NOT)。
    
            3.2.9 The network on which the server is homed SHOULD have
                  in-addr.arpa service.
            3.2.9 サーバーの存在するネットワークはaddr.arpaサービスを持つべ
                  きです(SHOULD)。
    
       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 ルートサーバーが出すデータがルートゾーンデータを保守する権限を与
           えられた人たちによって作られたことを保証するようにプロトコル認証
           と安全管理が要求されます。
    
            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 ルートゾーンは[RFC2535]のDNSSECかその後継によってインター
                  ネット番号割当当局(IANA)の署名がされなくてはなりません
                  (MUST)。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対応であるに違いありませ
                  ん(MUST)。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 ルートサーバー間のルートゾーン転送が認証されて、合理的に利
                  用可能な方法で確証されるあるに違いありません(MUST)。アップ
                  デート時の通信の外でのセキュリティがサポートされなくてはな
                  りません(MUST)。サーバーが他のサーバーから受け取ったルート
                  ゾーンを認証するためにDNSSECを使わなくてはなりません(MUST)。
                  DNSSECがある共通プラットホームでまだ利用可能ではないが、サ
                  ポートする際は利用可能であろうと理解されます。
    
            3.3.4 A 'hidden primary' server, which only allows access by the
                  authorized secondary root servers, MAY be used.
            3.3.4 認定されたセカンダリルートサーバーにだけアクセスを許す「隠
                  れたプライマリ」サーバーが使われるかもしれません(MAY)。
    
            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)。更新がテストに失敗するならば、人間の介入が求めら
                  れなくてはなりません(MUST)。
    
            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 ルートゾーン更新が通常ルートサーバーオペレーターの通知から
                  6時間以内に効果を発揮すべきです(SHOULD)。
    
            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)。緊
                  急手順によって始められた更新が通知の12時間以内に行われる
                  べきです(SHOULD)。
    
            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 重大なネットワーク故障の際に、各ルートサーバーが代用の非
                  ネットワークの配達手段によってルートゾーンデータを更新す
                  る方法を持っていなくてはなりません(MUST)。
    
            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
                  internet.  Each root MAY collect data snapshots to help
                  determine data points such as DNS query storms,
                  significant implementation bugs, etc.
            3.3.9 それぞれのルートが日単位で受付と応答の問合せタイプ別のグロー
                  バルな統計を保持しなくてはなりません(MUST)。これらの統計値
                  がRSSACとRSSACに入手可能にし、インターネットでより効率的に
                  より良くマシンを実装すべきか決定する研究者を援助します。そ
                  れぞれのルートがDNS問合せストーム、重大な実装バグなどのよ
                  うなデータ特質を決定するのに役立つデータのスナップショット
                  を集めるかもしれません(MAY)。
    
    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)。これは中
           央のログ調整ポイントを通してかもしれないし(MAY)、あるいは非公式で
           かもしれません(MAY)。
    
       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.
       4.4 利用率や負荷や資源利用に関係する統計が操作員間で交換されるべきで
           ある(SHOULD)、そして統計が計画や報告の目的のためIANAに報告されな
           くてはなりません(MUST)。
    
       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時間、週7日間のサービス提供が可能なルートネームサーバー
           管理の人員を用意しなければはりません(MUST)。通常の就業時間外にこ
           のサービスを提供するため臨時職員が使われるかもしれません(MAY)。
    
    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.
       著者はScott BradnerとRobert ElzとChris FletcherとJohn KlensinとSteve
       BellovinとVern Paxsonの建設的なコメントに感謝したいです。
    
    6. References 
    6. 参考文献
    
       [RFC1035] Mockapetris, P., "Domain names - implementation and
                 specification", STD 13, RFC 1035, November 1987.
    
       [RFC1305] Mills, D., "Network Time Protocol (Version 3)
                 Specification, Implementation", RFC 1305, March 1992.
    
       [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
                 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
    
       [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
                 Specification", RFC 2181, July 1997.
    
       [RFC2535] Eastlake, D. and C. Kaufman, "Domain Name System Security
                 Extensions", RFC 2535, March 1999.
    
    7. Authors' Addresses 
    7. 著者のアドレス
    
       Randy Bush
       Verio, Inc.
       5147 Crystal Springs
       Bainbridge Island, WA US-98110
    
       Phone: +1 206 780 0431
       EMail: randy@psg.com
    
    
       Daniel Karrenberg
       RIPE Network Coordination Centre (NCC)
       Singel 258
       NL-1016 AB  Amsterdam
       Netherlands
    
       Phone: +31 20 535 4444
       EMail: daniel.karrenberg@ripe.net
    
    
       Mark Kosters
       Network Solutions
       505 Huntmar Park Drive
       Herndon, VA 22070-5100
    
       Phone: +1 703 742 0400
       EMail: markk@netsol.com
    
    
       Raymond Plzak
       SAIC
       1710 Goodridge Drive
       McLean, Virginia 22102
       +1 703 821 6535
    
       EMail: 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"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
       NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"とは
       RFC2119で記述されるように、解釈されるはずである。
    
    9.  Full Copyright Statement 
    9.  著作権表示全文
    
       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エディタ機能のための資金供給が現在インターネット学会によって
       供給されます。
    

    Japanese translation by Ishida So