[要約] RFC 2870は、ルートネームサーバの運用要件に関するガイドラインです。その目的は、インターネットのルートネームサーバの安定性と信頼性を確保するための基準を提供することです。
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.
Copyright（c）The Internet Society（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.
インターネット上のドメイン名の解像度は、ルートドメイン名サーバーの適切で安全で安全な操作に大きく依存しています。現在、これらの12つのサーバーは、非常に有能で信頼できるボランティアのグループによって提供および運営されています。このドキュメントは、それを変更することを提案するものではなく、コミュニティがこれがどのように、なぜ行われるのかを理解するように、単に正式なガイドラインを提供することを提案しています。
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 ルートサーバーは、ルート、別名「。」、ゾーンを提供します。今日、ルートサーバーの一部は、GTLD（com、net、orgなど）、intやin-addr.arpaなどのインフラストラクチャTLD、および一部のCCTLD（国コードTLDS、国のTLDなどのいくつかの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 各サーバーは、現在[RFC1035] [RFC2181]のIETF標準をDNSの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秒あたりのリクエストで表されます。これは、サーバーの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.
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.
ルートサーバーには、インターネットプロバイダーからのRoot Serverへの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 サーバーは、提供するゾーンからのみ権威ある応答を提供する必要があります。サーバーは、再帰的な検索、転送、またはキャッシュされた回答を提供できる他の機能を無効にする必要があります。また、ルートとルートセルバー以外のゾーンにセカンダリサービスを提供してはなりません。これらの制限は、ルートサーバーの過度の負荷を防ぎ、キャッシングが誤ったデータを使用する可能性を減らすのに役立ちます。
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 ルートサーバーは、他のルートサーバー以外のクライアントからのクエリまたはその他のゾーン転送に応答してはなりません。この制限は、とりわけ、「腐敗しやすいキャッシュを避けるために、サーバーをルートゾーンのステルスセカンダリにする」などのアドバイスが聞こえるように、ルートサーバーの不必要な負荷を防ぐことを目的としています。ルートサーバーは、ルートゾーンをFTPまたはその他のアクセスに配置することができます。
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.1 ルートサーバーが配置されているサイト全体にアクセス制御があるかどうかにかかわらず、ルートサーバーが配置されている特定の領域には正のアクセス制御が必要です。つまり、エリアへのアクセスを許可する個人の数を制限、制御、および録音。少なくとも、制御対策は機械的または電子ロックのいずれかでなければなりません。物理的なセキュリティは、侵入検知とモーションセンサー、複数のシリアルアクセスポイント、セキュリティ担当者などを使用することで強化される場合があります。
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 システムの停止後、操作に迅速に復帰するために提供する必要があります。これには、システムソフトウェアと構成のバックアップが含まれる必要があります。ただし、事前に構成され、操作を引き継ぐ準備ができているバックアップハードウェアも含まれる必要があります。
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時間365日のサポート要件（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 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認証を使用してルートサーバーへのアクセスを管理する場合、関連する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セグメントは、名前サービスに必要なポート以外のネットワークアクセスを阻止するために、個別にファイアウォールまたはパケットフィルタリングされている必要があります。
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]または同様のメカニズムを介してクロックを同期する必要があります。この目的のために、サーバーとそれに関連するファイアウォールは、ルートサーバーを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 サーバーロギングは、ルートサーバー自体と同様に保護する必要があるホストを分離することです。
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.
3.2.9 サーバーが家に帰るネットワークには、in-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 ルートサーバーによって提示されたデータが、ルートゾーンデータを維持することが許可されたデータによって作成されたデータであることを確認するために、プロトコル認証とセキュリティが必要です。
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に従ってインターネット割り当てされた番号局（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 ルートゾーンの更新は、誤った更新を検出するために設計された多数のヒューリスティックチェックが渡された後にのみ進行する必要があります。更新がテストに失敗した場合、人間の介入を要求する必要があります。
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.
著者は、建設的なコメントをしてくれたスコット・ブラッドナー、ロバート・エルツ、クリス・フレッチャー、ジョン・クレンシン、スティーブ・ベロヴィン、ヴァーン・パクソンに感謝したいと思います。
[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] Mills、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] Mills、D。、「IPv4、IPv6およびOSI用のSimple Network Time Protocol（SNTP）バージョン4」、RFC 2030、1996年10月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[RFC2535] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake、D。およびC. Kaufman、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
Randy Bush Verio, Inc. 5147 Crystal Springs Bainbridge Island, WA US-98110
Randy Bush Verio、Inc。5147クリスタルスプリングスベインブリッジ島、ワシントン州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
ダニエル・カレンバーグRIPEネットワーク調整センター（NCC）シンゲル258 NL-1016 AB AMSTERDAMオランダ
Phone: +31 20 535 4444
EMail: daniel.karrenberg@ripe.net
Mark Kosters Network Solutions 505 Huntmar Park Drive Herndon, VA 22070-5100
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
Raymond Plzak Saic 1710 Goodridge Drive McLean、Virginia 22102 1 703 821 6535
EMail: 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.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119に記載されているとおりに解釈されます。
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。