--- 1/draft-ietf-nfsv4-federated-fs-dns-srv-namespace-04.txt 2010-08-26 21:12:34.000000000 +0200 +++ 2/draft-ietf-nfsv4-federated-fs-dns-srv-namespace-05.txt 2010-08-26 21:12:34.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group C. Everhart Internet-Draft W. Adamson Intended status: Standards Track NetApp -Expires: November 26, 2010 J. Zhang +Expires: February 27, 2011 J. Zhang Google - May 25, 2010 + August 26, 2010 Using DNS SRV to Specify a Global File Name Space with NFS version 4 - draft-ietf-nfsv4-federated-fs-dns-srv-namespace-04.txt + draft-ietf-nfsv4-federated-fs-dns-srv-namespace-05.txt Abstract The NFS version 4 protocol provides a natural way for a collection of NFS file servers to collaborate in providing an organization-wide file name space. The DNS SRV RR allows a simple and appropriate way for an organization to publish the root of its name space, 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 name spaces together to allow construction of a global, @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 26, 2010. + This Internet-Draft will expire on February 27, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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 @@ -67,51 +67,51 @@ Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Proposed Use of SRV Resource Record in DNS . . . . . . . . . . 4 4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 6 4.1. Globally-useful names: conventional mount point . . . . . 6 4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Filesystem integration issues . . . . . . . . . . . . . . 8 5. Where is this integration carried out? . . . . . . . . . . . . 8 - 6. Relationship to DNS NFS4ID RR . . . . . . . . . . . . . . . . 9 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Requirements notation 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]. 2. Background - With the advent of fs_locations attributes in the NFS Version 4 - protocol [RFC3530], NFS servers can cooperate to build a file name - space that crosses server boundaries, as detailed in the description - of referrals in [NB0510] and as further developed in the NFS Version - 4 Minor Version 1 protocol [RFC5661]. With NFS Version 4 referrals, - 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 filesystem in some other set of servers. The - mechanism is general, allowing servers to describe any filesystem as - being reachable by requests to any of a set of servers. Thus, - starting with a single NFS Version 4 server, using these referrals, - an NFS Version 4 client might be able to see a large name space - associated with a collection of interrelated NFS Version 4 file - servers. An organization could use this capability to construct a - uniform file name space for itself. + The NFS Version 4 protocol [RFC3530] introduced the fs_locations + attribute. Its use was elaborated further in the NFS Version 4 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 name space 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 filesystem + in some other set of servers. The mechanism is general, allowing + servers to describe any filesystem as being reachable by requests to + any of a set of servers. Thus, starting with a single NFS Version 4 + server, using these referrals, an NFS Version 4 client might be able + to see a large name space associated with a collection of + interrelated NFS Version 4 file servers. An organization could use + this capability to construct a uniform file name space for itself. An organization might wish to publish the starting point for this name space 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 clients to know only the smallest amount of information in order to locate the appropriate name space. Simultaneously, 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. @@ -133,29 +132,25 @@ organization in order to locate the filesystem name space published by that organization. We propose the use of the DNS SRV resource record type [RFC2782] to fulfill this function. The format of the DNS SRV record is as follows: _Service._Proto.Name TTL Class SRV Priority Weight Port Target In our case, we use a Service name of "_nfs4._domainroot" and a - conventional Protocol of "_tcp". (In accordance with RFC 2782 - [RFC2782], we use "_" prefix characters on the Service and Protocol - names, but we recognize that there is work in progress [Gudmundsson] - to create a registry of these names and to no longer use the "_" - prefix for some names.) The Target fields give the domain names of - the NFS Version 4 servers that export filesystems for the domain's - root. An NFS Version 4 client SHOULD interpret any of the exported - root filesystems as the filesystem published by the organization with - the given domain name. + conventional Protocol of "_tcp". The Target fields give the domain + names of the NFS Version 4 servers that export filesystems for the + domain's root. An NFS Version 4 client SHOULD interpret any of the + exported root filesystems as the filesystem published by the + organization with the given domain name. In order to allow the NFSv4 servers so given to export a variety of filesystems, those file servers SHOULD export the given domain's root filesystems at "/.domainroot-{Name}" within their pseudo-filesystems, where the "{Name}" is the name of the organization as used in the SRV RR. As an example, suppose a client wished to locate the root of the filesystem published by organization example.net. The DNS servers for the domain could publish records like @@ -333,35 +328,21 @@ their SRV lookups for them, we feel that such a requirement would impose unusual dependencies and vulnerabilities for the deployers of such clients. Yet even if it is desirable to deploy this functionality on the NFS client side, it may be valuable as a transition aid for a site to be able to deploy it on the NFS server side: it may be easier for them to install it on special NFS servers rather than install it on all their NFS clients. Thus, from an implementation standpoint, NFS clients SHOULD implement the functionality, and NFS servers MAY implement it. -6. Relationship to DNS NFS4ID RR - - This DNS use has no obvious relationship to the NFS4ID RR [Mesta]. - The NFS4ID RR is a mechanism to help clients and servers configure - themselves with respect to the domain strings used in "who" strings - in ACL entries and in owner and group names. The authentication/ - authorization domain string of a server need have no direct - relationship to the name of the organization that is publishing a - file name space of which this server's filesystems form a part. At - the same time, it might be seen as straightforward or normal for such - a server to refer to the ownership of most of its files using a - domain string with an evident relationship to that NFS4ID-given - domain name, but this document imposes no such requirement. - -7. Security Considerations +6. Security Considerations Naive use of the DNS may effectively give clients published server referrals that are intrusive substitutes for the servers intended by domain administrators. It may be possible to build a trust chain by using DNSSEC [RFC4033] to implement this function on the client, or by implementing this function on an NFS Version 4 server that uses DNSSEC and maintaining a trust relationship with that server. This trust chain also breaks if the SRV interpreter accepts responses from insecure DNS zones. @@ -387,29 +367,27 @@ GSS-API should be used with the name-type of GSS_C_NT_DOMAINBASED_SERVICE defined in RFC 5178 and with a symbolic name of nfs@example.net@nfs2ex.example.net in order to verify that the named server (nfs2ex.example.net) is authorized to provide the root filesystem for the example.net organization. -8. IANA Considerations +7. IANA Considerations - This document does not raise actions for IANA, but it may require - cosmetic changes if the in-progress work in the Gudmundsson/Hoenes - draft [Gudmundsson] is adopted. + None. -9. References +8. References -9.1. Normative References +8.1. Normative References [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. @@ -432,48 +410,35 @@ [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. [RFC5661] Shepler, S., Eisler, M., and D. Noveck, Editors, "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010. -9.2. Informative References +8.2. Informative References [AFS] Howard, J., "An Overview of the Andrew File System"", Proc. USENIX Winter Tech. Conf. Dallas, February 1988. [AMD] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter Reference Manual", March 1991, . [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. - [Gudmundsson] - Gudmundsson, O. and A. Hoenes, "Creation of a Registry for - DNS SRV Record Service Prefixes", October 2009, . - - [Mesta] Mesta, R., "A DNS RR for NFSv4 ID Domains", October 2005, - . - - [NB0510] Noveck, D. and R. Burnett, "Next Steps for NFSv4 - Migration/Replication", October 2005, . - [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. Authors' Addresses Craig Everhart NetApp 800 Cranberry Woods Drive, Ste. 300 Cranberry Township, PA 16066