[要約] RFC 3258は、共有ユニキャストアドレスを使用して権威ある名前サーバーを配布する方法について説明しています。このRFCの目的は、アドレススペースの効率的な使用と、ネットワークのスケーラビリティの向上です。
Network Working Group T. Hardie
Request for Comments: 3258 Nominum, Inc.
Category: Informational April 2002
Distributing Authoritative Name Servers via Shared Unicast Addresses
共有ユニキャストアドレスを介した権限のあるネームサーバーの配布
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
Abstract
概要
This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under-served areas of the network topology and to reduce the latency for DNS query responses in those areas.
このメモは、権威あるネームサーバーオペレーターが複数の場所にある単一の名前付きサーバーへのアクセスを提供できるようにすることを目的とした一連のプラクティスについて説明しています。これらのプラクティスの開発と展開の主な動機は、ドメインネームシステム（DNS）サーバーの分散を以前はネットワークトポロジのサービスが不足していた領域に増やし、それらの領域でのDNSクエリ応答の待機時間を短縮することです。
This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of DNS servers to previously under-served areas of the network topology and to reduce the latency for DNS query responses in those areas. This document presumes a one-to-one mapping between named authoritative servers and administrative entities (operators). This document contains no guidelines or recommendations for caching name servers. The shared unicast system described here is specific to IPv4; applicability to IPv6 is an area for further study. It should also be noted that the system described here is related to that described in [ANYCAST], but it does not require dedicated address space, routing changes, or the other elements of a full anycast infrastructure which that document describes.
このメモは、権威あるネームサーバーオペレーターが複数の場所にある単一の名前付きサーバーへのアクセスを提供できるようにすることを目的とした一連のプラクティスについて説明しています。これらのプラクティスの開発と展開の主な動機は、以前はサービスが提供されていなかったネットワークトポロジの領域へのDNSサーバーの配布を増やし、それらの領域でのDNSクエリ応答の待機時間を短縮することです。このドキュメントでは、指定された権限のあるサーバーと管理エンティティ（オペレーター）間の1対1のマッピングを想定しています。このドキュメントには、ネームサーバーのキャッシュに関するガイドラインや推奨事項は含まれていません。ここで説明する共有ユニキャストシステムはIPv4に固有です。 IPv6への適用性は、今後の検討課題です。ここで説明されているシステムは[ANYCAST]で説明されているシステムに関連していますが、専用のアドレススペース、ルーティングの変更、またはそのドキュメントで説明されている完全なエニーキャストインフラストラクチャの他の要素は必要ありません。
Operators of authoritative name servers may wish to refer to [SECONDARY] and [ROOT] for general guidance on appropriate practice for authoritative name servers. In addition to proper configuration as a standard authoritative name server, each of the hosts participating in a shared-unicast system should be configured with two network interfaces. These interfaces may be either two physical interfaces or one physical interface mapped to two logical interfaces. One of the network interfaces should use the IPv4 shared unicast address associated with the authoritative name server. The other interface, referred to as the administrative interface below, should use a distinct IPv4 address specific to that host. The host should respond to DNS queries only on the shared-unicast interface. In order to provide the most consistent set of responses from the mesh of anycast hosts, it is good practice to limit responses on that interface to zones for which the host is authoritative.
権威ネームサーバーの運営者は、権威ネームサーバーの適切な実施に関する一般的なガイダンスについて、[SECONDARY]と[ROOT]を参照することをお勧めします。標準の権威ネームサーバーとしての適切な構成に加えて、共有ユニキャストシステムに参加している各ホストには、2つのネットワークインターフェイスを構成する必要があります。これらのインターフェースは、2つの物理インターフェース、または2つの論理インターフェースにマップされた1つの物理インターフェースのいずれかです。ネットワークインターフェイスの1つは、信頼できるネームサーバーに関連付けられたIPv4共有ユニキャストアドレスを使用する必要があります。以下の管理インターフェースと呼ばれる他のインターフェースは、そのホストに固有の別個のIPv4アドレスを使用する必要があります。ホストは、共有ユニキャストインターフェイスでのみDNSクエリに応答する必要があります。エニーキャストホストのメッシュから最も一貫性のある応答セットを提供するために、そのインターフェイス上の応答を、ホストが権限を持つゾーンに制限することをお勧めします。
In order to minimize the risk of man-in-the-middle attacks, zone files should be delivered to the administrative interface of the servers participating in the mesh. Secure file transfer methods and strong authentication should be used for all transfers. If the hosts in the mesh make their zones available for zone transfer, the administrative interfaces should be used for those transfers as well, in order to avoid the problems with potential routing changes for TCP traffic noted in section 2.5 below.
中間者攻撃のリスクを最小限に抑えるには、メッシュに参加しているサーバーの管理インターフェイスにゾーンファイルを配信する必要があります。安全なファイル転送方法と強力な認証をすべての転送に使用する必要があります。メッシュ内のホストがゾーン転送にゾーンを利用できるようにする場合、以下のセクション2.5に記載されているTCPトラフィックのルーティング変更の可能性に関する問題を回避するために、それらの転送にも管理インターフェイスを使用する必要があります。
Authoritative name servers may be loosely or tightly synchronized, depending on the practices set by the operating organization. As noted below in section 4.1.2, lack of synchronization among servers using the same shared unicast address could create problems for some users of this service. In order to minimize that risk, switch-overs from one data set to another data set should be coordinated as much as possible. The use of synchronized clocks on the participating hosts and set times for switch-overs provides a basic level of coordination. A more complete coordination process would involve:
権限のあるネームサーバーは、運用組織によって設定された慣例に応じて、緩やかにまたは厳密に同期されます。以下のセクション4.1.2で説明するように、同じ共有ユニキャストアドレスを使用するサーバー間で同期が取れていない場合、このサービスの一部のユーザーに問題が発生する可能性があります。このリスクを最小限に抑えるには、あるデータセットから別のデータセットへの切り替えを可能な限り調整する必要があります。参加しているホストで同期されたクロックを使用し、スイッチオーバーの時間を設定することで、基本的なレベルの調整が提供されます。より完全な調整プロセスには、以下が含まれます。
a) receipt of zones at a distribution host b) confirmation of the integrity of zones received c) distribution of the zones to all of the servers in the mesh d) confirmation of the integrity of the zones at each server e) coordination of the switchover times for the servers in the mesh f) institution of a failure process to ensure that servers that did not receive correct data or could not switchover to the new data ceased to respond to incoming queries until the problem could be resolved.
a）配信ホストでのゾーンの受信b）受信したゾーンの整合性の確認c）メッシュ内のすべてのサーバーへのゾーンの配信d）各サーバーでのゾーンの整合性の確認e）スイッチオーバーの調整メッシュ内のサーバーの時間f）正しいデータを受信しなかった、または新しいデータに切り替えられなかったサーバーが問題が解決するまで着信クエリに応答しなくなったことを確認するための障害プロセスの確立。
Depending on the size of the mesh, the distribution host may also be a participant; for authoritative servers, it may also be the host on which zones are generated.
メッシュのサイズによっては、配信ホストも参加者になる場合があります。権限のあるサーバーの場合、ゾーンが生成されるホストでもあります。
This document presumes that the usual DNS failover methods are the only ones used to ensure reachability of the data for clients. It does not advise that the routes be withdrawn in the case of failure; it advises instead that the DNS process shutdown so that servers on other addresses are queried. This recommendation reflects a choice between performance and operational complexity. While it would be possible to have some process withdraw the route for a specific server instance when it is not available, there is considerable operational complexity involved in ensuring that this occurs reliably. Given the existing DNS failover methods, the marginal improvement in performance will not be sufficient to justify the additional complexity for most uses.
このドキュメントでは、通常のDNSフェイルオーバー方法が、クライアントのデータの到達可能性を確保するために使用される唯一の方法であると想定しています。障害が発生した場合にルートを撤回することはお勧めしません。代わりに、他のアドレスのサーバーが照会されるようにDNSプロセスをシャットダウンすることをお勧めします。この推奨事項は、パフォーマンスと運用の複雑さの間の選択を反映しています。特定のサーバーインスタンスのルートが利用できない場合に、そのルートでプロセスを撤回することは可能ですが、これが確実に行われるようにするには、操作がかなり複雑になります。既存のDNSフェイルオーバー方法を考えると、パフォーマンスのわずかな改善だけでは、ほとんどの用途で追加の複雑さを正当化するのに十分ではありません。
Though the geographic diversity of server placement helps reduce the effects of service disruptions due to local problems, it is diversity of placement in the network topology which is the driving force behind these distribution practices. Server placement should emphasize that diversity. Ideally, servers should be placed topologically near the points at which the operator exchanges routes and traffic with other networks.
サーバーの配置には地理的な多様性があるため、ローカルの問題によるサービス中断の影響を減らすのに役立ちますが、これらの配布方法の背後にある原動力であるのは、ネットワークトポロジにおける配置の多様性です。サーバーの配置では、その多様性を強調する必要があります。理想的には、サーバーはトポロジー的に、オペレーターがルートやトラフィックを他のネットワークと交換するポイントの近くに配置する必要があります。
The organization administering the mesh of servers sharing a unicast address must have an autonomous system number and speak BGP to its peers. To those peers, the organization announces a route to the network containing the shared-unicast address of the name server. The organization's border routers must then deliver the traffic destined for the name server to the nearest instantiation. Routing to the administrative interfaces for the servers can use the normal routing methods for the administering organization.
ユニキャストアドレスを共有するサーバーのメッシュを管理する組織は、自律システム番号を持ち、ピアとBGPを話す必要があります。これらのピアに対して、組織はネームサーバーの共有ユニキャストアドレスを含むネットワークへのルートをアナウンスします。次に、組織の境界ルーターは、ネームサーバー宛てのトラフィックを最も近いインスタンス化に配信する必要があります。サーバーの管理インターフェースへのルーティングでは、管理組織の通常のルーティング方法を使用できます。
One potential problem with using shared unicast addresses is that routers forwarding traffic to them may have more than one available route, and those routes may, in fact, reach different instances of the shared unicast address. Applications like the DNS, whose communication typically consists of independent request-response messages each fitting in a single UDP packet present no problem. Other applications, in which multiple packets must reach the same endpoint (e.g., TCP) may fail or present unworkable performance characteristics in some circumstances. Split-destination failures may occur when a router does per-packet (or round-robin) load sharing, a topology change occurs that changes the relative metrics of two paths to the same anycast destination, etc.
共有ユニキャストアドレスの使用に伴う潜在的な問題の1つは、トラフィックを転送するルーターに複数の使用可能なルートがあり、それらのルートが実際に共有ユニキャストアドレスの異なるインスタンスに到達する可能性があることです。 DNSのようなアプリケーションは、その通信が通常、それぞれが単一のUDPパケットに収まる独立した要求/応答メッセージで構成され、問題はありません。複数のパケットが同じエンドポイント（TCPなど）に到達しなければならない他のアプリケーションは、状況によっては失敗するか、機能しないパフォーマンス特性を示すことがあります。ルーターがパケット単位（またはラウンドロビン）のロードシェアリングを行う場合、分割宛先の障害が発生する可能性があります。トポロジーの変更が発生し、同じエニーキャスト宛先への2つのパスの相対的なメトリックが変更されます。
Four things mitigate the severity of this problem. The first is that UDP is a fairly high proportion of the query traffic to name servers. The second is that the aim of this proposal is to diversify topological placement; for most users, this means that the coordination of placement will ensure that new instances of a name server will be at a significantly different cost metric from existing instances. Some set of users may end up in the middle, but that should be relatively rare. The third is that per packet load sharing is only one of the possible load sharing mechanisms, and other mechanisms are increasing in popularity.
この問題の深刻度を軽減するために4つのことを行います。 1つ目は、UDPがネームサーバーへのクエリトラフィックのかなり高い割合であることです。 2つ目は、この提案の目的はトポロジー配置を多様化することです。ほとんどのユーザーにとって、これは配置の調整により、ネームサーバーの新しいインスタンスが既存のインスタンスとは大幅に異なるコストメトリックになることを意味します。一部のユーザーは途中で終了する可能性がありますが、それは比較的まれなはずです。 3つ目は、パケットごとのロードシェアリングは可能なロードシェアリングメカニズムの1つにすぎず、他のメカニズムの人気が高まっていることです。
Lastly, in the case where the traffic is TCP, per packet load sharing is used, and equal cost routes to different instances of a name server are available, any DNS implementation which measures the performance of servers to select a preferred server will quickly prefer a server for which this problem does not occur. For the DNS failover mechanisms to reliably avoid this problem, however, those using shared unicast distribution mechanisms must take care that all of the servers for a specific zone are not participants in the same shared-unicast mesh. To guard even against the case where multiple meshes have a set of users affected by per packet load sharing along equal cost routes, organizations implementing these practices should always provide at least one authoritative server which is not a participant in any shared unicast mesh. Those deploying shared-unicast meshes should note that any specific host may become unreachable to a client should a server fail, a path fail, or the route to that host be withdrawn. These error conditions are, however, not specific to shared-unicast distributions, but would occur for standard unicast hosts.
最後に、トラフィックがTCPの場合、パケットごとのロードシェアリングが使用され、ネームサーバーのさまざまなインスタンスへの等コストルートが利用可能です。優先サーバーを選択するサーバーのパフォーマンスを測定するDNS実装は、この問題が発生しないサーバー。ただし、DNSフェイルオーバーメカニズムがこの問題を確実に回避するためには、共有ユニキャスト配布メカニズムを使用するユーザーが、特定のゾーンのすべてのサーバーが同じ共有ユニキャストメッシュに参加していないことに注意する必要があります。複数のメッシュが、等コストルートに沿ったパケットごとのロードシェアリングの影響を受ける一連のユーザーを持つケースからも保護するために、これらのプラクティスを実装する組織は、共有ユニキャストメッシュに参加していない少なくとも1つの信頼できるサーバーを常に提供する必要があります。共有ユニキャストメッシュを展開する場合、サーバーに障害が発生した場合、パスに障害が発生した場合、またはそのホストへのルートが撤回された場合、特定のホストがクライアントに到達できなくなる可能性があることに注意してください。ただし、これらのエラー状態は共有ユニキャスト配布に固有のものではなく、標準のユニキャストホストで発生します。
Since ICMP response packets might go to a different member of the mesh than that sending a packet, packets sent with a shared unicast source address should also avoid using path MTU discovery.
ICMP応答パケットは、パケットを送信するものとは異なるメッシュのメンバーに送信される可能性があるため、共有ユニキャスト送信元アドレスで送信されるパケットも、パスMTUディスカバリーの使用を避ける必要があります。
Appendix A. contains an ASCII diagram of an example of a simple implementation of this system. In it, the odd numbered routers deliver traffic to the shared-unicast interface network and filter traffic from the administrative network; the even numbered routers deliver traffic to the administrative network and filter traffic from the shared-unicast network. These are depicted as separate routers for the ease this gives in explanation, but they could easily be separate interfaces on the same router. Similarly, a local NTP source is depicted for synchronization, but the level of synchronization needed would not require that source to be either local or a stratum one NTP server.
付録Aには、このシステムの簡単な実装例のASCII図が含まれています。その中で、奇数番号のルーターは共有ユニキャストインターフェースネットワークにトラフィックを配信し、管理ネットワークからのトラフィックをフィルタリングします。偶数番号のルーターは、管理ネットワークにトラフィックを配信し、共有ユニキャストネットワークからのトラフィックをフィルタリングします。これらは、説明を簡単にするために個別のルーターとして示されていますが、同じルーター上の個別のインターフェイスである場合もあります。同様に、ローカルのNTPソースが同期のために示されていますが、必要な同期のレベルでは、そのソースがローカルであることも、1つのNTPサーバーである必要もありません。
A single point of contact for reporting problems is crucial to the correct administration of this system. If an external user of the system needs to report a problem related to the service, there must be no ambiguity about whom to contact. If internal monitoring does not indicate a problem, the contact may, of course, need to work with the external user to identify which server generated the error.
このシステムを正しく管理するには、問題を報告するための単一の窓口が重要です。システムの外部ユーザーがサービスに関連する問題を報告する必要がある場合、誰に連絡するかについてのあいまいさがあってはなりません。内部監視で問題が示されない場合は、連絡先が外部ユーザーと協力して、エラーを生成したサーバーを特定する必要がある場合もあります。
As a core piece of Internet infrastructure, authoritative name servers are common targets of attack. The practices outlined here increase the risk of certain kinds of attacks and reduce the risk of others.
権限のあるネームサーバーは、インターネットインフラストラクチャの中核として攻撃の一般的なターゲットです。ここで説明する方法は、特定の種類の攻撃のリスクを高め、他の種類のリスクを減らします。
The architecture outlined in this document increases the number of physical servers, which could increase the possibility that a server mis-configuration will occur which allows for a security breach. In general, the entity administering a mesh should ensure that patches and security mechanisms applied to a single member of the mesh are appropriate for and applied to all of the members of a mesh. "Genetic diversity" (code from different code bases) can be a useful security measure in avoiding attacks based on vulnerabilities in a specific code base; in order to ensure consistency of responses from a single named server, however, that diversity should be applied to different shared-unicast meshes or between a mesh and a related unicast authoritative server.
このドキュメントで説明するアーキテクチャでは、物理サーバーの数が増えるため、サーバーの構成ミスが発生してセキュリティ違反が発生する可能性が高くなります。一般に、メッシュを管理するエンティティは、メッシュの単一のメンバーに適用されたパッチとセキュリティメカニズムがメッシュのすべてのメンバーに適切であり、適用されていることを確認する必要があります。 「遺伝的多様性」（異なるコードベースのコード）は、特定のコードベースの脆弱性に基づく攻撃を回避するのに役立つセキュリティ対策です。ただし、単一の名前付きサーバーからの応答の一貫性を確保するために、その多様性は、異なる共有ユニキャストメッシュに、またはメッシュと関連するユニキャスト権威サーバー間に適用する必要があります。
The level of systemic synchronization described above should be augmented by synchronization of the data present at each of the servers. While the DNS itself is a loosely coupled system, debugging problems with data in specific zones would be far more difficult if two different servers sharing a single unicast address might return different responses to the same query. For example, if the data associated with www.example.com has changed and the administrators of the domain are testing for the changes at the example.com authoritative name servers, they should not need to check each instance of a named authoritative server. The use of NTP to provide a synchronized time for switch-over eliminates some aspects of this problem, but mechanisms to handle failure during the switchover are required. In particular, a server which cannot make the switchover must not roll-back to a previous version; it must cease to respond to queries so that other servers are queried.
上記のシステム同期のレベルは、各サーバーに存在するデータの同期によって強化する必要があります。 DNS自体は疎結合システムですが、単一のユニキャストアドレスを共有する2つの異なるサーバーが同じクエリに対して異なる応答を返す場合、特定のゾーンのデータに関する問題のデバッグははるかに困難になります。たとえば、www.example.comに関連付けられたデータが変更され、ドメインの管理者がexample.comの権威ネームサーバーで変更をテストしている場合、名前付きの権威サーバーの各インスタンスをチェックする必要はありません。 NTPを使用して切り替えの同期時刻を提供すると、この問題の一部の側面が排除されますが、切り替え中に障害を処理するメカニズムが必要です。特に、スイッチオーバーを実行できないサーバーは、以前のバージョンにロールバックしないでください。他のサーバーが照会されるように、照会への応答を停止する必要があります。
If the mechanism used to distribute zone files among the servers is not well secured, a man-in-the-middle attack could result in the injection of false information. Digital signatures will alleviate this risk, but encrypted transport and tight access lists are a necessary adjunct to them. Since zone files will be distributed to the administrative interfaces of meshed servers, the access control list for distribution of the zone files should include the administrative interface of the server or servers, rather than their shared unicast addresses.
サーバー間でゾーンファイルを配布するために使用されるメカニズムが十分に保護されていない場合、中間者攻撃により、誤った情報が注入される可能性があります。デジタル署名はこのリスクを軽減しますが、暗号化されたトランスポートと厳格なアクセスリストはそれらに必要な補助です。ゾーンファイルはメッシュサーバーの管理インターフェイスに配布されるため、ゾーンファイルを配布するためのアクセス制御リストには、共有ユニキャストアドレスではなく、サーバーの管理インターフェイスを含める必要があります。
The increase in number of physical servers reduces the likelihood that a denial-of-service attack will take out a significant portion of the DNS infrastructure. The increase in servers also reduces the effect of machine crashes, fiber cuts, and localized disasters by reducing the number of users dependent on a specific machine.
物理サーバーの数が増えると、サービス拒否攻撃がDNSインフラストラクチャのかなりの部分を奪う可能性が低くなります。サーバーの増加は、特定のマシンに依存するユーザーの数を減らすことにより、マシンのクラッシュ、ファイバーの切断、および局所的な災害の影響も減らします。
Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak, Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato, Suzanne Woolf, Bernard Aboba, Casey Ajalat, and Gunnar Lindberg all provided input and commentary on this work. The editor wishes to remember in particular the contribution of the late Scott Tucker, whose extensive systems experience and plain common sense both contributed greatly to the editor's own deployment experience and are missed by all who knew him.
太田雅孝、ビルマニング、ランディブッシュ、クリスヤーネル、レイプルザック、マークアンドリュース、ロバートエルズ、ジェフヒューストン、ビルノートン、加藤彰、スザンヌウルフ、バーナードアボバ、ケーシーアジャラート、ガンナーリンドバーグのすべてが、この作品に関する意見と解説を提供しました。編集者は、特に故スコットタッカーの貢献を思い出したいと思います。そのスコットタッカーの広範なシステム経験と明白な常識の両方が、編集者自身の展開経験に大きく貢献し、彼を知っているすべての人に見落とされています。
[SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and Operation of Secondary DNS Servers", BCP 16, RFC 2182, July 1997.
[セカンダリ] Elz、R.、Bush、R.、Bradner、S。およびM. Patton、「セカンダリDNSサーバーの選択と操作」、BCP 16、RFC 2182、1997年7月。
[ROOT] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root Name Server Operational Requirements", BCP 40, RFC 2870, June 2000.
[ルート] Bush、R.、Karrenberg、D.、Kosters、M。、およびR. Plzak、「Root Name Server Operational Requirements」、BCP 40、RFC 2870、2000年6月。
[ANYCAST] Patridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[ANYCAST] Patridge、C.、Mendez、T。およびW. Milliken、「Host Anycasting Service」、RFC 1546、1993年11月。
Appendix A.
付録A
__________________
Peer 1-| |
Peer 2-| |
Peer 3-| Switch |
Transit| | _________ _________
etc | |--|Router1|---|----|----------|Router2|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router3|---|----|----------|Router4|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router5|---|----|----------|Router6|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router7|---|----|----------|Router8|---WAN-|
| | --------- | | ---------
| | | |
| | | |
------------------ [NTP] [DNS]
Ted Hardie Nominum, Inc. 2385 Bay Road. Redwood City, CA 94063
Ted Hardie Nominum、Inc. 2385 Bay Road。レッドウッドシティ、カリフォルニア94063
Phone: 1.650.381.6226 EMail: Ted.Hardie@nominum.com
電話：1.650.381.6226メール：Ted.Hardie@nominum.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
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機能への資金提供は、現在Internet Societyから提供されています。