[要約] RFC 5864は、AFS（Andrew File System）のためのDNS SRVリソースレコードに関する仕様です。このRFCの目的は、AFSサーバーの位置情報を効率的に提供し、クライアントが適切なサーバーに接続できるようにすることです。
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
AFSのDNS SRVリソースレコード
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.
このドキュメントは、DNS（ドメイン名サービス）SRV RRS（リソースレコード）の使用方法を指定して、AFS分散ファイルシステムのサービスを見つけ、AFSが使用するサーバーランキングシステムでSRV RRの優先順位と重量値をどのように解釈するかを指定します。RFC 1183を更新して、AFSDB RRの使用を非難してAFSセルデータベースサーバーを見つけ、後方互換性のガイダンスを提供します。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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 Corporationの登録商標）は分散ファイルシステムです（[AFS1]および[AFS2]を参照）。最も広く使用されている実装は[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セルは、1つ以上のボリュームロケーションデータベース（VLDB）サーバー、1つ以上の保護サービス（PTS）サーバー、1つ以上のファイルサーバーとボリュームサーバー、さらにこのドキュメントに関連しない可能性のある追加サービスで構成されています。AFSに保存されているデータは、ボリュームと呼ばれるファイルのコレクションに分割されます。AFSプロトコルクライアントは、特定のAFSセル内のファイルにアクセスするときに、最初にそのセルのVLDBサーバーに連絡して、そのファイルが配置されているAFSボリュームのファイルサーバーを決定し、そのファイルサーバーに直接連絡してファイルにアクセスします。また、クライアントは、そのセル内のファイルにアクセスする前に、そのセルの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：O AFSDB RRが優先度やランキングをサポートしていないといういくつかの利点があり、AFSセル管理者にVLDBサーバーのクライアントが好むべきかを示す方法を示す方法がありません。
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.
o AFSDB RRSには、すべての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 RRSを使用するクライアントは、VLDBおよびPTSサービスが同じホストによって提供されると想定する必要がありますが、VLDBサーバーをPTSサーバーから分離すると便利かもしれません。
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.
これらの理由から、AFSサービスの場所をAFSDB RRからDNS SRV RRSに移動することが望ましいです。
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 RRSの形式と使用について説明し、AFSDB RRを非難します。また、AFSDB RRからDNS SRV RRSへの移行のガイダンスと、後方互換性の推奨事項を提供します。
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 RRSは、[RFC1183]に記載されているように、Open Software Foundation（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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The label of a DNS SRV RR, as defined in [RFC2782], is:
[RFC2782]で定義されているDNS SRV RRのラベルは次のとおりです。
_<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 RRSを使用しません。
<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.
<Proto>は、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.
<name>識別されたサーバーがAFSサービスを提供するAFSセル名でなければなりません。クライアントは、関心のあるAFSセルと正確に一致する<name>値に対してのみDNS SRV RRSをクエリする必要があります。より一般的な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 RRSと同様に、これは、DNS SRV RRSを使用して、命名がDNSの構造と一致するセルのAFSサービスを見つけるためにのみ使用できることを意味します。これはAFSプロトコルの要件ではありませんが、新しいAFSセルを作成するサイトでは、DNSの構造に従い、その結果、管理管理下でDNS SRV RRSが表示される名前を使用する必要があります。これにより、クライアント構成の代わりにDNS SRV RRSの使用が許可され、別々の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 RRSには、優先度と重量が含まれます。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の重量を使用する必要があります。AFSクライアントは、サーバーを選択する際にSRV RRの重みとともにネットワークパフォーマンスやその他のプロトコルメトリックを考慮することができます。これにより、SRV RRSに純粋に基づいたシステムとは異なるサーバーを選択する可能性があります。ただし、そのような情報は、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 RRSは、すべてのDNS RRと同様に、時間（TTL）までの時間（TTL）を持ち、その後SRVレコード情報はもはや有効ではありません（[RFC1034]を参照）。DNS RRSは、TTLの後、およびDNSクエリが繰り返された後に破棄する必要があります。これは、他のDNS RRの場合と同様に、AFSのDNS SRV RRSに適用されます。優先ランクなどのDNS SRV RRSから派生した情報は、DNS SRV RRの有効期限が切れたときに破棄する必要があります。
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 RRSが期限切れになるまで、アルゴリズムの結果を再利用する場合があります。したがって、クライアントは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]のアルゴリズムに従ってこれらのターゲットを順序付けます。次に、最初の選択されたターゲットが最低ランクを持ち、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 RRSの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サーバーの優先ランクは、従来は1〜65535の間の数値です。DNSSRVRR優先順位は0〜65535の数値です。したがって、このアルゴリズムに従う実装は、非常に多数のDNS SRV RRターゲットの非常に多数のDNS SRV RRターゲットの例外的なケースで十分に異なるベースランク値を割り当てる問題に遭遇する可能性があります。異なる優先順位。ただし、有意義に明確な優先順位を持つAFS VLDBまたはPTSサービスの数千のDNS SRV RRターゲットを備えたAFSセル構成は非常にありそうもないことです。AFSクライアントの実装DNS SRV RRに遭遇したのは、優先度のみに基づいてランクのみに基づいてランクを生成し、他のランク入力を無視し、ランクの動的調整を無効にするために、より明確な優先度値を持つターゲットを含むDNS SRV RRを含むターゲットを含む。実装は、少なくとも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 RRSをサポートしているが、DNS SRV RRSをサポートしていないため、DNS SRV RRSを提供するAFSセルもAFSDB RRSを提供する必要があります。ただし、AFSDB RRSは優先順位または重み付け情報を提供していないことに注意してください。ASFDB RRSにリストされているすべてのサーバーは、等しく扱われます。AFSDB RRSもポート情報を提供しません。
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:
したがって、DNS SRV RRSを使用したAFSセルは、次のステートメントがすべて真であるすべてのAFSサーバーをリストするAFSDB RRリストも提供する必要があります。
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 サーバーは、RXを介してUDPを介してこれらのサービスを提供しています。
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.
o サーバーは、DNS SRV RRSにリストされているものの最優先度が低いか、AFSセル管理者は、AFSDB RRSを使用してこのサーバーを好みに使用することが合理的であると考えています。
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.)
上記はデフォルトの推奨事項です。AFSセル管理者は、クライアントがAFSDB RRを使用し、クライアントがDNS SRV RRを使用するかについてのローカルな知識に基づいて、特定の効果に基づいて、AFSDB RRSおよびDNS SRV RRSのサーバーの異なるリストを使用できます。ただし、AFSサーバーは、標準ポートでUDPを介してVLDBおよびPTSサービスを提供しない限り、AFSDB RRSで宣伝しないでください。（これは恥ずかしがり屋であるに違いありません。なぜなら、AFSDB RRを介して、2つのサービスのいずれかを提供するサーバーを介して宣伝するのに役立つかもしれないからです。
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.
AFSセルには、DNS SRV RRサポートのないクライアントが非標準ポート上のサーバーを見つけることができないため、AFSセルにはそれぞれ7003と7002の標準ポートでサービスを提供する少なくとも1つのVLDBと少なくとも1つの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 RRSをクエリングする必要がありますが、DNS SRV RRが見つからない場合はAFSDB RRSに戻る必要があります。DNS SRV RRSがない場合、<SubType> 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.
<Cell>はAFSDB RRのラベル、<TTL>はTTL、<HOSTNAME>は[RFC1183]で指定されているAFSDB RRの<HOSTNAME>値です。これは、サーバーの完全に資格のあるドメイン名です。
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 RRSの可能性の範囲を示すことを目的としています。これは、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.
$ 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.
@ afsdb 1 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
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サービスを提供します。最初の2つは同じ優先順位を持っていますが、AFSDB1がAFSDB2の約2倍のクライアントを獲得する必要があることを示す重みがあります。AFSDB1とAFSDB2にアクセスできない場合、AFSDB3はUDP VLDBサービスにのみ使用し、非標準ポート（65500）でそのサービスを提供します。
Only one host, afsdb1, provides UDP PTS service.
1つのホスト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は、古いクライアントとの後方互換性のために提供されます。AFSDB1のみをリストします。なぜなら、そのホストのみが標準ポートのUDPを介してVLDBサービスとPTSサービスの両方を提供するからです。
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 RRSを使用すると、既存のAFSDB RRと同じセキュリティの問題が発生します。具体的には、DNS応答の整合性と信ity性がチェックされない限り、攻撃者はDNSの応答を偽造し、攻撃者の制御下にあるVLDBまたはPTSサーバーでクライアントを誘導することができます。そこから、攻撃者は、セル内のボリュームとファイルサーバー、およびそのセルのファイルとディレクトリの内容について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 Forgery以外の方法で活用される可能性があります。適切に対処するには、AFSプロトコルの変更が必要で、クライアントは常にAFSサービスを認証し、認定されていないデータを破棄できます。整合性保護を備えたDNSシステムがない場合でも、DNS SRV RRSを追加しても、この脆弱性がより深刻になるわけではなく、別の同等の攻撃ポイントを開きます。
[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] Everhart、C.、Mamakos、L.、Ullmann、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Howard、J.、Kazar、M.、Menees、S.、Nichols、D.、Satyanarayanan、M.、Sidebotham、R.、およびM. West、「分散ファイルシステムのスケールとパフォーマンス」、ACMトランス。コンピューターシステム6（1）、1988年2月。
[AFS2] Howard, J., "An Overview of the Andrew File System", CMU-ITC 88-062, February 1988.
[AFS2] Howard、J。、「Andrew File Systemの概要」、CMU-ITC 88-062、1988年2月。
[ARLA] Assar Westerlund, et al., "Arla", May 2001, <http://www.stacken.kth.se/project/arla/html/arla.html>.
[Arla] Assar Westerlund、et al。、 "Arla"、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 Corporation、et al。、「Openafs Documentation」、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] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティの導入と要件」、RFC 4033、2005年3月。
Author's Address
著者の連絡先
Russ Allbery Stanford University P.O. Box 20066 Stanford, CA 94309 US
ラス・オールベリー・スタンフォード大学P.O.Box 20066 Stanford、CA 94309 US
EMail: rra@stanford.edu
URI: http://www.eyrie.org/~eagle/