--- 1/draft-ietf-nfsv4-federated-fs-dns-srv-namespace-01.txt 2009-10-26 22:12:14.000000000 +0100 +++ 2/draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02.txt 2009-10-26 22:12:14.000000000 +0100 @@ -1,20 +1,20 @@ Network Working Group C. Everhart Internet-Draft W. Adamson Intended status: Standards Track NetApp -Expires: November 16, 2009 J. Zhang +Expires: April 29, 2010 J. Zhang Google - May 15, 2009 + October 26, 2009 Using DNS SRV to Specify a Global File Name Space with NFS version 4 - draft-ietf-nfsv4-federated-fs-dns-srv-namespace-01.txt + draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -23,21 +23,21 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on November 16, 2009. + This Internet-Draft will expire on April 29, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -52,55 +52,54 @@ 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, uniform NFS version 4 file name space. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Proposed Use of SRV Resource Record in DNS . . . . . . . . . . 3 - 3.1. Deployment of the Resource Record . . . . . . . . . . . . 4 - 4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 5 + 4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 4 4.1. Globally-useful names: conventional mount point . . . . . 5 4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 5 - 4.3. File system integration issues . . . . . . . . . . . . . . 6 + 4.3. Filesystem integration issues . . . . . . . . . . . . . . 7 5. Where is this integration carried out? . . . . . . . . . . . . 7 - 6. Relationship to DNS NFS4ID RR . . . . . . . . . . . . . . . . 7 + 6. Relationship to DNS NFS4ID RR . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 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]. With NFS Version 4 referrals, a file - server may indicate to its client that the file system 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. + 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. @@ -120,155 +119,182 @@ [DFS] before it. A client need know only the name of the organization in order to locate the file system 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" and a conventional - Protocol of "_tcp". The Target fields give the domain names of the - NFS Version 4 servers that export root filesystems. An NFS Version 4 - client SHOULD interpret any of the exported pseudo-root filesystems - as the filesystem published by the organization with the given domain - name. + 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. - Suppose a client wished to locate the root of the file system - published by organization example.net. The DNS servers for the - domain could publish records like + 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 "/.domain-root-{Name}" within their pseudo- + filesystems, where the "{Name}" is the name of the organization as + used in the SRV RR. - _nfs4._tcp IN SRV 0 0 2049 nfs1tr.example.net - _nfs4._tcp IN SRV 1 0 2049 nfs2ex.example.net + 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 + + _nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net + _nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net The result domain names nfs1tr.example.net and nfs2ex.example.net indicate NFS Version 4 file servers that export the root of the published name space for the example.net domain. In accordance with - RFC 2782, 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. Subsequent accesses are carried out - in accordance with ordinary NFS Version 4 protocol. - -3.1. Deployment of the Resource Record - - As with any DNS resource, any server installation needs to concern - itself with the likely loads and effects of the presence of the - resource record. The answers to requests for RRs might differ - depending on what the server can tell about the client. For example, - some RRs might be returned only to those clients inside some network - perimeter (to provide an intranet service) and requests from other - clients might be denied. As the RR directs the clients to ask for - service from a given set of servers, the administrator should ensure - that the identified servers can handle the expected load. - Fortunately, the definition of the DNS SRV resource record offers a - mechanism to distribute the load to multiple servers within a - priority ordering. + 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 filesystems that would be found at "/.domain- + root-example.net" in their pseudo-filesystems, which clients would + mount. Clients then carry out subsequent accesses in accordance with + the ordinary NFS Version 4 protocol. 4. Integration with Use of NFS Version 4 - There are at least two remaining questions: whether this DNS SRV - record evaluation is done in the NFS server or client, and also how - the domain names of the organizations are passed to client or server. - A third question is how this might produce a uniform global file name - space, and what prefix should be used for such file names. + We expect that NFSv4 clients will implement a special directory, + analogous to an Automounter [AMD] 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 filesystem(s) in that name in the + special directory. The goal is that NFSv4 applications will be able + to lookup an organization's domain name in the special directory, and + the NFSv4 client will be able to discover the filesystem that that + 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 filesystem + published by the organization responsible for that domain name. - This specification anticipates that these SRV records will most - commonly be used to define the second directory level in an inter- - organizational file name space. This directory will be populated - with domain names pointing to the file systems published for use - under those domain names. Thus, the root directory for the file - system published by example.net will effectively be mounted - underneath the example.net name in a second-level directory. + This functionality does not require or use any list of organizations + that are known to provide file service, as AFS did with its + "root.afs" functionality. - In general, a domain name will appear to a client as a directory name - pointing to the root directory of the file system published by the - organization responsible for that domain name. + This DNS SRV record evaluation could, in principle, be done either in + the NFSv4 client or in an NFSv4 server. In either case, the result + would appear the same to applications on the NFSv4 client. 4.1. Globally-useful names: conventional mount point For the inter-organizational name space to be a global name space, it is useful for its mount point in local systems to be uniform as well. - The name /nfs4/ SHOULD be 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 + On POSIX machines, the name /nfs4/ SHOULD be used so that names on + one machine will be directly usable on any machine. Thus, the + example.net published filesystem would be accessible as /nfs4/example.net/ - on any client. Using this convention, "/nfs4/" is a mount for a - special file system that is populated with the results of SRV record + 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 filesystems that capture the results of SRV record lookups. 4.2. Mount options SRV records are necessarily less complete than the information in the existing NFS Version 4 attributes fs_locations and the proposed - fs_locations_info. For the rootpath field of fs_location, we assume - that the empty string is adequate. Thus, the servers listed as - targets for the SRV resource records should export the root of the - organization's published file system as the pseudo-root in its - exported namespace. + fs_locations_info. For the rootpath field of fs_location, as + mentioned, we use the "/.domain-root-{Name}" string. Thus, the + servers listed as targets for the SRV resource records should export + the root of the organization's published filesystem as the directory + "/.domain-root-{Name}" (for the given organization Name) in its + exported namespace. For example, for organization "example.net", the + directory "/.domain-root-example.net" should be used. As for the other attributes in fs_locations_info, the recommended approach is for a client to make its first possible contact with any of the referred-to servers, obtain the fs_locations_info structure from that server, and use the information from that obtained structure as the basis for its judgment of whether it would be better to use a different server representative from the set of servers for that filesystem. - We recommend, though, that the process of mounting an organization's - name space should permit the use of what is likely to impose the - lowest cost on the server. Thus, we recommend that the client not - insist on using a writable copy of the filesystem if read-only copies - exist, or a zero-age copy rather than a copy that may be a little - older. We presume that the organization's file name space can be - navigated to provide access to higher-cost properties such as - writability or currency as necessary, but that the default use when - navigating to the base information for an organization ought to be as - low-overhead as possible. + The process of mounting an organization's name space 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 filesystem if read-only copies exist, or a zero-age copy rather + than a copy that may be a little older. We presume that the + organization's file name space can be navigated to provide access to + higher-cost properties such as writability or currency as necessary, + but that the default use when navigating to the base information for + an organization ought to be as low-overhead as possible. - One extension of this rule that we might choose to inherit from AFS, - though, is to give a special meaning to the domain name of an - organization preceded by a period ("."). It might be reasonable to - have names mounting the filesystem for a period-prefixed domain name - (e.g., ".example.net") attempt to mount only a read-write instance of - that organization's root filesystem, rather than permitting the use - of read-only instances of that filesystem. Thus, + Because of the possible distinction between read-only and read-write + versions of a filesystem, organizations SHOULD also publish the + location of a writable instance of their root filesystems, and that + NFSv4 clients SHOULD mount that filesystem under the organizational + domain name preceded by a period ("."). Therefore, when names + beginning with a period are looked up under the NFSv4 client's + special directory, the SRV RR looked up in DNS uses a Service name of + "_nfs4._write._domainroot", and the indicated server (or servers) + SHOULD export the writable instance at "/.domain-root-write-{Name}" + for a domain name Name. + + Extending the opening example, suppose a client wished to locate the + read-only and read-write roots of the filesystem published by + organization example.net. Suppose a read-write instance were hosted + on server nfs1tr.example.net, and read-only instances were on that + server and also on server nfs2ex.example.net. The DNS servers for + the domain would publish records like + + _nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net + _nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net + _nfs4._write._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net + + The nfs1tr.example.net server would export filesystems at both + "/.domain-root-example.net" (the read-only instance) and "/.domain- + root-write-example.net" (the read-write instance). The + nfs2ex.example.net server need export only the "/.domain-root- + example.net" name for its read-only instance. + + The read-write version of the filesystem would be mounted (upon use) + under ".example.net" in the special directory, and a read-only + version would be mounted under "example.net". Thus, /nfs4/example.net/users might be a directory in a read-only instance of the root filesystem of the organization "example.net", while /nfs4/.example.net/users would be a writable form of that same directory. A small benefit of following this convention is that names with the period prefix are treated as "hidden" in many operating systems, so that the visible name remains the lowest-overhead name. 4.3. File system integration issues The result of the DNS search SHOULD appear as a (pseudo-)directory in - the client name space, cached for a time no longer than the RR's TTL. - A further refinement is advisable, and SHOULD be deployed: 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 file - system code that all resolve to the same DNS SRV RRs. The - abbreviated form SHOULD be represented in the client's name space - cache as a symbolic link, pointing to the fully-qualified name, case- - canonicalized when appropriate. 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. + the client name space. A further refinement is advisable, and SHOULD + be deployed: 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 filesystem code that all resolve to + the same DNS SRV RRs. The abbreviated form SHOULD be represented in + the client's name space cache as a symbolic link, pointing to the + fully-qualified name, case-canonicalized when appropriate. 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. 5. Where is this integration carried out? Another consideration is what agent should be responsible for interpreting the SRV records. It could be done just as well by the client or by the server, though we expect that most clients will include this function themselves. Using something like Automounter [AMD] technology, the client would be responsible for interpreting names under a particular directory, discovering the appropriate filesystem to mount, and mounting it in the appropriate place in the @@ -317,21 +343,21 @@ Thus, it would likely be prudent also to use domain-based service principal names for the servers for the root filesystems as indicated as the targets of the SRV records. The idea here 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 an insecure DNS SRV RR lookup. The domain administrator can thus ensure that only domain root NFSv4 servers have credentials for such domain-based service principal names. Domain-based service principal names are defined in RFCs 5178 - [RFC3530] and 5179 [RFC3530]. To make use of RFC 5178's domain-based + [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 filesystem is being sought, and a hostname given in the target of the DNS SRV resource record. Thus, in the example above, two file servers (nfs1tr.example.net and nfs2ex.example.net) are located as hosting the root filesystem for the organization example.net. To communicate with, for instance, the second of the given file servers, 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 @@ -385,20 +411,26 @@ [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, . + [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