Internet Engineering Task Force (IETF) R. Allbery
Request for Comments: 5864 Stanford University
Updates: 1183 April 2010
Category: Standards Track
ISSN: 2070-1721
DNS SRV Resource Records for AFS
Abstract
抽象
This document specifies how to use DNS (Domain Name Service) SRV RRs (Resource Records) to locate services for the AFS distributed file system and how the priority and weight values of the SRV RR should be interpreted in the server ranking system used by AFS. It updates RFC 1183 to deprecate the use of the AFSDB RR to locate AFS cell database servers and provides guidance for backward compatibility.
この文書では、AFS分散ファイルシステムとどのようにSRV RRの優先順位と重み値がAFSで使用されるサーバーランキングシステムで解釈されるべきであるため、サービスを検索するDNS（ドメインネームサービス）のSRV RRを（リソースレコード）を使用する方法を指定します。これは、AFSセルのデータベース・サーバを検索するAFSDB RRの使用を廃止するためにRFC 1183を更新し、後方互換性のためのガイダンスを提供します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5864.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5864で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Overview and Rationale ..........................................2
2. Scope ...........................................................3
3. Requirements Notation ...........................................3
4. DNS SRV RRs for AFS .............................................4
4.1. Interpretation as AFS Preference Ranks .....................5
5. Use of AFSDB RRs ................................................6
6. Example .........................................................8
7. Security Considerations .........................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
AFS (a registered trademark of IBM Corporation) is a distributed file system (see [AFS1] and [AFS2]). Its most widely used implementations are [OPENAFS] and [ARLA].
AFSは、（IBM社の登録商標）分散ファイルシステム（[AFS2] [AFS1]参照）です。その最も広く使用されている実装では、[OpenAFSの]と[ARLA]です。
AFS is organized administratively into cells. Each AFS cell consists of one or more Volume Location Database (VLDB) servers, one or more Protection Service (PTS) servers, and one or more file servers and volume servers, plus possible additional services not relevant to this document. Data stored in AFS is divided into collections of files called volumes. An AFS protocol client, when accessing a file within a specific AFS cell, first contacts a VLDB server for that cell to determine the file server for the AFS volume in which that file is located, and then contacts that file server directly to access the file. A client may also need to contact a PTS server for that cell to register before accessing files in that cell or to query protection database information.
AFSは、細胞内に行政組織化されています。各AFSセルは、一つ以上のボリューム・ロケーション・データベース（VLDB）のサーバー、一つ以上の保護サービス（PTS）のサーバ、および1つまたは複数のファイルサーバーとボリューム・サーバー、プラス、このドキュメントに関連していない可能性の追加サービスで構成されています。 AFSに格納されたデータは、ボリュームと呼ばれるファイルのコレクションに分かれています。 AFSプロトコルクライアント、特定のAFSセル内のファイルにアクセスし、そのファイルが配置されているAFSボリュームのファイルサーバを決定するために、そのセルの第一コンタクトVLDBサーバ、ファイルをアクセスするために、直接サーバファイルコンタクト。また、クライアントは、そのセル内のファイルにアクセスする前に登録したり、保護データベースの情報を照会するために、そのセルのためのPTSサーバに連絡する必要があるかもしれません。
An AFS client therefore needs to determine, for a given AFS cell, the VLDB and possibly the PTS servers for that cell. (Traditionally, the VLDB and PTS servers are provided by the same host.) Once the client is in contact with the VLDB server, it locates file and volume servers through AFS protocol queries to the VLDB server. Originally, VLDB server information was configured separately on each client in a file called the CellServDB file. [RFC1183] specified the DNS RR (Resource Record) AFSDB to locate VLDB servers for AFS.
AFSクライアントは、したがって、そのセルの特定のAFSセル、VLDBおよびおそらくPTSサーバに対して、決定する必要があります。 （伝統的に、VLDBとPTSサーバが同じホストによって提供されている。）クライアントがVLDBサーバーと接触していると、それはVLDBサーバーにAFSプロトコルクエリを介してファイルとボリュームサーバを見つけ。もともと、VLDBサーバー情報は、CellServDBファイルと呼ばれるファイル内の各クライアントに個別に設定されました。 [RFC1183]はAFSためVLDBサーバーを見つけるためにDNS RR（リソースレコード）AFSDBを指定しました。
Subsequent to [RFC1183], a general DNS RR was defined by [RFC2782] for service location for any service. This DNS SRV RR has several advantages over the AFSDB RR: o AFSDB RRs do not support priority or ranking, leaving AFS cell administrators without a way to indicate which VLDB servers clients should prefer.
[RFC1183]に続いて、一般的なDNSのRRは、任意のサービスのサービスロケーションは[RFC2782]で定義されました。このDNS SRV RRはAFSDBのRRに比べていくつかの利点ました：AFSDBのRR oはVLDBサーバクライアントが好むすべきかを示すための方法なしにAFSセルの管理者を残し、優先順位やランク付けをサポートしていません。
o AFSDB RRs do not include protocol or port information, implicitly assuming that all VLDB servers will be contacted over the standard port and the UDP. Future changes to the AFS protocol may require separate VLDB server lists for UDP and TCP traffic, and some uses of AFS, such as providing VLDB service for multiple cells from the same systems, require use of different ports.
AFSDBのRR oを暗黙的にすべてのVLDBサーバが標準ポートおよびUDP上で連絡されることを想定し、プロトコルまたはポート情報が含まれていません。 AFSプロトコルへの今後の変更は、UDPおよびTCPトラフィック用に別のVLDBサーバーのリストを必要とし、このように同じシステムからの複数のセルのためのVLDBサービスを提供するなど、AFSのいくつかの用途、異なるポートを使用する必要があります。
o Clients using AFSDB RRs must assume that VLDB and PTS services are provided by the same host, but it may be useful to separate VLDB servers from PTS servers.
O AFSDB RRを使用するクライアントは、VLDBとPTSのサービスが同じホストによって提供されていることを前提としなければならないが、PTSサーバからVLDBサーバを分離するのに有用である可能性があります。
o DNS SRV RRs are in widespread use, whereas AFSDB RRs are a little-known and little-supported corner of the DNS protocol.
OのDNS SRVのRRはAFSDBのRRは、DNSプロトコルの既知少ないとほとんどサポートコーナーであるのに対し、広く使用されています。
For those reasons, it is desirable to move AFS service location from the AFSDB RR to DNS SRV RRs.
これらの理由のために、DNS SRV資源レコードにAFSDB RRからAFSサービスの場所を移動させることが望ましいです。
This document describes the format and use of DNS SRV RRs for AFS service location and deprecates the AFSDB RR. It also provides guidance for transition from the AFSDB RR to DNS SRV RRs and recommendations for backward compatibility.
この文書では、AFSサービスの場所のためのDNS SRV RRの形式と使用方法について説明してAFSDBのRRを非難します。また、下位互換性のためのDNS SRV資源レコードと勧告にAFSDB RRから移行するためのガイダンスを提供します。
Documentation of the AFS protocol, the exact purpose and use of the VLDB and PTS services, and other information about AFS are outside the scope of this document.
AFSプロトコル、VLDBおよびPTSサービスの正確な目的と使用、およびAFSに関するその他の情報の文書は、この文書の範囲外です。
AFSDB RRs may also be used for locating servers for the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE) authenticated naming system, as described in [RFC1183]. Service location for DCE servers is outside the scope of this document and is not modified by this specification.
AFSDB RRはまた、[RFC1183]に記載されているように、システムを命名認証オープンソフトウェア財団（OSFの）分散コンピューティング環境（DCE）のためのサーバの位置を突き止めるために使用することができます。 DCEサーバのサービスの場所は、この文書の範囲外であり、本明細書によって変更されません。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The label of a DNS SRV RR, as defined in [RFC2782], is:
DNSのSRV RRのラベルは、[RFC2782]で定義されるように、です。
_<service>._<proto>.<name>
_ <サービス> ._ <プロト>。<名前>
The following values for <service> advertise servers providing AFS services:
<サービス>に次の値は、AFSサービスを提供するサーバーを宣伝します：
afs3-vlserver: servers providing AFS VLDB services.
afs3-のvlserver：AFS VLDBサービスを提供するサーバ。
afs3-prserver: servers providing AFS PTS services.
afs3-prserver：AFS PTSサービスを提供するサーバ。
Other AFS services, such as file and volume management services, are located through the VLDB service and therefore do not use DNS SRV RRs.
そのようなファイルやボリューム管理サービスなどの他のAFSサービスは、VLDBサービスを介して位置しているので、DNSのSRVのRRを使用しないでください。
<proto> MUST be "udp" for the current AFS protocol, which uses Rx over UDP. Other values may be used for future revisions of the AFS protocol supporting other protocols, such as Rx over TCP.
<プロト>はUDP上のRxを使用して現在のAFSプロトコルは、「UDP」でなければなりません。他の値は、TCP上のRxのような他のプロトコルをサポートAFSプロトコルの将来の改訂のために使用することができます。
<name> MUST be the AFS cell name for which the identified server provides AFS services. Clients MUST query DNS SRV RRs only for a <name> value exactly matching the AFS cell of interest. They MUST NOT remove leading components to search for more general DNS SRV RRs. The AFS cell "prod.example.com" and the AFS cell "example.com" are entirely different cells in the AFS protocol and VLDB servers for the latter cannot provide information for the former.
<名前>識別されるサーバーは、AFSサービスを提供するためにAFSセル名でなければなりません。クライアントは、のみ正確に関心のAFSセルに一致する<名前>値のDNS SRVのRRを照会しなければなりません。彼らは、より一般的なDNSのSRV RRを検索するための主要なコンポーネントを削除してはなりません。 AFS細胞「prod.example.com」とAFSセル「example.com」は、AFSプロトコルに全く異なる細胞であり、後者はVLDBサーバーは、前者の情報を提供することができません。
NOTE: As with AFSDB RRs, this means that DNS SRV RRs can only be used to locate AFS services for cells whose naming matches the structure of the DNS. This is not a requirement of the AFS protocol, but sites creating new AFS cells SHOULD use names that follow the structure of the DNS and that result in DNS SRV RRs under their administrative control. This both permits use of DNS SRV RRs instead of client configuration and helps avoid naming conflicts between separate AFS cells.
注：AFSDBのRRと同じように、これはDNS SRV RRのが唯一のその命名DNSの構造に一致するセルのAFSサービスを見つけるために使用できることを意味します。これは、AFSプロトコルの要件ではないが、新しいAFSセルを作成するサイトでは、管理下のDNS SRVのRRの中にDNSの構造とその結果に従う名前を使用すべきです。これは、DNS SRV RRの使用の代わりに、クライアントの設定を可能にし、別のAFSセル間の名前の競合を避けることができます両方。
DNS SRV RRs include a priority and a weight. As defined in the DNS SRV RR specification [RFC2782], clients MUST attempt to contact the target host with the lowest-numbered priority they can reach. AFS clients that use a ranked algorithm to determine which server to contact MUST therefore assign a sufficiently distinct rank to targets with different priorities such that targets with a higher-numbered priority are only contacted if all targets with a lower-numbered priority are inaccessible. See Section 4.1 for more information.
DNS SRV RRは優先度と重みがあります。 DNS SRV RRの仕様[RFC2782]で定義されるように、クライアントは、彼らが到達できる最低の番号の優先度でターゲットホストに連絡しようとしなければなりません。ランク付けアルゴリズムを使用するAFSクライアントは、したがって、より低い番号の優先度のすべてのターゲットがアクセス不能である場合、より高い番号の優先度を持つターゲットのみ接触するように異なる優先度を有する標的に十分に異なるランクを割り当てる必要があり連絡先のサーバを決定します。詳細については、セクション4.1を参照してください。
If there are multiple targets with an equal priority, the weight value of the DNS SRV RR SHOULD be used as input to a weighted algorithm for selecting servers. As specified by [RFC2782], larger weights SHOULD be given a proportionately higher probability of being selected. In the presence of records containing weights greater than 0, records with weight 0 should have a very small chance of being selected. A weight of 0 SHOULD be used if all targets with that priority are weighted equally. AFS clients MAY take into account network performance and other protocol metrics along with SRV RR weights when selecting servers, thereby possibly selecting different servers than a system based purely on the SRV RRs would indicate. However, such information MUST NOT override the priority information in the SRV RR.
等しい優先度を持つ複数のターゲットが存在する場合、DNS SRV RRの重み値は、サーバーを選択するための重み付けアルゴリズムへの入力として使用されるべきです。 [RFC2782]によって指定されるように、より大きな重みが選択されるのに比例してより高い確率が与えられるべきです。 0より大きい重みを含むレコードの存在下で、重量が0のレコードが選択されるの非常に小さなチャンスを有するべきです。その優先度のすべてのターゲットが等しく重み付けされる場合は、0の重みが使用されるべきです。それによって、おそらく示すことになるのSRV RRのに純粋に基づいたシステムよりも、別のサーバーを選択し、サーバを選択する際にAFSクライアントは、SRVのRRの重みと一緒にアカウントのネットワークパフォーマンスと他のプロトコルのメトリックにかかる場合があります。しかし、そのような情報は、SRV RRの中で優先度情報を上書きしてはなりません。
DNS SRV RRs, like all DNS RRs, have a time-to-live (TTL), after which the SRV record information is no longer valid (see [RFC1034]). DNS RRs SHOULD be discarded after their TTL, and after the DNS query repeated. This applies to DNS SRV RRs for AFS as it does for any other DNS RR. Any information derived from the DNS SRV RRs, such as preference ranks, MUST be discarded when the DNS SRV RR is expired.
DNS SRV RRのは、すべてのDNSのRRのように、生存時間（TTL）、SRVレコード情報が有効でなくなった後を持っている（参照[RFC1034]）。 DNSのRRはそのTTL後に破棄、およびDNSクエリの後に繰り返さなければなりません。それは、他のDNS RRの場合と同様にこれは、AFS用のDNS SRVのRRに適用されます。 DNSのSRV RRの有効期限が切れている場合、このような優先順位としてのDNS SRV資源レコードから誘導される任意の情報は、破棄されなければなりません。
Implementations are not required to re-run the weighted server selection algorithm for each call. Instead, they MAY reuse the results of the algorithm until the DNS SRV RRs expire. Clients could therefore use a specific server for the lifetime of the DNS SRV records, which may affect the load distribution properties that DNS SRV records provide. Server operators should account for this effect when setting the TTL of those records.
実装は呼び出しごとに重み付けされたサーバ選択アルゴリズムを再実行する必要はありません。 DNSのSRV RRを有効期限が切れるまでその代わりに、彼らは、アルゴリズムの結果を再利用することができます。クライアントは、そのためのDNS SRVレコードが提供する負荷分散特性に影響を与える可能性がある、DNS SRVレコードの寿命のために特定のサーバーを使用することができます。それらのレコードのTTLを設定する際にサーバーオペレータは、この効果を考慮する必要があります。
AFS clients MAY remember which targets are inaccessible by that client and ignore those targets when determining which server to contact first. Clients that do this SHOULD have a mechanism to retry targets that were previously inaccessible and reconsider them according to their current priority and weight if they become accessible again.
AFSクライアントは、クライアントがアクセスできないであるターゲット覚えていて、最初に連絡するサーバーを決定する際にこれらのターゲットを無視するかもしれません。これを実行するクライアントは、以前にアクセスできなかった目標を再試行する仕組みを持っており、彼らは再びアクセス可能になった場合、現在の優先度と重量に応じてそれらを再検討すべきです。
Several AFS implementations use a ranking algorithm that assigns numbers representing a preference rank to each server when the client first contacts that AFS cell and then prefers the server with the lowest rank unless that server goes down. Clients using this algorithm SHOULD assign their ranks as follows:
いくつかのAFSの実装では、そのサーバーがダウンしない限り、AFSセルと、その後は最低ランクでサーバーを好むクライアント最初に接触する各サーバに優先順位を表す番号を割り当てランキングアルゴリズムを使用します。次のようにこのアルゴリズムを使用しているクライアントは、自分のランクを割り当てる必要があります：
1. Sort targets by priority and assign a base rank value to each target based on its priority. Each base rank value MUST be sufficiently different from the base rank assigned to any higher-numbered priority so that higher-numbered targets will only be attempted if lower-numbered targets cannot be reached. It MUST, in other words, be farther from the base rank of any distinct priority than any possible automatic adjustment in the rank. When calculating base ranks, observe that the numeric value of a priority has no meaning. Only the ordering of distinct priority values between multiple SRV RR targets needs to be reflected in the base ranks.
優先1.ソート対象とその優先順位に基づいて、各ターゲットに基地ランク値を割り当てます。各基地ランク値は、より低い番号のターゲットに到達できない場合、より高い番号のターゲットのみ試行されるように、任意のより高い番号の優先順位に割り当てられたベースランクから十分に異なっていなければなりません。これは、換言すれば、ランクの任意の可能な自動調整以外の任意の異なる優先順位のベースランクから離れなければなりません。基本ランクを計算する場合、優先順位の数値が意味を持たないことを確認します。複数のSRV RRターゲットとの間の明確な優先度の値の唯一の順序は、ベースランクに反映する必要があります。
2. For each group of targets with the same priority, follow the algorithm in [RFC2782] to order those targets. Then, assign those targets ranks formed by incrementing the base weight for that priority such that the first selected target has the lowest rank, the second selected target has the next-lowest rank, and so on.
同じ優先度を持つターゲットのグループごとに2、これらのターゲットを注文する[RFC2782]にアルゴリズムに従います。そして、第1の選択されたターゲットが最低ランクを有するように、その優先順位のベース重量を増分することによって形成されるものターゲットランクを割り当て、第2の選択されたターゲットは、その次に低いランクとを有しています。
After assignment of ranks, the AFS client MAY then adjust the ranks dynamically based on network performance and other protocol metrics, provided that such adjustments are sufficiently small compared to the difference between base ranks that they cannot cause servers with a higher-numbered priority to be contacted instead of a server with a lower-numbered priority.
ランクの割り当て後、AFSクライアントは、ネットワークのパフォーマンスと他のプロトコルのメトリックに基づいて動的ランクを調整することができる、そのような調整は、ベースとの間の差に比べて十分に小さいことを条件とする、彼らは高い番号の優先順位のサーバがあることを起こさないことをランク低い番号の優先順位ではなく、サーバーの連絡。
The TTL of the DNS SRV RRs MUST be honored by invalidating and regenerating the server preference ranks with new DNS information once that TTL has expired. However, accumulated network and protocol metrics may be retained and reapplied to the new rankings.
DNS SRV RRのTTLは、TTLの有効期限が切れた後にサーバーの優先は、新しいDNS情報でランク無効にし、再生することにより表彰されなければなりません。しかし、蓄積されたネットワークとプロトコルのメトリックは保持され、新しいランキングに再適用することができます。
AFS server preference ranks are conventionally numbers between 1 and 65535. DNS SRV RR priorities are numbers between 0 and 65535. Implementations following this algorithm could therefore encounter problems assigning sufficiently distinct base rank values in exceptional cases of very large numbers of DNS SRV RR targets with different priorities. However, an AFS cell configuration with thousands of DNS SRV RR targets for an AFS VLDB or PTS service with meaningfully distinct priorities is highly improbable. AFS client implementations encountering a DNS SRV RR containing targets with more distinct priority values than can be correctly represented as base ranks SHOULD fall back to generating ranks based solely on priorities, ignoring other rank inputs, and disabling dynamic adjustment of ranks. Implementations MUST be able to assign distinct base ranks as described above for at least ten distinct priority values.
AFSサーバーの優先順位このアルゴリズム下記0〜65535実装の間の数字は、したがってとのDNS SRV RRの標的の非常に多数の例外的な場合に十分に異なる基地ランク値を割り当てる問題が発生する可能性が1〜65535 DNS SRV RRの優先度との間に従来の数字されています異なる優先順位。しかし、意味の異なる優先度を持つAFS VLDBまたはPTSサービスのDNS SRV RRの目標の数千とAFSセル構成は非常にありそうです。正しく塩基ランクのように表すことができるよりも多くの異なる優先度値を持つ標的を含むDNS SRV RRを遭遇AFSクライアント実装はバック、単に優先順位に基づいてランクを生成する他のランクの入力を無視し、そしてランクの動的調整を無効に落ちるべきです。少なくとも10個の異なる優先値について上記のような実装は、異なる基地ランクを割り当てることができなければなりません。
Since many AFS client implementations currently support AFSDB RRs but do not support DNS SRV RRs, AFS cells providing DNS SRV RRs SHOULD also provide AFSDB RRs. However, be aware that AFSDB RRs do not provide priority or weighting information; all servers listed in ASFDB RRs are treated as equal. AFSDB RRs also do not provide port information.
多くのAFSクライアント実装は、現在AFSDB RRをサポートしますが、DNSのSRVのRRをサポートしていないので、DNSのSRVのRRを提供するAFS細胞もAFSDB RRを提供する必要があります。しかし、AFSDBのRRは、優先順位や重み付け情報を提供しないことに注意してください。 ASFDBのRRに記載されているすべてのサーバが同じとして扱われます。 AFSDB RRはまた、ポート情報を提供していません。
An AFS cell using DNS SRV RRs SHOULD therefore also provide an AFSDB RR listing all AFS servers for which the following statements are all true:
したがって、次の文はすべて真であるため、すべてのAFSサーバをリストAFSDBのRRを提供するDNS SRVのRRを使用してAFSセル：
o The server provides both VLDB and PTS service on the standard ports (7003 and 7002, respectively).
Oサーバは、標準ポート（それぞれ7003および7002）の両方のVLDBとPTSのサービスを提供します。
o The server provides these services via Rx over UDP.
OサーバはUDP上でのRxを経由して、これらのサービスを提供します。
o The server either has the lowest-numbered priority of those listed in the DNS SRV RRs or the AFS cell administrator believes it reasonable for clients using AFSDB RRs to use this server by preference.
サーバーは、DNS SRVのRRの中に列挙されたものの最も低い番号の優先順位を持っているのいずれかまたはAFSセルの管理者は、好みによって、このサーバーを使用するようにAFSDB RRを使用しているクライアントのために、それが合理的と考えているoを。
The above is a default recommendation. AFS cell administrators MAY use different lists of servers in the AFSDB RRs and DNS SRV RRs if desired for specific effects based on local knowledge of which clients use AFSDB RRs and which clients use DNS SRV RRs. However, AFS servers SHOULD NOT be advertised with AFSDB RRs unless they provide VLDB and PTS services via UDP on the standard ports. (This falls shy of MUST NOT because it may be useful in some unusual circumstances to advertise, via an AFSDB RR, a server that provides only one of the two services, but be aware that such a configuration may confuse legacy clients.)
上記はデフォルトの勧告です。クライアントは、クライアントがDNS SRVのRRを使用AFSDB RRを使用し、その地域の知識に基づいて特定の効果のために必要に応じて、AFSセルの管理者はAFSDBのRRとDNS SRV RRの中のサーバの異なるリストを使用するかもしれません。彼らは標準ポートにUDP経由VLDBとPTSのサービスを提供しない限り、しかし、AFSサーバはAFSDBのRRで広告されるべきではありません。 （これはAFSDB RR、唯一の2つのサービスのいずれかを提供するサーバを経由して、それを宣伝するためにいくつかの特殊な状況で有用であるとは限らないのでMUSTの恥ずかしがり屋落ちるが、そのような設定がレガシークライアントを混乱させる可能性があることに注意してください。）
An AFS cell SHOULD have at least one VLDB and at least one PTS server providing service on the standard ports of 7003 and 7002, respectively, since clients without DNS SRV RR support cannot locate servers on non-standard ports.
DNSのSRVのRRをサポートしていないクライアントが非標準ポート上のサーバーを見つけることができませんので、AFSセルは、それぞれ、少なくとも一つのVLDBおよび7003と7002の標準ポート上でサービスを提供する少なくとも一つのPTSサーバを持っているべきです。
Clients SHOULD query DNS SRV RRs by default but SHOULD then fall back on AFSDB RRs if no DNS SRV RRs are found. In the absence of DNS SRV RRs, an AFSDB RR of <subtype> 1 SHOULD be treated as equivalent to the following pair of DNS SRV RRs:
クライアントは、デフォルトでは、DNSのSRVのRRを問い合わせる必要がありますが、何のDNS SRV RRをが見つからない場合は、その後AFSDBのRRに頼るべきです。 DNS SRV RRの非存在下で、<サブタイプ> 1のAFSDB RRは、DNS SRVのRRの次のペアと同等に扱われるべきです。
_afs3-vlserver._udp.<cell> <ttl> IN SRV 0 0 7003 <hostname>
_afs3-prserver._udp.<cell> <ttl> IN SRV 0 0 7002 <hostname>
<cell> is the label of the AFSDB RR, <ttl> is its TTL and <hostname> is the <hostname> value of the AFSDB RR as specified in [RFC1183]. This is the fully-qualified domain name of the server.
<細胞>はAFSDB RRのラベルは、<TTL>そのTTLと<hostname>は、[RFC1183]で指定されるようAFSDB RRの<ホスト名>の値です。これは、サーバーの完全修飾ドメイン名です。
The following example includes TCP AFS services, separation of a PTS server from a VLDB server, and use of non-standard ports, all features that either assume future AFS protocol development or are not widely supported by current clients. This example is intended to show the range of possibilities for AFS DNS SRV RRs, not as a practical example for an existing cell. This is a part of the zone file for a fictional example.com domain with AFS services.
次の例では、TCP AFSサービス、VLDBサーバーからPTSサーバの分離、および非標準ポートの使用、将来のAFSプロトコルの開発を想定してか、現在広く普及しているクライアントによってサポートされていないいずれかのすべての機能が含まれています。この例ではない既存のセルのための実用的な例として、AFS DNS SRV RRのための可能性の範囲を示すことを意図しています。これは、AFSサービスとの架空example.comドメインのゾーンファイルの一部です。
$ORIGIN example.com.
@ SOA dns.example.com. root.example.com. (
2009100201 3600 3600 604800 86400 )
NS dns.example.com.
_afs3-vlserver._udp SRV 0 2 7003 afsdb1.example.com.
_afs3-vlserver._udp SRV 0 4 7003 afsdb2.example.com.
_afs3-vlserver._udp SRV 1 0 65500 afsdb3.example.com.
_afs3-vlserver._tcp SRV 0 0 7003 afsdb3.example.com.
_afs3-vlserver._tcpのSRV 0 0 7003 afsdb3.example.com。
_afs3-prserver._udp SRV 0 0 7002 afsdb1.example.com.
_afs3-prserver._udpのSRV 0 0 7002 afsdb1.example.com。
_afs3-prserver._tcp SRV 0 0 7002 afsdb3.example.com.
_afs3-prserver._tcpのSRV 0 0 7002 afsdb3.example.com。
@ AFSDB 1 afsdb1.example.com.
@ 1 AFSDB afsdb1.example.com。
dns A 192.0.2.9 afsdb1 A 192.0.2.10 afsdb2 A 192.0.2.11 afsdb3 A 192.0.2.12
192.0.2.12 afsdb3 192.0.2.11 afsdb2 192.0.2.10 afsdb1 192.0.2.9をDNS
In this example, the AFS cell name is example.com.
この例では、AFSセル名はexample.comです。
afsdb1, afsdb2, and afsdb3 all provide VLDB service via UDP. The first two have the same priority but have weights indicating that afsdb1 should get about twice as many clients as afsdb2. afsdb3 should only be used for UDP VLDB service if afsdb1 and afsdb2 are not accessible and provides that service on a non-standard port (65500).
afsdb1、afsdb2、およびafsdb3すべてはUDP経由VLDBサービスを提供しています。最初の二つは同じ優先順位を持っていますが、afsdb1がafsdb2の約2倍の多くのクライアントを取得する必要があることを示す重みを持っています。 afsdb1とafsdb2はアクセスできませんし、非標準のポート（65500）にそのサービスを提供する場合afsdb3のみUDP VLDBサービスのために使用すべきです。
Only one host, afsdb1, provides UDP PTS service.
一つだけのホスト、afsdb1は、UDP PTSのサービスを提供しています。
afsdb3 provides a hypothetical TCP version of AFS VLDB and PTS service on the standard ports and is the only server providing these services over TCP for this cell. Such a TCP-based AFS protocol did not exist at the time this document was written. This example only shows what the record would look like in a hypothetical future if such a protocol were developed.
afsdb3は標準ポート上でAFS VLDBおよびPTSサービスの仮想的なTCPのバージョンを提供し、このセルのためにTCP上でこれらのサービスを提供する唯一のサーバーです。このようなTCPベースのAFSプロトコルは、この文書が書かれた時点で存在しませんでした。この例では唯一のそのようなプロトコルが開発された場合、レコードは架空の未来にどのように見えるかを示しています。
An AFSDB RR is provided for backward compatibility with older clients. It lists only afsdb1, since only that host provides both VLDB and PTS service over UDP on the standard ports.
AFSDB RRは、古いクライアントとの下位互換性のために提供されます。そのホストのみが標準ポートにUDP経由VLDBとPTSの両方のサービスを提供していますので、それは、唯一のafsdb1示しています。
Use of DNS SRV RRs for AFS service locations poses the same security issues as the existing AFSDB RRs. Specifically, unless the integrity and authenticity of the DNS response are checked, an attacker may forge DNS replies and thereby direct clients at a VLDB or PTS server under the control of the attacker. From there, the attacker may deceive an AFS client about the volumes and file servers in a cell and about the contents of files and directories in that cell. If the client uses cell data in a trusted way, such as by executing programs out of that AFS cell or using data from the cell as input to other programs, the attacker may be able to further compromise the security of the client and trick it into taking action under the attacker's control.
AFSサービスの場所のためのDNS SRV RRの使用は、既存のAFSDBのRRと同じセキュリティ上の問題を提起します。 DNS応答の完全性と真正性が確認されない限り、具体的には、攻撃者が攻撃者の制御下VLDBまたはPTSサーバにDNS応答し、それによって直接クライアントを偽造することができます。そこから、攻撃者は、細胞内のボリュームやファイルサーバについて、そのセル内のファイルやディレクトリの内容について、AFSクライアントを欺くことがあります。クライアントは、そのAFSセルからプログラムを実行するか、他のプログラムへの入力としてセルからのデータを使用するなど、信頼できる方法で、セル・データを使用している場合、攻撃者は、さらに、クライアントのセキュリティを侵害しにそれをだますことができるかもしれませ攻撃者の管理下に行動をとります。
This attack can be prevented if the server is authenticated, since the client can then detect a failure to authenticate the attacker's servers and thereby detect possible impersonation. However, this applies only to authenticated AFS access, and much AFS access is unauthenticated. Furthermore, clients after failure to authenticate may fall back to unauthenticated access, which the attacker's servers may permit.
サーバが認証された場合、クライアントはその後、攻撃者のサーバを認証するための障害を検出し、それによって可能な偽装を検出することができますので、この攻撃を防止することができます。しかし、これが唯一の認証されたAFSアクセスに適用され、多くのAFSアクセスが認証されていないです。さらに、認証に失敗した後、クライアントは攻撃者のサーバが許可することができる認証されていないアクセス、にフォールバックします。
Using an integrity-protected DNS system such as DNS Security (DNSSEC) [RFC4033] can prevent this attack via DNS. However, the underlying vulnerability is inherent in the current AFS protocol and may be exploited in ways other than DNS forgery, such as by forging the results of VLDB queries for an AFS cell. Addressing it properly requires changes to the AFS protocol allowing clients to always authenticate AFS services and discard unauthenticated data. Even in the absence of a DNS system with integrity protection, addition of DNS SRV RRs does not make this vulnerability more severe, only opens another equivalent point of attack.
そのようなDNSセキュリティ（DNSSEC）[RFC4033]と整合性が保護DNSシステムを使用すると、DNS経由でこの攻撃を防ぐことができます。しかし、基本的な脆弱性は、現在のAFSプロトコルに固有であり、そのようなAFSセルに対してVLDBクエリの結果を偽造するなどのDNS偽造以外の方法で利用することができます。それを適切に対処するには、クライアントが常にAFSサービスを認証し、認証されていないデータを破棄することができAFSプロトコルを変更する必要があります。でも、完全性保護とDNSシステムが存在しない場合に、DNS SRV RRの追加だけで、攻撃の他の同等のポイントを開き、この脆弱性は、より深刻なことはありません。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
[RFC1183]エバハート、C.、Mamakos、L.、ウルマン、R.、およびP. Mockapetris、 "新しいDNS RRの定義"、RFC 1183、1990年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsenの、A.、いるVixie、P.、およびL. Esibov、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2782、2000年2月。
[AFS1] Howard, J., Kazar, M., Menees, S., Nichols, D., Satyanarayanan, M., Sidebotham, R., and M. West, "Scale and Performance in a Distributed File System", ACM Trans. on Computer Systems 6(1), February 1988.
【AFS1】ハワード、J.、Kazar、M.、Menees、S.、ニコルズ、D.、Satyanarayanan、M.、Sidebotham、R.、およびM.西、 "分散ファイルシステムにおけるスケールとパフォーマンス"、ACMトランス。コンピュータシステム6の（1）、1988年2月。
[AFS2] Howard, J., "An Overview of the Andrew File System", CMU-ITC 88-062, February 1988.
[AFS2]ハワード、J.、 "アンドリューファイルシステムの概要"、CMU-ITC 88から062、1988年2月。
[ARLA] Assar Westerlund, et al., "Arla", May 2001, <http://www.stacken.kth.se/project/arla/html/arla.html>.
【EARLY] Assarウェスターら、 "アルラ"、2001年5月<http://www.stacken.kth.se/project/arla/html/arla.html>。
[OPENAFS] IBM Corporation, et al., "OpenAFS Documentation", April 2000, <http://docs.openafs.org/>.
[OpenAFSの] IBMコーポレーション、ら、 "OpenAFSのマニュアル"、2000年4月、<http://docs.openafs.org/>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
Author's Address
著者のアドレス
Russ Allbery Stanford University P.O. Box 20066 Stanford, CA 94309 US
ラスAllberyスタンフォード大学の私書箱20066スタンフォード、CA 94309米国箱
EMail: rra@stanford.edu URI: http://www.eyrie.org/~eagle/
電子メール：rra@stanford.edu URI：http://www.eyrie.org/~eagle/