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


  • Status of this Memo (この文書の状態 )
  • Abstract (概要)
  • 1 - Rationale and Scope (原理と範囲)
  • 2 - Operational Requirements (運用条件)
  • 3 - Possible Selection Criteria (可能な選択基準)
  • 4 - Security Considerations (セキュリティの考慮)
  • 5 - References (参考文献)
  • 6 - Acknowledgements (謝辞)
  • 7 - Authors' Addresses (著者のアドレス)

  • Network Working Group                                         B. Manning
    Request for Comments: 2010                                           ISI
    Category: Informational                                         P. Vixie
                                                                         ISC
                                                                October 1996
    
    
                   Operational Criteria for Root Name Servers
                      ルートネームサーバーの運用基準
    
    Status of this 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、ARPA)に関責
       任があった。これらのネームサーバーは高度に有能なボランティア中核員に
       より運用され、彼らの管理はほぼ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]
       で与えられた運用条件の適用を受けています。ルートゾーン(".")のサーバー
       群が、InterNICが保守してるのも含めて、TLDあるいはTLDグループのサーバー
       群と共通要素を持たなくなる可能性が高い。
    
       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のサーバーが運用条件が似ている
       にもかかわらず、管理者が異なりわずかに運用条件が異なるため、これらは
       異なるサーバ群である。多くの国番号TDLサーバーが更に多様な運用条件を持
       ことはありそうです。そこで、この文書の以下の必要条件は(ルート、最上
       位、その他に関わらず)、全てのネームサーバーに適用できますが、ルート
       ゾーン(".")以外のサーバーに必要であるというより過酷かもしれません。
    
       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.
         原理:      この条件はBINDソースコードの広く自由な能力と、IETFの数
                     人のメンバーから受け取る活発な分析と開発の有効性に基づ
                     いています。
    
       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.
         原理:      ある場合、振動している悪いデータを整理するため、ゾーン
                     サーバーの「コールド・スタート」が必要であると判明しま
                     した。すべてのソフトウェアアップグレードをほぼ同じ時間
                     にする事を強いることで、ソフトウェア変更とゾーン内容変
                     更を合わせることが可能であるでしょう。
    
       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.
         原理:      あるベンダーがMACレベルフレームチェック(例えばCRC)の
                     存在を「十分強い」と述べて、処理能力の理由でUDPチェック
                     サムを止めます。これは実際の実行で大惨事でした。
    
       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、その他)。もしシステムコンソール
       以外からのログインが認められるなら、それのログインサービスは暗号化チャ
       ネルを使うべきです(例えば、 ケルベロスと暗号化rlogin/telnet、安全な
       シェル(SSH)、あるいは同等なもの)。
    
         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プロトコル(最新バージョン)
       を使って認証のために時計を合わせるべきです。少なくとも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サーバー間で
                     認証が必要条件です。ネームサーバーと第1層NTPの両方を動か
                     すホストが非常に信頼性が高く安全なことが観察されたので、
                     ネームサーバーホストが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応答を送らなくてはなりません。ネームサーバーが多数の実際
       のインタフェースを持つかもしれませんが、ただ1だけがゾーンのNS RRset
       と接着A RRで広告されるであろう。広告されたアドレスは最大多数ホストの
       宛先に、ネットワークパフォーマンスと信頼性に関して「最も良い」インタ
       フェースであるべきです。
    
         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つに限定されます。
    
       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重化やバッテリーやジェネレーターやその他の
       手段で停電から保護するべきです。ネットワーク接続性は冗長であるべきで、
       ひとつの広域回線故障で完全にネームサーバーホストがネットワークから孤
       立するべきでありません。
    
       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. ネットワークセキュリティ。システムとネットワーク管理者は脅威の可
       能性について彼ら自身を教育し、ネットワーク破壊に関する現在のCERT告示
       に従うべきです。システムスタッフは周期的にネームサーバーホストの活動
       ログを監査して、発生中か発生したかの破壊活動を発見できるべきです。
    
       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,200のUDP取引に答えなければなりません。ネット
       ワークが高度成長しているから、秒毎に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時間以内に電子メー
       ルで問題報告をするでしょう。休暇と病気のような個人の問題がある時は、無
       視するのではなく、責任が委任されたり、再配置されるでしょう。勤務時間後
       に使える公表されない緊急時に使用する電話番号がゾーンマスターに利用可能
       にすべきです。通常のチャネルで応答がない場合に、他の連絡者や電子メール
       アドレスや電話番号がゾーンマスターに利用可能であるべきでしょう。
    
       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. ゾーン転送アクセス制御。ネームサーバーは、外行きのゾーン転送が
       サーバーのローカルネットワーク上と、ゾーンマスターが遠隔デバッグの目
       的で設定したネットワーク宛にだけ認められるように、構成を設定されるべ
       きです。
    
         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]参照)と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の値はゾーンマスターが指定したものに
       するべきである。
    
         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 RRの個別の管理がある
                     ので、あるソフトウェアで正しく動作するためには順検索と
                     逆検索の結果が一致する必要があるので、各権威サーバーの
                     プライマリアドレスの名前の選択はゾーンマスターに任せら
                     れます。
    
    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ホップ数の少ない場所にあるべきです。どのエンドホスト集団からも、
       あるゾーンの少なくとも1つの権威サーバが、IPホップ数の少ない場所に
       あるように、サービスの複製を避けらるべきです。
    
       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.
    
       [Postel96]
          Postel, J., "New Registries and the Delegation of International Top
          Level Domains", Work in Progress.
    
       [IXFR]
          Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
    
       [NOTIFY]
          Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
          RFC 1996, August 1996.
    
    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.
    
    7 - Authors' Addresses 
    7 - 著者のアドレス
    
         Bill Manning
         USC/ISI
         4676 Admiralty Way
         Marina del Rey, CA 90292
    
         Phone: +1 310 822 1511
         EMail: bmanning@isi.edu
    
    
         Paul Vixie
         Internet Software Consortium
         Star Route Box 159A
         Woodside, CA 94062
    
         Phone: +1 415 747 0204
         EMail: paul@vix.com
    

    Japanese translation by Ishida So