--- 1/draft-ietf-nfsv4-federated-fs-dns-srv-namespace-10.txt 2011-12-21 22:14:02.434671070 +0100 +++ 2/draft-ietf-nfsv4-federated-fs-dns-srv-namespace-11.txt 2011-12-21 22:14:02.462671546 +0100 @@ -1,20 +1,20 @@ Network Working Group C. Everhart Internet-Draft W. Adamson Intended status: Standards Track NetApp -Expires: April 28, 2012 J. Zhang +Expires: June 23, 2012 J. Zhang Google - October 26, 2011 + December 21, 2011 Using DNS SRV to Specify a Global File Name Space with NFS version 4 - draft-ietf-nfsv4-federated-fs-dns-srv-namespace-10.txt + draft-ietf-nfsv4-federated-fs-dns-srv-namespace-11.txt Abstract The NFS version 4 protocol provides a mechanism for a collection of NFS file servers to collaborate in providing an organization-wide file name space. The DNS SRV RR allows a simple way for an organization to publish the root of its filesystem 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 April 28, 2012. + This Internet-Draft will expire on June 23, 2012. Copyright Notice Copyright (c) 2011 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 @@ -66,21 +66,21 @@ Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. 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 . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Filesystem integration issues . . . . . . . . . . . . . . 7 - 4.4. Multicast, mDNS, and DNS-SD . . . . . . . . . . . . . . . 8 + 4.4. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 7 5. Where is this integration carried out? . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Requirements notation @@ -134,70 +134,68 @@ organizational file name space, similar to that seen in both AFS [AFS][RFC5864] and DCE/DFS [DFS]. An NFS client need know only the domain name for an organization in order to locate the filesystem name space published by that organization. The DNS SRV resource record type [RFC2782] is used to locate "domain root" file servers. The format of the DNS SRV record is as follows: _Service._Proto.Name TTL Class SRV Priority Weight Port Target - The Service name is "_nfs._domainroot". The Protocol as of this - writing could be either "_tcp" or "_sctp"; version 4 NFS is not - defined over UDP. Other transport protocols could be defined in the - future, and SRV records that advertise domain root file services with - other transport protocols would use the same Service name. The - Target fields give the domain names of the NFS servers that export - filesystems for the domain's root. An NFS client may then interpret - any of the exported root filesystems as the filesystem published by + The Service name used is "_domainroot._nfs" (using a "_domainroot" + subtype within the "_nfs" service). The Protocol without limitation + could be either of the labels "_tcp" or "_udp". The Target fields + give the domain names of the NFS servers that export filesystems for + the domain's root. An NFS client may then interpret any of the + exported root filesystems as the root of the filesystem published by the organization with the given domain name. The domain root service is not useful for NFS versions prior to v4, as the fs_locations attribute was introduced only in NFSv4 (as - described in Section 2). The "_nfs." Service name prefix is not - limited to NFSv4; it is possible to use that prefix in naming - additional Services (and their SRV records) that are also applicable - to other versions of NFS (e.g., NFSv3 [RFC1813]. + described in Section 2). The "_nfs" Service name is not limited to + NFSv4; it is possible to use that prefix in naming additional + Services (and their SRV records) that are also applicable to other + versions of NFS (e.g., NFSv3 [RFC1813]. In order to allow the NFSv4 servers so given to export a variety of filesystems, those file servers MUST export the given domain's root - filesystems at "/.domainroot-{Name}" within their pseudo-filesystems, + 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 would publish records like $ORIGIN example.net. - _nfs._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. - _nfs._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net. + _domainroot._nfs._tcp IN SRV 0 0 2049 nfs1tr.example.net. + _domainroot._nfs._tcp IN SRV 1 0 18204 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 [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 - "/.domainroot-example.net" in their pseudo-filesystems, which clients + "/.domainroot/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. The records use - the port number 2049 assigned to NFS, but another port number could - be specified here; the NFS servers would provide NFS service at the - indicated port number, and NFS clients would connect to the service - at that indicated port number. + accordance with the ordinary NFS Version 4 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. Other filesystem protocols could make use of the same "domain root" - abstraction, as well as the same "_domainroot" Service name suffix, - but this document discusses only the SRV records indicating NFS - servers. + abstraction, necessarily under different Service names not specified + here. 4. Integration with Use of NFS Version 4 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 filesystem(s) in that name in the special directory. The goal is @@ -227,66 +225,66 @@ 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 [RFC3530] or fs_locations_info [RFC5661]. For the rootpath field of fs_location, or the fli_fs_root of fs_locations_info, NFS servers MUST use the - "/.domainroot-{Name}" string. Thus, the servers listed as targets + "/.domainroot/{Name}" string. Thus, the servers listed as targets for the SRV resource records MUST export the root of the - organization's published filesystem as the directory "/.domainroot- + organization's published filesystem 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. + directory "/.domainroot/example.net" would be used. Chapter 11 of the NFS Version 4.1 document [RFC5661] describes the approach that an NFS client should take to navigating fs_locations_info information. 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 freshness as necessary, - but that the default use when navigating to the base information for - an organization ought to be as low-overhead as possible. + 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 + that the default use when navigating to the base information for an + organization ought to be as low-overhead as possible. 4.3. Filesystem integration issues The result of the DNS search SHOULD appear as a (pseudo-)directory in the client name space. 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 name space 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. -4.4. Multicast, mDNS, and DNS-SD +4.4. Multicast DNS - Location of the NFS domain root by this mechanism does not involve - IP-layer broadcast, multicast, or anycast communication. + Location of the NFS domain root by this SRV record is intended to be + performed with unicast by using ordinary DNS [RFC1034][RFC1035] + protocol. - It is not expected that this DNS SRV record format will be used in - conjunction with Multicast DNS (mDNS) or DNS Service Discovery - (DNS-SD). 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 with DNS-SD has too little value to use in locating - NFSv4 domain roots. + 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. 5. Where is this integration carried out? The NFS client is responsible for interpreting SRV records. Using something like Automounter [AMD1] [AMD2] technology, the client interprets names under a particular directory, discovering the appropriate filesystem to mount, and mounting it in the specified place in the client name space before returning control to the application doing a lookup. The result of the DNS lookup should be cached (obeying TTL) so that the result could be returned more @@ -348,30 +345,30 @@ 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. 7. IANA Considerations This document requests the assignment of a new Service name without - an associated port numbers (as defined in RFC 6335 [RFC6335], each - for both TCP and SCTP. For this new Service, the Reference is this - document. + an associated port number (as defined in RFC 6335 [RFC6335]), for + TCP. For this new Service, the Reference is this document. - Service name: _nfs._domainroot - Transport Protocol(s) TCP, SCTP + Service name: domainroot + Transport Protocol(s) TCP Assignee (REQUIRED) IESG (iesg@ietf.org) Contact (REQUIRED) IETF Chair (chair@ietf.org) - Description (REQUIRED) NFS file service for the domain root, the root - of the organization's published file name space + Description (REQUIRED) Subtype of NFS file service, indicating NFS + service for the domain root, the root of an + organization's published file name space. Reference (REQUIRED) This document Port Number (OPTIONAL) Service Code (REQUIRED for DCCP only) Known Unauthorized Uses (OPTIONAL) Assignment Notes (OPTIONAL) 8. References 8.1. Normative References