draft-ietf-nfsv4-federated-fs-dns-srv-namespace-10.txt   draft-ietf-nfsv4-federated-fs-dns-srv-namespace-11.txt 
Network Working Group C. Everhart Network Working Group C. Everhart
Internet-Draft W. Adamson Internet-Draft W. Adamson
Intended status: Standards Track NetApp Intended status: Standards Track NetApp
Expires: April 28, 2012 J. Zhang Expires: June 23, 2012 J. Zhang
Google Google
October 26, 2011 December 21, 2011
Using DNS SRV to Specify a Global File Name Space with NFS version 4 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 Abstract
The NFS version 4 protocol provides a mechanism for a collection of The NFS version 4 protocol provides a mechanism for a collection of
NFS file servers to collaborate in providing an organization-wide NFS file servers to collaborate in providing an organization-wide
file name space. The DNS SRV RR allows a simple way for an file name space. The DNS SRV RR allows a simple way for an
organization to publish the root of its filesystem name space, even organization to publish the root of its filesystem name space, even
to clients that might not be intimately associated with such an to clients that might not be intimately associated with such an
organization. The DNS SRV RR can be used to join these organization- organization. The DNS SRV RR can be used to join these organization-
wide file name spaces together to allow construction of a global, wide file name spaces together to allow construction of a global,
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use of SRV Resource Record in DNS . . . . . . . . . . . . . . 4 3. Use of SRV Resource Record in DNS . . . . . . . . . . . . . . 4
4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 6 4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 6
4.1. Globally-useful names: conventional mount point . . . . . 6 4.1. Globally-useful names: conventional mount point . . . . . 6
4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Filesystem integration issues . . . . . . . . . . . . . . 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 5. Where is this integration carried out? . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Requirements notation 1. Requirements notation
skipping to change at page 5, line 17 skipping to change at page 5, line 17
organizational file name space, similar to that seen in both AFS organizational file name space, similar to that seen in both AFS
[AFS][RFC5864] and DCE/DFS [DFS]. An NFS client need know only the [AFS][RFC5864] and DCE/DFS [DFS]. An NFS client need know only the
domain name for an organization in order to locate the filesystem domain name for an organization in order to locate the filesystem
name space published by that organization. name space published by that organization.
The DNS SRV resource record type [RFC2782] is used to locate "domain 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: root" file servers. The format of the DNS SRV record is as follows:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target _Service._Proto.Name TTL Class SRV Priority Weight Port Target
The Service name is "_nfs._domainroot". The Protocol as of this The Service name used is "_domainroot._nfs" (using a "_domainroot"
writing could be either "_tcp" or "_sctp"; version 4 NFS is not subtype within the "_nfs" service). The Protocol without limitation
defined over UDP. Other transport protocols could be defined in the could be either of the labels "_tcp" or "_udp". The Target fields
future, and SRV records that advertise domain root file services with give the domain names of the NFS servers that export filesystems for
other transport protocols would use the same Service name. The the domain's root. An NFS client may then interpret any of the
Target fields give the domain names of the NFS servers that export exported root filesystems as the root of the filesystem published by
filesystems for the domain's root. An NFS client may then interpret
any of the exported root filesystems as the filesystem published by
the organization with the given domain name. the organization with the given domain name.
The domain root service is not useful for NFS versions prior to v4, The domain root service is not useful for NFS versions prior to v4,
as the fs_locations attribute was introduced only in NFSv4 (as as the fs_locations attribute was introduced only in NFSv4 (as
described in Section 2). The "_nfs." Service name prefix is not described in Section 2). The "_nfs" Service name is not limited to
limited to NFSv4; it is possible to use that prefix in naming NFSv4; it is possible to use that prefix in naming additional
additional Services (and their SRV records) that are also applicable Services (and their SRV records) that are also applicable to other
to other versions of NFS (e.g., NFSv3 [RFC1813]. versions of NFS (e.g., NFSv3 [RFC1813].
In order to allow the NFSv4 servers so given to export a variety of 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, 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 where the "{Name}" is the name of the organization as used in the SRV
RR. RR.
As an example, suppose a client wished to locate the root of the As an example, suppose a client wished to locate the root of the
filesystem published by organization example.net. The DNS servers filesystem published by organization example.net. The DNS servers
for the domain would publish records like for the domain would publish records like
$ORIGIN example.net. $ORIGIN example.net.
_nfs._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. _domainroot._nfs._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 1 0 18204 nfs2ex.example.net.
The result domain names nfs1tr.example.net and 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 indicate NFS Version 4 file servers that export the root of the
published name space for the example.net domain. In accordance with published name space for the example.net domain. In accordance with
RFC 2782 [RFC2782], these records are to be interpreted using the RFC 2782 [RFC2782], these records are to be interpreted using the
Priority and Weight field values, selecting an appropriate file Priority and Weight field values, selecting an appropriate file
server with which to begin a network conversation. The two file server with which to begin a network conversation. The two file
servers would export filesystems that would be found at 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 would mount. Clients then carry out subsequent accesses in
accordance with the ordinary NFS Version 4 protocol. The records use accordance with the ordinary NFS Version 4 protocol. The first
the port number 2049 assigned to NFS, but another port number could record uses the port number 2049 assigned to NFS, and another port is
be specified here; the NFS servers would provide NFS service at the specified for the second record; the NFS servers would provide NFS
indicated port number, and NFS clients would connect to the service service at their indicated port numbers, and NFS clients would
at that indicated port number. connect to the service via the corresponding port numbers on those
indicated servers.
Other filesystem protocols could make use of the same "domain root" Other filesystem protocols could make use of the same "domain root"
abstraction, as well as the same "_domainroot" Service name suffix, abstraction, necessarily under different Service names not specified
but this document discusses only the SRV records indicating NFS here.
servers.
4. Integration with Use of NFS Version 4 4. Integration with Use of NFS Version 4
NFSv4 clients adhering to this specification implement a special NFSv4 clients adhering to this specification implement a special
directory, analogous to an Automounter [AMD1][AMD2] directory, the directory, analogous to an Automounter [AMD1][AMD2] directory, the
entries in which are domain names that have recently been traversed. entries in which are domain names that have recently been traversed.
When an application attempts to traverse a new name in that special When an application attempts to traverse a new name in that special
directory, the NFSv4 client consults DNS to obtain the SRV data for directory, the NFSv4 client consults DNS to obtain the SRV data for
the given name, and if successful, it mounts the indicated the given name, and if successful, it mounts the indicated
filesystem(s) in that name in the special directory. The goal is filesystem(s) in that name in the special directory. The goal is
skipping to change at page 7, line 14 skipping to change at page 7, line 12
the special directory that is populated with domain names, leading to the special directory that is populated with domain names, leading to
file servers and filesystems that capture the results of SRV record file servers and filesystems that capture the results of SRV record
lookups. lookups.
4.2. Mount options 4.2. Mount options
SRV records are necessarily less complete than the information in the SRV records are necessarily less complete than the information in the
existing NFS Version 4 attributes fs_locations [RFC3530] or existing NFS Version 4 attributes fs_locations [RFC3530] or
fs_locations_info [RFC5661]. For the rootpath field of fs_location, 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 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 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 {Name}" (for the given organization Name) in their exported NFS
namespaces. For example, for organization "example.net", the 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 Chapter 11 of the NFS Version 4.1 document [RFC5661] describes the
approach that an NFS client should take to navigating approach that an NFS client should take to navigating
fs_locations_info information. fs_locations_info information.
The process of mounting an organization's name space should permit 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. 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 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 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 than a copy that may be a little older. The organization's file
organization's file name space can be navigated to provide access to system representatives can be navigated to provide access to higher-
higher-cost properties such as writability or freshness as necessary, cost properties such as writability or freshness as necessary, but
but that the default use when navigating to the base information for that the default use when navigating to the base information for an
an organization ought to be as low-overhead as possible. organization ought to be as low-overhead as possible.
4.3. Filesystem integration issues 4.3. Filesystem integration issues
The result of the DNS search SHOULD appear as a (pseudo-)directory in The result of the DNS search SHOULD appear as a (pseudo-)directory in
the client name space. A further refinement is RECOMMENDED: that the client name space. A further refinement is RECOMMENDED: that
only fully-qualified domain names appear as directories. That is, in only fully-qualified domain names appear as directories. That is, in
many environments, DNS names may be abbreviated from their fully- many environments, DNS names may be abbreviated from their fully-
qualified form. In such circumstances, multiple names might be given qualified form. In such circumstances, multiple names might be given
to NFS clients that all resolve to the same DNS SRV RRs. The to NFS clients that all resolve to the same DNS SRV RRs. The
abbreviated form SHOULD be represented in the client's name space abbreviated form SHOULD be represented in the client's name space
cache as a symbolic link, pointing to the fully-qualified name. This cache as a symbolic link, pointing to the fully-qualified name. This
will allow pathnames obtained with, say, getcwd() to include the DNS will allow pathnames obtained with, say, getcwd() to include the DNS
name that is most likely to be usable outside the scope of any name that is most likely to be usable outside the scope of any
particular DNS abbreviation convention. 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 Location of the NFS domain root by this SRV record is intended to be
IP-layer broadcast, multicast, or anycast communication. performed with unicast by using ordinary DNS [RFC1034][RFC1035]
protocol.
It is not expected that this DNS SRV record format will be used in This document does not define the use of this DNS SRV record format
conjunction with Multicast DNS (mDNS) or DNS Service Discovery in conjunction with Multicast DNS (mDNS). While mDNS could be used
(DNS-SD). While mDNS could be used to locate a local domain root via to locate a local domain root via these SRV records, no other
these SRV records, no other domain's root could be discovered. This domain's root could be discovered. This means that mDNS has too
means that mDNS with DNS-SD has too little value to use in locating little value to use in locating NFSv4 domain roots.
NFSv4 domain roots.
5. Where is this integration carried out? 5. Where is this integration carried out?
The NFS client is responsible for interpreting SRV records. Using The NFS client is responsible for interpreting SRV records. Using
something like Automounter [AMD1] [AMD2] technology, the client something like Automounter [AMD1] [AMD2] technology, the client
interprets names under a particular directory, discovering the interprets names under a particular directory, discovering the
appropriate filesystem to mount, and mounting it in the specified appropriate filesystem to mount, and mounting it in the specified
place in the client name space before returning control to the place in the client name space before returning control to the
application doing a lookup. The result of the DNS lookup should be application doing a lookup. The result of the DNS lookup should be
cached (obeying TTL) so that the result could be returned more cached (obeying TTL) so that the result could be returned more
skipping to change at page 10, line 5 skipping to change at page 10, line 5
Using SRV records to advertise the locations of NFS servers may Using SRV records to advertise the locations of NFS servers may
expose those NFS servers to attacks. Organizations should carefully expose those NFS servers to attacks. Organizations should carefully
consider whether they wish their DNS servers to respond consider whether they wish their DNS servers to respond
differentially to different DNS clients, perhaps exposing their SRV differentially to different DNS clients, perhaps exposing their SRV
records to only those DNS requests that originate within a given records to only those DNS requests that originate within a given
perimeter, in order to reduce this exposure. perimeter, in order to reduce this exposure.
7. IANA Considerations 7. IANA Considerations
This document requests the assignment of a new Service name without This document requests the assignment of a new Service name without
an associated port numbers (as defined in RFC 6335 [RFC6335], each an associated port number (as defined in RFC 6335 [RFC6335]), for
for both TCP and SCTP. For this new Service, the Reference is this TCP. For this new Service, the Reference is this document.
document.
Service name: _nfs._domainroot Service name: domainroot
Transport Protocol(s) TCP, SCTP Transport Protocol(s) TCP
Assignee (REQUIRED) IESG (iesg@ietf.org) Assignee (REQUIRED) IESG (iesg@ietf.org)
Contact (REQUIRED) IETF Chair (chair@ietf.org) Contact (REQUIRED) IETF Chair (chair@ietf.org)
Description (REQUIRED) NFS file service for the domain root, the root Description (REQUIRED) Subtype of NFS file service, indicating NFS
of the organization's published file name space service for the domain root, the root of an
organization's published file name space.
Reference (REQUIRED) This document Reference (REQUIRED) This document
Port Number (OPTIONAL) Port Number (OPTIONAL)
Service Code (REQUIRED for DCCP only) Service Code (REQUIRED for DCCP only)
Known Unauthorized Uses (OPTIONAL) Known Unauthorized Uses (OPTIONAL)
Assignment Notes (OPTIONAL) Assignment Notes (OPTIONAL)
8. References 8. References
8.1. Normative References 8.1. Normative References
 End of changes. 22 change blocks. 
53 lines changed or deleted 51 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/