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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
インターネットは、世界の社会・経済インフラにますます重要になるにつれて、注意が正しく、正しい安全で、信頼性、およびインターネットインフラストラクチャ自体の安全な運転に焦点を当てています。ルートドメインネームサーバは、その技術インフラの重要な一部として見られています。このドキュメントの主な焦点は、ルートネームサーバの動作のためのガイドラインを提供することです。その他の主なゾーンサーバ事業者（のgTLD、ccTLDの、主要なゾーン）も、それが役に立つかもしれません。これらのガイドラインは過度に技術的な詳細を規定せず、知覚社会のニーズを満たすことを意図しています。
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 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と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ルートサーバは別名、ルートに仕える「」、ゾーンを。ルートサーバのいくつかはまた、このようなインフラのTLDなINTやIN-ADDR.ARPAなどのgTLD（COM、NET、ORG、など）、およびいくつかのccTLD（国別コードトップレベルドメインとして、いくつかのTLD（トップレベルドメイン）をサーブ今日ものの、例えばスウェーデンSE）、これは（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の中に誤ったデータに非常に脆弱であることが示されています。したがって、認証、検証、およびこれらのデータのセキュリティが大きな懸念です。
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倍の測定ピークであるルートデータに対する要求の負荷を処理できなければなりません。これは通常、秒あたりの要求で表現されます。これは、ルートサービスの継続的な操作は、サーバの三分の二が意図、事故、または悪意によってか、操作の外に取られるべきであることを確認することを意図しています。
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各ルートサーバは、上記の要件の帯域幅のニーズをサポートするために、インターネットへの十分な接続性を持っている必要があります。インターネットへの接続は、できるだけ多様であるべきです。
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.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サーバだけで、彼らが仕えるのゾーンから正式な回答を提供しなければなりません。サーバーは、再帰検索、転送、またはそれらがキャッシュされた答えを提供することを可能にする任意の他の機能を無効にする必要があります。彼らはまた、ルートとroot-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ルートサーバー、つまりブロッキングが問題だけで終わるべきである。その場合には操作上の問題を引き起こしたクエリの場合、を除き、任意の有効な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ルートサーバーは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データグラムを受信したときにチェックサムを検証しなければなりません。
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 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.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時間のパワーの継続よりも信頼性があることをdocumentable経験がない限りによるオンサイトのバッテリーかどうか、オンサイト発電、またはそれらの組み合わせ。これは、サーバー自体だけでなく、インターネットにサーバーを接続するために必要なインフラを供給しなければなりません。電源フォールバック機構と供給仕様、製造業者の推奨よりも劣ら頻繁に試験されていないことを確認手順がなければなりません。
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提供は、システム停止後の動作への迅速な復帰のためになされなければなりません。これは、システムのソフトウェアとコンフィギュレーションのバックアップを関与させるべきです。しかし、また、手動手順を必要とするかもしれ事前に設定され、操作を引き継ぐ準備ができているバックアップハードウェアを関与させるべきです。
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.
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.
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ルートネームサーバは、認証、暗号化キー、またはその他のアクセスやセキュリティ情報の事項については、プライマリサーバを信頼セカンダリサーバを除いて、他のホストを信用しないでください。ルート・オペレータは、ルートサーバーへのアクセスを管理するために、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.
ルートサーバはMUST NOTも家にクラックホストをホームされているLANセグメント（複数可）3.2.3。即ちマスカレードの可能性がないので、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.
ルート・サーバを別途ファイアウォールまたはパケットは、ネームサービスに必要なもの以外の任意のポートへのネットワークアクセスを阻止するために濾過されるべきであるホームされたLANセグメント（複数可）3.2.4。
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.
ルートサーバーは、それらのクロックは、できるだけ安全な方法で、NTP [RFC1305]、[RFC2030]または類似の機構を介して同期しているべきである3.2.5。このためには、サーバーとそれに関連するファイアウォールは、ルートサーバは、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などのサーバはGMTにログインする必要があるすべての侵入や他の妥協の試みログインする必要があり、そしてすべてのルートサーバからそのようなすべてのログがパターンを探すために、すべてのサーバーオペレータとの通信協調的安全保障チームによって分析されるべきである、深刻な試みを、ログの比較を容易にします。
3.2.7 Server logging SHOULD be to separate hosts which SHOULD be protected similarly to the root servers themselves.
3.2.7 Serverのログは、ルートサーバー自体と同様に保護されなければならないホストを分離することであるべきです。
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。サーバは、アドレス - または名前ベースの認証を当てにしてはいけません。
3.2.9 The network on which the server is homed SHOULD have in-addr.arpa service.
サーバーは、in-addr.arpaサービスを持つべきである（SHOULD）ホームされているネットワークを3.2.9。
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.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ルートゾーンの更新のみを進行すべきです。更新がテストに失敗した場合には、人間の介入を要求しなければなりません。
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時間より有効であってはなりません。
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。緊急時の手順によって開始更新は、遅くとも、通知後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 internet. Each root MAY collect data snapshots to help determine data points such as DNS query storms, significant implementation bugs, etc.
3.3.9各ルートは、グローバルな量の統計と受信クエリのタイプを保持しなければならない/毎日のように答えました。これらの統計は、RSSACが利用できるようにする必要があり、RSSACは、より良い、より効率的にインターネット上でこれらのマシンを展開する方法を決定するのに役立つ研究を後援しました。各ルートは、などのDNSクエリの嵐、大幅な実装のバグ、などのデータポイントを判断するためにデータのスナップショットを収集することがあります
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計画停止やダウン以外の時間は、ルートサーバのかなりの数は、同時にすべてダウンしていないことを確認するために、ルートサーバーオペレータ間で調整されるべきです。計画停止の予告はまた、任意の異常についての疑問に時間を浪費から他の演算子を保持します。
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ルートサーバのオペレータは、バックアップのタイミングを調整すべきです。バックアップは頻繁にサイトをオフに転送する必要があります。
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ルートサーバのオペレータは、彼らは、セキュリティ、ロード、およびその他の重要なイベントに関連し、特にとして、ログファイルを交換するべきです。これは、中央のログコーディネーションポイントを介してもよい、または非公式のかもしれ。
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統計は、彼らが使用率、負荷が懸念として、およびリソース使用率は、事業者間で交換されるべきであり、計画や報告の目的のために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時間、週7日間を提供するために使用可能でなければなりません。コールの担当者に通常の勤務時間外にこのサービスを提供するために使用されるかもしれません。
The authors would like to thank Scott Bradner, Robert Elz, Chris Fletcher, John Klensin, Steve Bellovin, and Vern Paxson for their constructive comments.
作者は彼らの建設的なコメントのためにスコット・ブラッドナー、ロバート・エルツ、クリス・フレッチャー、ジョン・クレンシン、スティーブBellovin氏、およびバーン・パクソンに感謝したいと思います。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装"、RFC 1305、1992年3月。
[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"、RFC 2030、1996年10月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、RFC 2181、1997年7月。
[RFC2535] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]イーストレイク、D.およびC.カウフマン、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
Randy Bush Verio, Inc. 5147 Crystal Springs Bainbridge Island, WA US-98110
ランディブッシュベリオ社5147クリスタルスプリングスベインブリッジ島、WA、US-98110
Phone: +1 206 780 0431 EMail: randy@psg.com
電話：+1 206 780 0431 Eメール：randy@psg.com
Daniel Karrenberg RIPE Network Coordination Centre (NCC) Singel 258 NL-1016 AB Amsterdam Netherlands
ダニエルKarrenberg RIPEネットワークコーディネーションセンター（NCC）シンゲル258 NL-1016 ABアムステルダムオランダ
Phone: +31 20 535 4444 EMail: daniel.karrenberg@ripe.net
電話：+31 20 535 4444 Eメール：daniel.karrenberg@ripe.net
Mark Kosters Network Solutions 505 Huntmar Park Drive Herndon, VA 22070-5100
マークKostersネットワークソリューション505 Huntmarパークドライブハーンドン、バージニア州22070から5100
Phone: +1 703 742 0400 EMail: markk@netsol.com
電話：+1 703 742 0400 Eメール：markk@netsol.com
Raymond Plzak SAIC 1710 Goodridge Drive McLean, Virginia 22102 +1 703 821 6535
レイモンドPlzak SAIC 1710グッドリッジドライブマクリーン、バージニア州22102 +1 703 821 6535
EMail: plzakr@saic.com
メールアドレス：plzakr@saic.com
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。