RFC3258 日本語訳
3258 Distributing Authoritative Name Servers via Shared UnicastAddresses. T. Hardie. April 2002. (Format: TXT=22195 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Hardie Request for Comments: 3258 Nominum, Inc. Category: Informational April 2002
コメントを求めるワーキンググループT.ハーディー要求をネットワークでつないでください: 3258年のNominum Inc.カテゴリ: 情報の2002年4月
Distributing Authoritative Name Servers via Shared Unicast Addresses
Shared Unicast Addressesを通してAuthoritative Name Serversを分配します。
Status of this Memo
この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)インターネット協会(2002)。 All rights reserved。
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.
このメモは正式のネームサーバオペレータが複数の所在地のただ一つの命名されたサーバへのアクセスを提供するのを可能にすることを意図する1セットの習慣について説明します。 これらの習慣の開発と展開に関するプライマリ動機は、ドメインネームシステム(DNS)サーバの分配を以前にネットワーク形態の誘致圏域の下に増強して、それらの領域でのDNS質問応答のためにレイテンシを減少させることです。
1. Introduction
1. 序論
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.
このメモは正式のネームサーバオペレータが複数の所在地のただ一つの命名されたサーバへのアクセスを提供するのを可能にすることを意図する1セットの習慣について説明します。 これらの習慣の開発と展開に関するプライマリ動機は、以前にネットワーク形態の誘致圏域の下にDNSサーバの分配を増強して、それらの領域でのDNS質問応答のためにレイテンシを減少させることです。 このドキュメントは命名された正式のサーバと管理実体(オペレータ)の間の1〜1つのマッピングを推定します。 このドキュメントはネームサーバをキャッシュするためのどんなガイドラインも推薦も含んでいません。 ここで説明された共有されたユニキャストシステムはIPv4に特定です。 IPv6への適用性はさらなる研究への領域です。 また、ここで説明されたシステムが[ANYCAST]で説明されたそれに関連することに注意されるべきですが、それはそのドキュメントが説明する完全なanycastインフラストラクチャのひたむきなアドレス空間、ルーティング変化、または他の要素を必要としません。
Hardie Informational [Page 1] RFC 3258 Distributing Authoritative Name Servers April 2002
ネームサーバ2002年4月に正式のハーディー情報[1ページ]のRFC3258Distributing
2. Architecture
2. アーキテクチャ
2.1 Server Requirements
2.1 サーバ要件
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質問に応じるべきです。 anycastホストのメッシュから最も一貫した応答を提供するために、そのインタフェースにおける応答をホストが正式であるゾーンに制限するのは、良い習慣です。
2.2 Zone file delivery
2.2 ゾーンファイル配送
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トラフィックのために潜在的ルーティング変化に関する問題を避けるために。
2.3 Synchronization
2.3 同期
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で述べられるように、同じ共有されたユニキャストアドレスを使用するサーバの中の同期の不足はこのサービスの何人かのユーザのために問題を生じさせるかもしれません。 その危険を最小にするために、1つのデータセットから別のデータセットまでのスイッチ-oversはできるだけ調整されるべきです。 参加しているホストとセット回における連動している時計のスイッチ-oversの使用は基礎水準のコーディネートを提供します。 より完全なコーディネートプロセスは以下にかかわるでしょう。
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
a) ゾーンの保全の分配ホストb)確認におけるゾーンの領収書は各サーバでゾーンの保全のメッシュd)確認におけるサーバのすべてにゾーンのc)分配を受けました。
Hardie Informational [Page 2] RFC 3258 Distributing Authoritative Name Servers April 2002
ネームサーバ2002年4月に正式のハーディー情報[2ページ]のRFC3258Distributing
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.
失敗プロセスのメッシュf)団体におけるサーバが受信されなかったサーバがデータを修正できないか、新しさへのデータがやんだ転換が問題まで入って来る質問に応じることができなかったのを保証する転換時間のe)コーディネートを決議できました。
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フェイルオーバーメソッドを考えて、性能におけるわずかな改善は、ほとんどの用途のために追加複雑さを正当化するために十分ではありません。
2.4 Server Placement
2.4 サーバプレースメント
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.
サーバプレースメントの地理的な多様性は、地方の問題によるサービスの崩壊の効果を減少させるのを助けますが、それはこれらの分配練習の後ろの原動力であるネットワーク形態のプレースメントの多様性です。 サーバプレースメントはその多様性を強調するべきです。 理想的に、サーバはオペレータが他のネットワークとルートとトラフィックを交換するポイントの近くに位相的に置かれるべきです。
2.5 Routing
2.5 ルート設定
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
共有されたユニキャストアドレスを使用する1つの潜在的な問題はそれらへのトラフィックが利用可能なルート、およびそれらのルートがそうする1つ以上、事実上範囲の異なったインスタンスを持っているかもしれないそのルータ推進です。
Hardie Informational [Page 3] RFC 3258 Distributing Authoritative Name Servers April 2002
ネームサーバ2002年4月に正式のハーディー情報[3ページ]のRFC3258Distributing
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.
共有されたユニキャストアドレス。 アプリケーションはコミュニケーションがただ一つのUDPパケットプレゼントでそれぞれ問題に全く合わない独立している要求応答メッセージから通常成るDNSが好きです。 他のアプリケーションであり、パケットがどの倍数に同じ終点(例えば、TCP)に達しなければならないかが、いくつかの事情における「非-実行可能」性能の特性を失敗するか、または提示するかもしれません。 ルータがパケット(またはコマドリの周りで)あたりの負荷分割法をすると、分裂目的地失敗は起こるかもしれなくて、2つの経路の相対的な測定基準を同じanycastの目的地などに変えるトポロジー変化は起こります。
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セットのユーザがいるケースにさえ用心するために、これらの習慣を実装する組織はいつもどんな共有されたユニキャストメッシュの関係者でない少なくとも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
付録A.はこのシステムの簡単な実装に関する例のASCIIダイヤグラムを含んでいます。 それでは、変な番号付のルータはトラフィックを管理ネットワークから共有されたユニキャストインタフェースネットワークとフィルタトラフィックに提供します。 同等の番号付のルータ
Hardie Informational [Page 4] RFC 3258 Distributing Authoritative Name Servers April 2002
ネームサーバ2002年4月に正式のハーディー情報[4ページ]のRFC3258Distributing
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.
トラフィックを共有されたユニキャストネットワークから管理ネットワークとフィルタトラフィックに提供してください。 これらはこれが説明で与える容易さのための別々のルータとして描かれますが、それらは容易に同じルータの別々のインタフェースであるかもしれません。 同様に、ローカルのNTPソースは同期のために表現されますが、必要である同期のレベルは地方であるそのソースか層の1NTPのサーバを必要としないでしょう。
3. Administration
3. 政権
3.1 Points of Contact
3.1 連絡先
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.
報告問題のための単一の連絡先はこのシステムの正しい管理に重要です。 システムの社外利用者が、問題がサービスに関連したと報告する必要があるなら、だれに連絡するかに関してあいまいさが全くあるはずがありません。 内部のモニターが問題を示さないなら、接触は、もちろん誤りであると生成されたどのサーバを特定するかために社外利用者と共に働く必要があるかもしれません。
4. Security Considerations
4. セキュリティ問題
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.
1つのコア・ピースのインターネット基盤として、正式のネームサーバは攻撃の一般的な目標です。 ここに概説された習慣は、ある種類の攻撃の危険を増強して、他のものの危険を減少させます。
4.1 Increased Risks
4.1 増強されたリスク
4.1.1 Increase in physical servers
4.1.1 物理的なサーバを増やしてください。
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.
本書では概説されたアーキテクチャは物理的なサーバの数を増強します。(サーバはサーバ誤構成が起こる機密保護違反を考慮する可能性を増強できました)。 一般に、メッシュを管理する実体は、メッシュのメンバーのすべてにメッシュの独身のメンバーに適用されたパッチとセキュリティー対策が確実に適切になるようにして、申し込まれるべきでした。 「遺伝的多様性」(異なったコードベースからのコード)は特定のコードベースの中で脆弱性に基づいた攻撃を避けることにおいて役に立つ安全対策であるかもしれません。 しかしながら、ただ一つの命名されたサーバから応答の一貫性を確実にするために、その多様性はメッシュと、そして、異なった共有されたユニキャストメッシュか関連するユニキャスト正式のサーバの間で適用されるべきです。
4.1.2 Data synchronization problems
4.1.2 データ同期問題
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
上で説明されたシステムの同期のレベルはそれぞれのサーバにおける現在のデータの同期で増大するべきです。 DNS自身は弱連結システム、デバッグですが
Hardie Informational [Page 5] RFC 3258 Distributing Authoritative Name Servers April 2002
ネームサーバ2002年4月に正式のハーディー情報[5ページ]のRFC3258Distributing
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.
ただ一つのユニキャストアドレスを共有する2つの異なったサーバが同じ質問への異なった応答を返すかもしれないなら、特定のゾーンのデータに関する問題ははるかに難しいでしょう。 例えば、www.example.comに関連しているデータが変化して、ドメインの管理者が変化がないかどうかexample.comの正式のネームサーバでテストしているなら、それらは命名された正式のサーバの各インスタンスをチェックする必要はないはずです。オーバー切り替わる連動している時間を提供するNTPの使用はこの問題のいくつかの局面を取り除きますが、転換の間に失敗を扱うメカニズムが必要です。 特に、転換をすることができないサーバは旧バージョンに逆行してはいけません。 それが、質問に応じるのをやめなければならないので、他のサーバは質問されます。
4.1.3 Distribution risks
4.1.3 分配リスク
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.
ゾーンファイルをサーバに分配するのに使用されるメカニズムがよく固定されていないなら、介入者攻撃は偽情報の注射をもたらすかもしれません。 デジタル署名はこの危険を軽減するでしょうが、暗号化された輸送ときついアクセスリストはそれらへの必要な付属物です。 ゾーンファイルがかみ合っているサーバの管理インタフェースに分配されるので、ゾーンファイルの分配のためのアクセスコントロールリストはそれらの共有されたユニキャストアドレスよりむしろサーバかサーバの管理インタフェースを含むべきです。
4.2 Decreased Risks
4.2 減少しているリスク
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インフラストラクチャの重要な部分を取り出すという見込みを減少させます。 また、サーバの増加は、特定のマシンに依存するユーザの数を減少させることによって、マシンクラッシュ、ファイバーカット、およびローカライズしている災害の影響を減少させます。
5. Acknowledgments
5. 承認
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.
Masataka太田、ビル・マニング、ランディ・ブッシュ、クリスYarnell、レイPlzak、マーク・アンドリュース、ロバートElz、ジェフ・ヒューストン、ビルノートン、Akira加藤、スザンヌ・ウルフ、バーナードAboba、ケーシーAjalat、およびグナー・リンドバーグはこの仕事のときに入力と論評をすべて提供しました。 エディタは故スコット・タッカーの貢献を特に覚えていたがっています。(大規模なシステム経験とタッカーの明瞭な常識は、エディタの自己の展開経験に大いに貢献して、彼を知っていたすべてによって逃されています)。
Hardie Informational [Page 6] RFC 3258 Distributing Authoritative Name Servers April 2002
ネームサーバ2002年4月に正式のハーディー情報[6ページ]のRFC3258Distributing
6. References
6. 参照
[SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
and Operation of Secondary DNS Servers", BCP 16, RFC
2182, July 1997.
[2番目]Elz、R.、ブッシュ、R.、ブラドナー、S.、およびM.パットンと、「セカンダリDNSサーバの選択と操作」、BCP16、RFC2182(1997年7月)
[ROOT] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root
Name Server Operational Requirements", BCP 40, RFC 2870,
June 2000.
[根づきます] ブッシュ、R.、Karrenberg(D.、Kosters、M.、およびR.Plzak)は「ネームサーバの操作上の要件を根づきます」、BCP40、RFC2870、2000年6月。
[ANYCAST] Patridge, C., Mendez, T. and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993.
[ANYCAST] PatridgeとC.とメンデスとT.とW.ミリケン、「ホストAnycastingサービス」、RFC1546、1993年11月。
Hardie Informational [Page 7] RFC 3258 Distributing Authoritative Name Servers April 2002
ネームサーバ2002年4月に正式のハーディー情報[7ページ]のRFC3258Distributing
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] |
|
|
|
__________________ 同輩1| | 同輩2| | 同輩3| スイッチ| トランジット| | _________ _________ など| |--|Router1|---|----|----------|Router2|---WAN| | | --------- | | --------- | | | | | | | | | | | ------------------ [NTP][DNS]| | | | | __________________ | 同輩1| | | 同輩2| | | 同輩3| スイッチ| | トランジット| | _________ _________ | など| |--|Router3|---|----|----------|Router4|---WAN| | | --------- | | --------- | | | | | | | | | | | ------------------ [NTP][DNS]| | | | | __________________ | 同輩1| | | 同輩2| | | 同輩3| スイッチ| | トランジット| | _________ _________ | など| |--|Router5|---|----|----------|Router6|---WAN| | | --------- | | --------- | | | | | | | | | | | ------------------ [NTP][DNS]| | | |
Hardie Informational [Page 8] RFC 3258 Distributing Authoritative Name Servers April 2002
ネームサーバ2002年4月に正式のハーディー情報[8ページ]のRFC3258Distributing
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router7|---|----|----------|Router8|---WAN-|
| | --------- | | ---------
| | | |
| | | |
------------------ [NTP] [DNS]
| __________________ | 同輩1| | | 同輩2| | | 同輩3| スイッチ| | トランジット| | _________ _________ | など| |--|Router7|---|----|----------|Router8|---WAN| | | --------- | | --------- | | | | | | | | ------------------ [NTP][DNS]
Hardie Informational [Page 9] RFC 3258 Distributing Authoritative Name Servers April 2002
ネームサーバ2002年4月に正式のハーディー情報[9ページ]のRFC3258Distributing
7. Editor's Address
7. エディタのアドレス
Ted Hardie Nominum, Inc. 2385 Bay Road. Redwood City, CA 94063
テッドハーディーNominum Inc.2385は道路を吠えたてさせます。 レッドウッドシティー、カリフォルニア 94063
Phone: 1.650.381.6226 EMail: Ted.Hardie@nominum.com
以下に電話をしてください。 1.650.381.6226 メールしてください: Ted.Hardie@nominum.com
Hardie Informational [Page 10] RFC 3258 Distributing Authoritative Name Servers April 2002
ネームサーバ2002年4月に正式のハーディー情報[10ページ]のRFC3258Distributing
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Hardie Informational [Page 11]
ハーディーInformationalです。[11ページ]
一覧
スポンサーリンク
