[要約] RFC 6641は、NFSバージョン4でグローバルファイル名前空間を指定するためにDNS SRVを使用する方法について説明しています。このRFCの目的は、NFSクライアントが複数のサーバーに分散されたファイルシステムにアクセスするための標準化された方法を提供することです。
Internet Engineering Task Force (IETF) C. Everhart
Request for Comments: 6641 W. Adamson
Category: Standards Track NetApp
ISSN: 2070-1721 J. Zhang
Google
June 2012
Using DNS SRV to Specify a Global File Namespace with NFS Version 4
DNSバージョン4でDNS SRVを使用してグローバルファイル名前空間を指定する
Abstract
概要
The NFS version 4 (NFSv4) protocol provides a mechanism for a collection of NFS file servers to collaborate in providing an organization-wide file namespace. The DNS SRV Resource Record (RR) allows a simple way for an organization to publish the root of its file system namespace, even to clients that might not be intimately associated with such an organization. The DNS SRV RR can be used to join these organization-wide file namespaces together to allow construction of a global, uniform NFS file namespace.
NFSバージョン4（NFSv4）プロトコルは、NFSファイルサーバーのコレクションが協力して組織全体のファイル名前空間を提供するためのメカニズムを提供します。 DNS SRVリソースレコード（RR）を使用すると、組織がファイルシステムの名前空間のルートを、組織に密接に関連付けられていない可能性のあるクライアントに対しても簡単に公開できます。 DNS SRV RRを使用すると、これらの組織全体のファイル名前空間を結合して、グローバルで統一されたNFSファイル名前空間を構築できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6641.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6641で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していないIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Background ......................................................3
2. Requirements Notation ...........................................3
3. Use of the SRV Resource Record in DNS ...........................3
4. Integration with Use of NFS Version 4 ...........................5
4.1. Globally Useful Names: Conventional Mount Point ............5
4.2. Mount Options ..............................................6
4.3. File System Integration Issues .............................6
4.4. Multicast DNS ..............................................7
5. Where Is This Integration Carried Out? ..........................7
6. Security Considerations .........................................7
7. IANA Considerations .............................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
Version 4 of the NFS protocol [RFC3530] introduced the fs_locations attribute. Use of this attribute was elaborated further in the NFSv4 minor version 1 protocol [RFC5661], which also defined an extended version of the attribute as fs_locations_info. With the advent of these attributes, NFS servers can cooperate to build a file namespace that crosses server boundaries. The fs_locations and fs_locations_info attributes are used as referrals, so that a file server may indicate to its client that the file name tree beneath a given name in the server is not present on itself but is represented by a file system in some other set of servers. The mechanism is general, allowing servers to describe any file system as being reachable by requests to any of a set of servers. Thus, starting with a single NFSv4 server, using these referrals, an NFSv4 client could see a large namespace associated with a collection of interrelated NFSv4 file servers. An organization could use this capability to construct a uniform file namespace for itself.
NFSプロトコルのバージョン4 [RFC3530]では、fs_locations属性が導入されました。この属性の使用は、NFSv4マイナーバージョン1プロトコル[RFC5661]でさらに詳しく説明されており、これも属性の拡張バージョンをfs_locations_infoとして定義しました。これらの属性の出現により、NFSサーバーは連携して、サーバーの境界を越えるファイル名前空間を構築できます。 fs_locationsおよびfs_locations_info属性は参照として使用されるため、ファイルサーバーは、サーバー内の特定の名前の下にあるファイル名ツリーがそれ自体には存在しないが、他のサーバーセットのファイルシステムによって表されることをクライアントに示すことができます。 。このメカニズムは一般的であり、サーバーは任意のファイルシステムを、任意のサーバーセットへの要求によって到達可能であると記述できます。したがって、これらの参照を使用して単一のNFSv4サーバーから開始すると、NFSv4クライアントは、相互に関連するNFSv4ファイルサーバーのコレクションに関連付けられた大きな名前空間を見ることができます。組織はこの機能を使用して、独自のファイル名前空間を構築できます。
An organization might wish to publish the starting point for this namespace to its clients. In many cases, the organization will want to publish this starting point to a broader set of possible clients. At the same time, it is useful to require that clients know only the smallest amount of information in order to locate the appropriate namespace. Also, that required information should be constant through the life of an organization if the clients are not to require reconfiguration as administrative events change, for instance, a server's name or address.
組織は、この名前空間の開始点をクライアントに公開することができます。多くの場合、組織はこの開始点をより広範なクライアントセットに公開する必要があります。同時に、適切な名前空間を特定するために、クライアントに最小限の情報しか知らせないように要求すると便利です。また、サーバーの名前やアドレスなどの管理イベントの変更に応じてクライアントが再構成を必要としない場合、必要な情報は組織の存続期間を通じて一定でなければなりません。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Providing an organization's published file system namespace is a service, and the DNS [RFC1034][RFC1035] provides methods for discovery of that service. This standard defines a mapping from a DNS name to the NFS file system(s) providing the root of the file system namespace associated with that DNS name; such file systems are called "domain root" file systems. From such file systems, like other NFS file systems, an NFS client can use the standard NFS mechanisms to navigate the rest of the NFS file servers that make up the file system namespace for the given domain.
組織の公開されたファイルシステム名前空間を提供することはサービスであり、DNS [RFC1034] [RFC1035]はそのサービスを検出する方法を提供します。この標準は、DNS名からNFSファイルシステムへのマッピングを定義し、そのDNS名に関連付けられたファイルシステム名前空間のルートを提供します。このようなファイルシステムは「ドメインルート」ファイルシステムと呼ばれます。他のNFSファイルシステムと同様に、そのようなファイルシステムから、NFSクライアントは標準のNFSメカニズムを使用して、特定のドメインのファイルシステム名前空間を構成する残りのNFSファイルサーバーをナビゲートできます。
Such domain root file systems are mounted at a conventional point in the NFS client namespace. The mechanism results in a uniform cross-organizational file namespace, similar to that seen in both AFS [AFS][RFC5864] and Distributed Computing Environment / Distributed File System (DCE/DFS) [DFS]. An NFS client need know only the domain name for an organization in order to locate the file namespace published by that organization.
このようなドメインルートファイルシステムは、NFSクライアントの名前空間の従来の場所にマウントされます。このメカニズムにより、AFS [AFS] [RFC5864]と分散コンピューティング環境/分散ファイルシステム（DCE / DFS）[DFS]の両方で見られるのと同様の、組織をまたがるファイルの名前空間が統一されます。 NFSクライアントは、組織によって公開されたファイル名前空間を見つけるために、組織のドメイン名のみを知っている必要があります。
The DNS SRV RR type [RFC2782] is used to locate domain root file servers. The format of the DNS SRV record is as follows:
DNS SRV RRタイプ[RFC2782]は、ドメインルートファイルサーバーを見つけるために使用されます。 DNS SRVレコードの形式は次のとおりです。
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
The Service name used is "_nfs-domainroot", in conformance with RFC 6335 [RFC6335]. The Protocol name used is "_tcp", for NFS service over TCP. Future NFS services using other protocols MUST use another protocol name. The "_udp" label MUST NOT be used to imply use of UDP with NFSv4, as neither RFC 3530 [RFC3530] nor RFC 5661 [RFC5661] defines NFSv4 over UDP. The Target fields give the domain names of the NFS servers that export file systems for the domain's root. An NFS client may then interpret any of the exported root file systems as the root of the file system published by the organization with the given domain name.
使用されるサービス名は、RFC 6335 [RFC6335]に準拠した「_nfs-domainroot」です。使用されるプロトコル名は、TCPを介したNFSサービスの場合、「_ tcp」です。他のプロトコルを使用する将来のNFSサービスは、別のプロトコル名を使用する必要があります。 RFC 3530 [RFC3530]もRFC 5661 [RFC5661]もNFSv4 over UDPを定義していないため、「_ udp」ラベルはNFSv4でのUDPの使用を示唆するために使用してはなりません（MUST NOT）。 [ターゲット]フィールドには、ドメインのルートのファイルシステムをエクスポートするNFSサーバーのドメイン名が表示されます。次に、NFSクライアントは、エクスポートされたルートファイルシステムを、指定されたドメイン名で組織が公開したファイルシステムのルートとして解釈します。
The domain root service is not useful for NFS versions prior to version 4, as the fs_locations attribute was introduced only in NFSv4 (as described in Section 1).
ドメインルートサービスは、バージョン4より前のNFSバージョンには役立ちません。fs_locations属性はNFSv4でのみ導入されたためです（セクション1で説明）。
In order to allow the NFSv4 servers as given to export a variety of file systems, those file servers MUST export the given domain's root file systems at "/.domainroot/{Name}" within their pseudo-file systems, where the "{Name}" is the name of the organization as used in the SRV RR.
NFSv4サーバーがさまざまなファイルシステムをエクスポートできるようにするには、これらのファイルサーバーは、指定されたドメインのルートファイルシステムを、疑似ファイルシステム内の「/.domainroot/{Name}」にエクスポートする必要があります。 } "は、SRV RRで使用される組織の名前です。
As an example, suppose a client wished to locate the root of the file system published by organization example.net. The DNS servers for the domain would publish records like
例として、クライアントが組織example.netによって公開されたファイルシステムのルートを検索したいとします。ドメインのDNSサーバーは、次のようなレコードを公開します。
$ORIGIN example.net. _nfs-domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. _nfs-domainroot._tcp IN SRV 1 0 18204 nfs2ex.example.net.
$ ORIGIN example.net。 _nfs-domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net。 _nfs-domainroot._tcp IN SRV 1 0 18204 nfs2ex.example.net。
The resulting domain names nfs1tr.example.net and nfs2ex.example.net indicate NFSv4 file servers that export the root of the published namespace for the example.net domain. In accordance with RFC 2782 [RFC2782], these records are to be interpreted using the Priority and Weight field values, selecting an appropriate file server with which to begin a network conversation. The two file servers would export file systems that would be found at "/.domainroot/example.net" in their pseudo-file systems, which clients would mount. Clients then carry out subsequent accesses in accordance with the ordinary NFSv4 protocol. The first record uses the port number 2049 assigned to NFS, and another port is specified for the second record; the NFS servers would provide NFS service at their indicated port numbers, and NFS clients would connect to the service via the corresponding port numbers on those indicated servers.
結果のドメイン名nfs1tr.example.netおよびnfs2ex.example.netは、example.netドメインの公開された名前空間のルートをエクスポートするNFSv4ファイルサーバーを示します。 RFC 2782 [RFC2782]に従って、これらのレコードはPriorityおよびWeightフィールドの値を使用して解釈され、ネットワーク会話を開始する適切なファイルサーバーを選択します。 2つのファイルサーバーは、クライアントがマウントする疑似ファイルシステムの "/.domainroot/example.net"にあるファイルシステムをエクスポートします。その後、クライアントは通常のNFSv4プロトコルに従って後続のアクセスを実行します。最初のレコードはNFSに割り当てられたポート番号2049を使用し、別のポートが2番目のレコードに指定されています。 NFSサーバーは指定されたポート番号でNFSサービスを提供し、NFSクライアントは指定されたサーバーの対応するポート番号を介してサービスに接続します。
Other file system protocols could make use of the same domain root abstraction, but it is necessary to use different Service names not specified here.
他のファイルシステムプロトコルは同じドメインルート抽象化を利用できますが、ここで指定されていない別のサービス名を使用する必要があります。
NFSv4 clients adhering to this specification implement a special directory, analogous to an Automounter [AMD1][AMD2] directory, the entries in which are domain names that have recently been traversed. When an application attempts to traverse a new name in that special directory, the NFSv4 client consults DNS to obtain the SRV data for the given name, and if successful, it mounts the indicated file system(s) in that name in the special directory. The goal is that NFSv4 applications will be able to look up an organization's domain name in the special directory, and the NFSv4 client will be able to discover the file system that the organization publishes. Entries in the special directory will be domain names, and they will each appear to the application as a directory name pointing to the root directory of the file system published by the organization responsible for that domain name.
この仕様に準拠したNFSv4クライアントは、オートマウンタ[AMD1] [AMD2]ディレクトリに類似した特別なディレクトリを実装します。このエントリのエントリは、最近トラバースされたドメイン名です。アプリケーションがその特別なディレクトリ内の新しい名前をトラバースしようとすると、NFSv4クライアントはDNSに問い合わせて特定の名前のSRVデータを取得し、成功した場合は、指定されたファイルシステムをその名前の特別なディレクトリにマウントします。目標は、NFSv4アプリケーションが特別なディレクトリで組織のドメイン名を検索でき、NFSv4クライアントが組織が公開するファイルシステムを検出できるようにすることです。特別なディレクトリのエントリはドメイン名であり、それぞれのドメイン名を担当する組織によって公開されたファイルシステムのルートディレクトリを指すディレクトリ名としてアプリケーションに表示されます。
As noted in Section 3, the domain root service is not useful for NFS versions prior to version 4.
セクション3で述べたように、ドメインルートサービスは、バージョン4より前のNFSバージョンには役立ちません。
In order for the inter-organizational namespace to function as a global file namespace, the client-side mount point for that namespace must be the same on different clients. Conventionally, on Portable Operating System Interface (POSIX) machines, the name "/nfs4/" is used so that names on one machine will be directly usable on any machine. Thus, the example.net published file system would be accessible as
組織間名前空間がグローバルファイル名前空間として機能するためには、その名前空間のクライアント側のマウントポイントが、異なるクライアントで同じである必要があります。従来、ポータブルオペレーティングシステムインターフェース（POSIX）マシンでは、「/ nfs4 /」という名前が使用されているため、1台のマシンの名前はどのマシンでも直接使用できます。したがって、example.net公開ファイルシステムは次のようにアクセスできます。
/nfs4/example.net/
on any POSIX client. Using this convention, "/nfs4/" is the name of the special directory that is populated with domain names, leading to file servers and file systems that capture the results of SRV record lookups.
任意のPOSIXクライアント。この規則を使用すると、「/ nfs4 /」は、ドメイン名が入力された特別なディレクトリの名前であり、SRVレコードルックアップの結果をキャプチャするファイルサーバーとファイルシステムにつながります。
SRV records are necessarily less complete than the information in the existing NFSv4 attributes fs_locations [RFC3530] or fs_locations_info [RFC5661]. For the rootpath field of fs_location, or the fli_fs_root field of fs_locations_info, NFS servers MUST use the "/.domainroot/ {Name}" string. Thus, the servers listed as targets for the SRV RRs MUST export the root of the organization's published file system as the directory "/.domainroot/{Name}" (for the given organization Name) in their exported NFS namespaces. For example, for organization example.net, the directory "/.domainroot/example.net" would be used.
SRVレコードは、既存のNFSv4属性fs_locations [RFC3530]またはfs_locations_info [RFC5661]の情報よりも必ずしも完全ではありません。 fs_locationのrootpathフィールド、またはfs_locations_infoのfli_fs_rootフィールドの場合、NFSサーバーは「/.domainroot/ {Name}」文字列を使用する必要があります。したがって、SRV RRのターゲットとしてリストされているサーバーは、組織の公開されたファイルシステムのルートを、エクスポートされたNFS名前空間のディレクトリ「/.domainroot/{Name}」（特定の組織名用）としてエクスポートする必要があります。たとえば、組織example.netの場合、ディレクトリ「/.domainroot/example.net」が使用されます。
Section 11 of the NFSv4.1 document [RFC5661] describes the approach that an NFS client should take to navigate fs_locations_info information.
NFSv4.1ドキュメント[RFC5661]のセクション11では、fs_locations_info情報をナビゲートするためにNFSクライアントがとるべきアプローチについて説明しています。
The process of mounting an organization's namespace should permit the use of what is likely to impose the lowest cost on the server. Thus, the NFS client SHOULD NOT insist on using a writable copy of the file system if read-only copies exist, or a zero-age copy rather than a copy that may be a little older. The organization's file system representatives can be navigated to provide access to higher-cost properties such as writability or freshness as necessary, but the default use when navigating to the base information for an organization ought to be as low-overhead as possible.
組織の名前空間をマウントするプロセスでは、サーバーのコストが最も低くなる可能性があるものを使用できるようにする必要があります。したがって、NFSクライアントは、読み取り専用コピーが存在する場合、ファイルシステムの書き込み可能なコピー、または少し古い可能性のあるコピーではなくゼロエイジのコピーを使用するように主張すべきではありません（SHOULD NOT）。組織のファイルシステムの代表者をナビゲートして、必要に応じて書き込み可能性や鮮度などの高コストのプロパティにアクセスできますが、組織の基本情報に移動するときのデフォルトの使用は、可能な限りオーバーヘッドを低くする必要があります。
The result of the DNS search SHOULD appear as a (pseudo-)directory in the client namespace. A further refinement is RECOMMENDED: that only fully qualified domain names appear as directories. That is, in many environments, DNS names may be abbreviated from their fully qualified form. In such circumstances, multiple names might be given to NFS clients that all resolve to the same DNS SRV RRs. The abbreviated form SHOULD be represented in the client's namespace cache as a symbolic link, pointing to the fully qualified name. This will allow pathnames obtained with, say, getcwd() to include the DNS name that is most likely to be usable outside the scope of any particular DNS abbreviation convention.
DNS検索の結果は、クライアントの名前空間に（疑似）ディレクトリとして表示される必要があります（SHOULD）。さらに改良することをお勧めします。つまり、完全修飾ドメイン名のみがディレクトリとして表示されます。つまり、多くの環境では、DNS名は完全修飾形式から省略される場合があります。このような状況では、すべて同じDNS SRV RRに解決される複数の名前がNFSクライアントに与えられる場合があります。省略形は、完全修飾名を指すシンボリックリンクとしてクライアントのネームスペースキャッシュで表す必要があります（SHOULD）。これにより、たとえばgetcwd()で取得したパス名に、特定のDNS省略表記の範囲外で使用できる可能性が最も高いDNS名を含めることができます。
Location of the NFS domain root by this SRV record is intended to be performed with unicast by using the ordinary DNS [RFC1034][RFC1035] protocol.
このSRVレコードによるNFSドメインルートの場所は、通常のDNS [RFC1034] [RFC1035]プロトコルを使用してユニキャストで実行されることを目的としています。
This document does not define the use of this DNS SRV record format in conjunction with Multicast DNS (mDNS). While mDNS could be used to locate a local domain root via these SRV records, no other domain's root could be discovered. This means that mDNS has too little value to use in locating NFSv4 domain roots.
このドキュメントでは、このDNS SRVレコード形式をマルチキャストDNS（mDNS）と組み合わせて使用することを定義していません。 mDNSを使用してこれらのSRVレコードを介してローカルドメインのルートを見つけることはできますが、他のドメインのルートは検出できませんでした。これは、mDNSの値がNFSv4ドメインルートの検索に使用するには小さすぎることを意味します。
The NFS client is responsible for interpreting SRV records. Using something like Automounter [AMD1] [AMD2] technology, the client interprets names under a particular directory, by first discovering the appropriate file system to mount and then mounting it in the specified place in the client namespace before returning control to the application doing a lookup. The result of the DNS lookup should be cached (obeying Time to Live (TTL)) so that the result could be returned more quickly the next time.
NFSクライアントはSRVレコードの解釈を担当します。 Automounter [AMD1] [AMD2]テクノロジーのようなものを使用して、クライアントは特定のディレクトリの下の名前を解釈します。まず、マウントする適切なファイルシステムを検出し、それをクライアントのネームスペースの指定された場所にマウントしてから、アプリケーションに制御を戻します。調べる。 DNSルックアップの結果はキャッシュされ（Time to Live（TTL）に従って）、結果が次回により速く返されるようにする必要があります。
This functionality introduces a new reliance of NFSv4 on the integrity of DNS. Forged SRV records in DNS could cause the NFSv4 client to connect to the file servers of an attacker, rather than the legitimate file servers of an organization. This is similar to attacks that can be made on the base NFSv4 protocol, if server names are given in fs_location attributes: the client can be made to connect to the file servers of an attacker, not the file servers intended to be the target for the fs_location attributes.
この機能により、NFSv4がDNSの整合性に新たに依存するようになります。 DNSの偽造SRVレコードにより、NFSv4クライアントが組織の正規のファイルサーバーではなく、攻撃者のファイルサーバーに接続する可能性があります。これは、サーバー名がfs_location属性で指定されている場合、ベースNFSv4プロトコルで実行できる攻撃に似ています。クライアントは、攻撃対象のファイルサーバーではなく、攻撃者のファイルサーバーに接続するように作成できます。 fs_location属性。
If DNS Security Extensions (DNSSEC) [RFC4033] is available, it SHOULD be used to avoid both such attacks. Domain-based service principal names are an additional mechanism that also apply in this case, and it would be prudent to use them. They provide a mapping from the domain name that the user specified to names of security principals used on the NFSv4 servers that are indicated as the targets in the SRV records (as providing file service for the root file systems).
DNS Security Extensions（DNSSEC）[RFC4033]が利用可能な場合は、そのような攻撃を回避するために使用する必要があります（SHOULD）。ドメインベースのサービスプリンシパル名は、この場合にも適用される追加のメカニズムであり、それらを使用するのが賢明です。これらは、ユーザーが指定したドメイン名から、SRVレコードでターゲットとして示されているNFSv4サーバーで使用されるセキュリティプリンシパルの名前へのマッピングを提供します（ルートファイルシステムのファイルサービスの提供として）。
With domain-based service principal names, the idea is that one wants to authenticate {nfs, domainname, host.fqdn}, not simply {nfs, host.fqdn}, when the server is a domain's root file server obtained through a DNS SRV RR lookup that may or may not have been secure.
ドメインベースのサービスプリンシパル名の場合、サーバーがDNS SRVを通じて取得されたドメインのルートファイルサーバーである場合、単に{nfs、host.fqdn}ではなく{nfs、domainname、host.fqdn}を認証したいという考えです。安全である場合とそうでない場合があるRRルックアップ。
The domain administrator can thus ensure that only domain root NFSv4 servers have credentials for such domain-based service principal names.
したがって、ドメイン管理者は、ドメインルートのNFSv4サーバーのみが、このようなドメインベースのサービスプリンシパル名の資格情報を持っていることを確認できます。
Domain-based service principal names are defined in RFCs 5178 [RFC5178] and 5179 [RFC5179]. To make use of RFC 5178's domain-based names, the syntax for "domain-based-name" MUST be used with a service of "nfs", a domain matching the name of the organization whose root file system is being sought, and a hostname given in the target of the DNS SRV RR. Thus, in the example above, two file servers (nfs1tr.example.net and nfs2ex.example.net) are located as hosting the root file system for the organization example.net. To communicate with, for instance, the second of the given file servers, Generic Security Service Application Program Interface (GSS-API) is used with the name-type of GSS_C_NT_DOMAINBASED_SERVICE defined in RFC 5178 and with a symbolic name of
ドメインベースのサービスプリンシパル名は、RFC 5178 [RFC5178]および5179 [RFC5179]で定義されています。 RFC 5178のドメインベースの名前を利用するには、「domain-based-name」の構文を「nfs」のサービス、ルートファイルシステムを探している組織の名前と一致するドメイン、およびDNS SRV RRのターゲットで指定されたホスト名。したがって、上記の例では、2つのファイルサーバー（nfs1tr.example.netとnfs2ex.example.net）が組織example.netのルートファイルシステムをホストするものとして配置されています。たとえば、特定のファイルサーバーの2番目と通信するために、Generic Security Service Application Program Interface（GSS-API）が、RFC 5178で定義されているGSS_C_NT_DOMAINBASED_SERVICEの名前タイプと、
nfs@example.net@nfs2ex.example.net
nfs @ example.net @ nfs2ex.example.net
in order to verify that the named server (nfs2ex.example.net) is authorized to provide the root file system for the example.net organization.
名前付きサーバー（nfs2ex.example.net）が、example.net組織にルートファイルシステムを提供する権限があることを確認するため。
NFSv4 itself contains a facility for the negotiation of security mechanisms to be used between NFS clients and NFS servers. Section 3.3 of RFC 3530 [RFC3530] and Section 2.6 of RFC 5661 [RFC5661] both describe how security mechanisms are to be negotiated. As such, there is no need for this document to describe how that negotiation is to be carried out when the NFS client contacts the NFS server for the specified domain root file system(s).
NFSv4自体には、NFSクライアントとNFSサーバー間で使用されるセキュリティメカニズムのネゴシエーションのための機能が含まれています。 RFC 3530 [RFC3530]のセクション3.3とRFC 5661 [RFC5661]のセクション2.6の両方で、セキュリティメカニズムのネゴシエート方法について説明しています。そのため、このドキュメントでは、NFSクライアントが指定されたドメインルートファイルシステムのNFSサーバーに接続するときに、そのネゴシエーションがどのように実行されるかを説明する必要はありません。
Using SRV records to advertise the locations of NFS servers may expose those NFS servers to attacks. Organizations should carefully consider whether they wish their DNS servers to respond differentially to different DNS clients, perhaps exposing their SRV records to only those DNS requests that originate within a given perimeter, in order to reduce this exposure.
SRVレコードを使用してNFSサーバーの場所をアドバタイズすると、それらのNFSサーバーが攻撃にさらされる可能性があります。この露出を減らすために、組織はDNSサーバーがさまざまなDNSクライアントに異なる応答をすることを望み、SRVレコードを特定の境界内で発生するDNS要求のみに公開することを希望するかどうかを慎重に検討する必要があります。
IANA has assigned a new Service name without an associated port number (as defined in RFC 6335 [RFC6335]) for TCP. For this new Service, the Reference is this document.
IANAは、TCPに関連するポート番号（RFC 6335 [RFC6335]で定義されている）なしで新しいサービス名を割り当てました。この新しいサービスのリファレンスはこのドキュメントです。
Service name: nfs-domainroot Transport Protocol(s) TCP Assignee (REQUIRED) IESG (iesg@ietf.org) Contact (REQUIRED) IETF Chair (chair@ietf.org) Description (REQUIRED) NFS service for the domain root, the root of an organization's published file namespace. Reference (REQUIRED) This document Port Number (OPTIONAL) Service Code (REQUIRED for DCCP only) Known Unauthorized Uses (OPTIONAL) Assignment Notes (OPTIONAL)
サービス名：nfs-domainrootトランスポートプロトコルTCP割り当て先（必須）IESG（iesg@ietf.org）連絡先（必須）IETF議長（chair@ietf.org）説明（必須）ドメインルート、ルートのNFSサービス組織の公開されたファイル名前空間の。参照（必須）このドキュメントポート番号（オプション）サービスコード（DCCPの場合のみ必須）既知の不正使用（オプション）割り当てに関する注意（オプション）
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[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月。
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530] Shepler、S.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、M。、およびD. Noveck、「Network File System（NFS）version 4 Protocol」、 RFC 3530、2003年4月。
[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月。
[RFC5178] Williams, N. and A. Melnikov, "Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type", RFC 5178, May 2008.
[RFC5178]ウィリアムズN.およびA.メルニコフ、「Generic Security Service Application Program Interface（GSS-API）Internationalization and Domain-Based Service Names and Name Type」、RFC 5178、2008年5月。
[RFC5179] Williams, N., "Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism", RFC 5179, May 2008.
[RFC5179]ウィリアムズN。、「Kerberos V GSSメカニズム用の汎用セキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）ドメインベースのサービス名マッピング」、RFC 5179、2008年5月。
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010.
[RFC5661] Shepler、S.、Ed。、Eisler、M.、Ed。、and D. Noveck、Ed。、 "Network File System（NFS）Version 4 Minor Version 1 Protocol"、RFC 5661、January 2010。
[RFC5864] Allbery, R., "DNS SRV Resource Records for AFS", RFC 5864, April 2010.
[RFC5864] Allbery、R。、「AFSのDNS SRVリソースレコード」、RFC 5864、2010年4月。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、2011年8月。
[AFS] Howard, J., "An Overview of the Andrew File System", Proc. USENIX Winter Tech. Conf. Dallas, February 1988.
[AFS]ハワード、J。、「アンドリューファイルシステムの概要」、Proc。 USENIX Winter Tech。会議ダラス、1988年2月。
[AMD1] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter Reference Manual", March 1991, <http://docs.freebsd.org/info/amdref/amdref.pdf>.
[AMD1] Pendry、J。およびN. Williams、「Amd：The 4.4 BSD Automounter Reference Manual」、1991年3月、<http://docs.freebsd.org/info/amdref/amdref.pdf>。
[AMD2] Crosby, M., "AMD--AutoMount Daemon", Linux Journal, 35es Article 4, March 1997.
[AMD2]クロスビー、M。、「AMD--AutoMount Daemon」、Linux Journal、35es Article 4、1997年3月。
[DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V., Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S., and E. Zayas, "DEcorum File System Architectural Overview", Proc. USENIX Summer Conf. Anaheim, Calif., June 1990.
[DFS] Kazar、M.、Leverett、B.、Anderson、O.、Apostolides、V.、Bottos、B.、Chutani、S.、Everhart、C.、Mason、W.、Tu、S.、E 。Zayas、「DEcorum File System Architectural Overview」、Proc。 USENIX Summer Conf。カリフォルニア州アナハイム、1990年6月。
Authors' Addresses
著者のアドレス
Craig Everhart NetApp 800 Cranberry Woods Drive, Ste. 300 Cranberry Township, PA 16066 USA
Craig Everhart NetApp 800 Cranberry Woods Drive、Ste。 300 Cranberry Township、PA 16066 USA
Phone: +1 724 741 5101
EMail: everhart@netapp.com
W.A. (Andy) Adamson NetApp 495 East Java Drive Sunnyvale, CA 94089 USA
W.A.（Andy）Adamson NetApp 495 East Java Drive Sunnyvale、CA 94089 USA
Phone: +1 734 665 1204
EMail: andros@netapp.com
Jiaying Zhang Google 604 Arizona Avenue Santa Monica, CA 90401 USA
J IAはGoogle 604アリゾナアベニューサンタモニカ、カリフォルニア州90401アメリカを張るべき
Phone: +1 310 309 6884
EMail: jiayingz@google.com