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
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 SRV指定NFS版本4的全局文件命名空间
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.
这是一份互联网标准跟踪文件。
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/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.
版权所有（c）2012 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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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协议[RFC3530]的第4版引入了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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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
_服务._Proto.Name TTL Class SRV优先级权重端口目标
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.
使用的服务名称为“_nfs-domainroot”，符合RFC 6335[RFC6335]。对于tcp上的NFS服务，使用的协议名称为“tcp”。使用其他协议的未来NFS服务必须使用其他协议名称。由于RFC 3530[RFC3530]和RFC 5661[RFC5661]均未定义udp上的NFSv4，因此“_udp”标签不得用于暗示将udp与NFSv4一起使用。目标字段提供为域的根导出文件系统的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}”处导出给定域的根文件系统，“{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
例如，假设一个客户端希望找到organization 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.\u SRV 0 0 2049 nfs1tr.example.net中的tcp_nfs domainroot.\u SRV 1 0 18204 nfs2ex.example.net中的tcp。
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]，这些记录将使用优先级和权重字段值进行解释，选择适当的文件服务器开始网络对话。这两个文件服务器将导出可在其伪文件系统中的“/.domainroot/example.net”中找到的文件系统，客户端将挂载这些文件系统。然后，客户机根据普通NFSv4协议执行后续访问。第一条记录使用分配给NFS的端口号2049，并为第二条记录指定另一个端口；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客户端实现一个特殊目录，类似于Automounter[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/”，以便一台机器上的名称可以直接用于任何机器。因此，示例.net发布的文件系统可以作为
/nfs4/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 RRs目标的服务器必须在其导出的NFS命名空间中将组织发布的文件系统的根导出为目录“/.domainroot/{Name}”（对于给定的组织名称）。例如，对于organization 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节描述了NFS客户端导航fs\u位置\u信息所应采取的方法。
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客户端不应该坚持使用文件系统的可写副本，或者使用零期副本而不是可能稍旧的副本。可以根据需要导航组织的文件系统代表以提供对较高成本属性（如可写性或新鲜度）的访问，但导航到组织的基本信息时的默认使用应该尽可能低的开销。
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搜索的结果应显示为客户端命名空间中的（伪）目录。建议进一步改进：只有完全限定的域名显示为目录。也就是说，在许多环境中，DNS名称可以从其完全限定形式缩写。在这种情况下，可能会为所有解析为相同DNS SRV RRs的NFS客户端指定多个名称。缩写形式应在客户端的命名空间缓存中表示为符号链接，指向完全限定名称。这将允许使用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（MDN）的结合使用。虽然MDN可用于通过这些SRV记录定位本地域根，但找不到其他域的根。这意味着MDN在定位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查找的结果（遵守生存时间（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_位置属性中给出了服务器名称，则这类似于可以对基本NFSv4协议进行的攻击：可以使客户端连接到攻击者的文件服务器，而不是打算作为fs_位置属性目标的文件服务器。
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安全扩展（DNSSEC）[RFC4033]可用，则应使用它来避免这两种攻击。基于域的服务主体名称是在这种情况下也适用的一种附加机制，使用它们是谨慎的。它们提供了从用户指定的域名到NFSv4服务器上使用的安全主体名称的映射，这些安全主体在SRV记录中被指示为目标（为根文件系统提供文件服务）。
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 RR查找获得的域根文件服务器时，需要验证{nfs，domainname，host.fqdn}，而不仅仅是{nfs，host.fqdn}，这可能是安全的，也可能不是安全的。
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
基于域的服务主体名称在RFCs 5178[RFC5178]和5179[RFC5179]中定义。要使用RFC 5178的基于域的名称，“基于域的名称”的语法必须与“nfs”服务一起使用，该服务是一个与正在查找其根文件系统的组织的名称相匹配的域，以及DNS SRV RR目标中给定的主机名。因此，在上面的示例中，两个文件服务器（nfs1tr.example.net和nfs2ex.example.net）被定位为组织example.net的根文件系统的宿主。例如，为了与第二个给定文件服务器通信，通用安全服务应用程序接口（GSS-API）使用RFC 5178中定义的GSS_C_NT_DOMAINBASED_服务的名称类型和符号名称
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域根传输协议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 SRV）的DNS RR”，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，“网络文件系统（NFS）版本4协议”，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]Williams，N.和A.Melnikov，“通用安全服务应用程序接口（GSS-API）国际化和基于域的服务名称和名称类型”，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]Williams，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.，和D.Noveck，Ed.，“网络文件系统（NFS）版本4次要版本1协议”，RFC 56612010年1月。
[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]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 63352011年8月。
[AFS] Howard, J., "An Overview of the Andrew File System", Proc. USENIX Winter Tech. Conf. Dallas, February 1988.
[AFS]Howard，J.，“Andrew文件系统概述”，Proc。USENIX Winter Tech.Conf.达拉斯，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:4.4 BSD自动贴片机参考手册”，1991年3月<http://docs.freebsd.org/info/amdref/amdref.pdf>.
[AMD2] Crosby, M., "AMD--AutoMount Daemon", Linux Journal, 35es Article 4, March 1997.
[AMD2]Crosby，M.，“AMD——自动挂载守护进程”，Linux杂志，35es文章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，“礼仪文件系统架构概述”，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，圣彼得堡。美国宾夕法尼亚州蔓越莓镇300号，邮编16066
Phone: +1 724 741 5101
EMail: everhart@netapp.com
Phone: +1 724 741 5101
EMail: everhart@netapp.com
W.A. (Andy) Adamson NetApp 495 East Java Drive Sunnyvale, CA 94089 USA
W.A.（安迪）美国加利福尼亚州桑尼维尔市东爪哇大道495号亚当森NetApp 94089
Phone: +1 734 665 1204
EMail: andros@netapp.com
Phone: +1 734 665 1204
EMail: andros@netapp.com
Jiaying Zhang Google 604 Arizona Avenue Santa Monica, CA 90401 USA
美国加利福尼亚州圣莫尼卡市亚利桑那大道604号，邮编90401
Phone: +1 310 309 6884
EMail: jiayingz@google.com
Phone: +1 310 309 6884
EMail: jiayingz@google.com