draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13.txt   rfc6641.txt 
Network Working Group C. Everhart Internet Engineering Task Force (IETF) C. Everhart
Internet-Draft W. Adamson Request for Comments: 6641 W. Adamson
Intended status: Standards Track NetApp Category: Standards Track NetApp
Expires: September 9, 2012 J. Zhang ISSN: 2070-1721 J. Zhang
Google Google
March 8, 2012 June 2012
Using DNS SRV to Specify a Global File Name Space with NFS version 4 Using DNS SRV to Specify a Global File Namespace with NFS Version 4
draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13.txt
Abstract Abstract
The NFS version 4 protocol provides a mechanism for a collection of The NFS version 4 (NFSv4) protocol provides a mechanism for a
NFS file servers to collaborate in providing an organization-wide collection of NFS file servers to collaborate in providing an
file name space. The DNS SRV RR allows a simple way for an organization-wide file namespace. The DNS SRV Resource Record (RR)
organization to publish the root of its filesystem name space, even allows a simple way for an organization to publish the root of its
to clients that might not be intimately associated with such an file system namespace, even to clients that might not be intimately
organization. The DNS SRV RR can be used to join these organization- associated with such an organization. The DNS SRV RR can be used to
wide file name spaces together to allow construction of a global, join these organization-wide file namespaces together to allow
uniform NFS file name space. construction of a global, uniform NFS file namespace.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 9, 2012. 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.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 7 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Background ......................................................3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation ...........................................3
3. Use of SRV Resource Record in DNS . . . . . . . . . . . . . . 4 3. Use of the SRV Resource Record in DNS ...........................3
4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 6 4. Integration with Use of NFS Version 4 ...........................5
4.1. Globally-useful names: conventional mount point . . . . . 6 4.1. Globally Useful Names: Conventional Mount Point ............5
4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Mount Options ..............................................6
4.3. Filesystem integration issues . . . . . . . . . . . . . . 7 4.3. File System Integration Issues .............................6
4.4. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Multicast DNS ..............................................7
5. Where is this integration carried out? . . . . . . . . . . . . 8 5. Where Is This Integration Carried Out? ..........................7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations .........................................7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations .............................................9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References ......................................................9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References .......................................9
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References ....................................10
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 1. Background
Version 4 of the NFS protocol [RFC3530] introduced the fs_locations Version 4 of the NFS protocol [RFC3530] introduced the fs_locations
attribute. Use of this attribute was elaborated further in the NFS attribute. Use of this attribute was elaborated further in the NFSv4
Version 4 Minor Version 1 protocol [RFC5661], which also defined an minor version 1 protocol [RFC5661], which also defined an extended
extended version of the attribute as fs_locations_info. With the version of the attribute as fs_locations_info. With the advent of
advent of these attributes, NFS servers can cooperate to build a file these attributes, NFS servers can cooperate to build a file namespace
name space that crosses server boundaries. The fs_locations and that crosses server boundaries. The fs_locations and
fs_locations_info attributes are used as referrals, so that a file 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 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 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 by a file system in some other set of servers. The mechanism is
general, allowing servers to describe any filesystem as being general, allowing servers to describe any file system as being
reachable by requests to any of a set of servers. Thus, starting reachable by requests to any of a set of servers. Thus, starting
with a single NFS Version 4 server, using these referrals, an NFS with a single NFSv4 server, using these referrals, an NFSv4 client
Version 4 client could see a large name space associated with a could see a large namespace associated with a collection of
collection of interrelated NFS Version 4 file servers. An interrelated NFSv4 file servers. An organization could use this
organization could use this capability to construct a uniform file capability to construct a uniform file namespace for itself.
name space for itself.
An organization might wish to publish the starting point for this An organization might wish to publish the starting point for this
name space to its clients. In many cases, the organization will want namespace to its clients. In many cases, the organization will want
to publish this starting point to a broader set of possible clients. 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 At the same time, it is useful to require that clients know only the
smallest amount of information in order to locate the appropriate smallest amount of information in order to locate the appropriate
name space. Simultaneously, that required information should be namespace. Also, that required information should be constant
constant through the life of an organization if the clients are not through the life of an organization if the clients are not to require
to require reconfiguration as administrative events change, for reconfiguration as administrative events change, for instance, a
instance, a server's name or address. server's name or address.
3. Use of SRV Resource Record in DNS 2. Requirements Notation
Providing an organization's published filesystem name space is a 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].
3. Use of the SRV Resource Record in DNS
Providing an organization's published file system namespace is a
service, and the DNS [RFC1034][RFC1035] provides methods for service, and the DNS [RFC1034][RFC1035] provides methods for
discovery of that service. This standard defines a mapping from a discovery of that service. This standard defines a mapping from a
DNS name to the NFS filesystem(s) providing the root of the DNS name to the NFS file system(s) providing the root of the file
filesystem name space associated with that DNS name; such filesystems system namespace associated with that DNS name; such file systems are
are called "domain root" filesystems. From such filesystems, like called "domain root" file systems. From such file systems, like
other NFS filesystems, an NFS client can use the standard NFS 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 mechanisms to navigate the rest of the NFS file servers that make up
the filesystem name space for the given domain. the file system namespace for the given domain.
Such "domain root" filesystems are mounted at a conventional point in Such domain root file systems are mounted at a conventional point in
the NFS client namespace. The mechanism results in a uniform cross- the NFS client namespace. The mechanism results in a uniform cross-
organizational file name space, similar to that seen in both AFS organizational file namespace, similar to that seen in both AFS
[AFS][RFC5864] and DCE/DFS [DFS]. An NFS client need know only the [AFS][RFC5864] and Distributed Computing Environment / Distributed
domain name for an organization in order to locate the filesystem File System (DCE/DFS) [DFS]. An NFS client need know only the domain
name space published by that organization. name for an organization in order to locate the file namespace
published by that organization.
The DNS SRV resource record type [RFC2782] is used to locate "domain The DNS SRV RR type [RFC2782] is used to locate domain root file
root" file servers. The format of the DNS SRV record is as follows: 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 used is "_nfs-domainroot", in conformance with RFC The Service name used is "_nfs-domainroot", in conformance with RFC
6335 [RFC6335]. The Protocol name used is "_tcp", for NFS service 6335 [RFC6335]. The Protocol name used is "_tcp", for NFS service
over TCP. Future NFS services using other protocols MUST use another 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 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] with NFSv4, as neither RFC 3530 [RFC3530] nor RFC 5661 [RFC5661]
defines NFSv4 over UDP. The Target fields give the domain names of defines NFSv4 over UDP. The Target fields give the domain names of
the NFS servers that export filesystems for the domain's root. An the NFS servers that export file systems for the domain's root. An
NFS client may then interpret any of the exported root filesystems as NFS client may then interpret any of the exported root file systems
the root of the filesystem published by the organization with the as the root of the file system published by the organization with the
given domain name. 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
as the fs_locations attribute was introduced only in NFSv4 (as version 4, as the fs_locations attribute was introduced only in NFSv4
described in Section 2). (as described in Section 1).
In order to allow the NFSv4 servers so given to export a variety of In order to allow the NFSv4 servers as given to export a variety of
filesystems, those file servers MUST export the given domain's root file systems, those file servers MUST export the given domain's root
filesystems at "/.domainroot/{Name}" within their pseudo-filesystems, file systems at "/.domainroot/{Name}" within their pseudo-file
where the "{Name}" is the name of the organization as used in the SRV systems, where the "{Name}" is the name of the organization as used
RR. in the SRV 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 file
filesystem published by organization example.net. The DNS servers system published by organization example.net. The DNS servers for
for the domain would publish records like the domain would publish records like
$ORIGIN example.net. $ORIGIN example.net.
_nfs-domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. _nfs-domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
_nfs-domainroot._tcp IN SRV 1 0 18204 nfs2ex.example.net. _nfs-domainroot._tcp IN SRV 1 0 18204 nfs2ex.example.net.
The result domain names nfs1tr.example.net and nfs2ex.example.net The resulting domain names nfs1tr.example.net and nfs2ex.example.net
indicate NFS Version 4 file servers that export the root of the indicate NFSv4 file servers that export the root of the published
published name space for the example.net domain. In accordance with namespace for the example.net domain. In accordance with RFC 2782
RFC 2782 [RFC2782], these records are to be interpreted using the [RFC2782], these records are to be interpreted using the Priority and
Priority and Weight field values, selecting an appropriate file Weight field values, selecting an appropriate file server with which
server with which to begin a network conversation. The two file to begin a network conversation. The two file servers would export
servers would export filesystems that would be found at file systems that would be found at "/.domainroot/example.net" in
"/.domainroot/example.net" in their pseudo-filesystems, which clients their pseudo-file systems, which clients would mount. Clients then
would mount. Clients then carry out subsequent accesses in carry out subsequent accesses in accordance with the ordinary NFSv4
accordance with the ordinary NFS Version 4 protocol. The first protocol. The first record uses the port number 2049 assigned to
record uses the port number 2049 assigned to NFS, and another port is NFS, and another port is specified for the second record; the NFS
specified for the second record; the NFS servers would provide NFS servers would provide NFS service at their indicated port numbers,
service at their indicated port numbers, and NFS clients would and NFS clients would connect to the service via the corresponding
connect to the service via the corresponding port numbers on those port numbers on those indicated servers.
indicated servers.
Other filesystem protocols could make use of the same "domain root" Other file system protocols could make use of the same domain root
abstraction, necessarily under different Service names not specified abstraction, but it is necessary to use different Service names not
here. specified here.
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 file
filesystem(s) in that name in the special directory. The goal is system(s) in that name in the special directory. The goal is that
that NFSv4 applications will be able to lookup an organization's NFSv4 applications will be able to look up an organization's domain
domain name in the special directory, and the NFSv4 client will be name in the special directory, and the NFSv4 client will be able to
able to discover the filesystem that that organization publishes. discover the file system that the organization publishes. Entries in
Entries in the special directory will be domain names, and they will the special directory will be domain names, and they will each appear
each appear to the application as a directory name pointing to the to the application as a directory name pointing to the root directory
root directory of the filesystem published by the organization of the file system published by the organization responsible for that
responsible for that domain name. domain name.
As noted in Section 3, the domain root service is not useful for NFS As noted in Section 3, the domain root service is not useful for NFS
versions prior to version 4. versions prior to version 4.
4.1. Globally-useful names: conventional mount point 4.1. Globally Useful Names: Conventional Mount Point
In order that the inter-organizational name space function as a
global name space, the client-side mount point for that name space
must be the same on different clients. Conventionally, on POSIX
machines, the name /nfs4/ is 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
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
/nfs4/example.net/ /nfs4/example.net/
on any POSIX client. Using this convention, "/nfs4/" is the name of on any POSIX client. Using this convention, "/nfs4/" is the name of
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 file systems 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 NFSv4 attributes fs_locations [RFC3530] or fs_locations_info
fs_locations_info [RFC5661]. For the rootpath field of fs_location, [RFC5661]. For the rootpath field of fs_location, or the fli_fs_root
or the fli_fs_root of fs_locations_info, NFS servers MUST use the field of fs_locations_info, NFS servers MUST use the "/.domainroot/
"/.domainroot/{Name}" string. Thus, the servers listed as targets {Name}" string. Thus, the servers listed as targets for the SRV RRs
for the SRV resource records MUST export the root of the MUST export the root of the organization's published file system as
organization's published filesystem as the directory "/.domainroot/ the directory "/.domainroot/{Name}" (for the given organization Name)
{Name}" (for the given organization Name) in their exported NFS in their exported NFS namespaces. For example, for organization
namespaces. For example, for organization "example.net", the 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 Section 11 of the NFSv4.1 document [RFC5661] describes the approach
approach that an NFS client should take to navigating that an NFS client should take to navigate fs_locations_info
fs_locations_info information. information.
The process of mounting an organization's name space should permit The process of mounting an organization's namespace should permit the
the use of what is likely to impose the lowest cost on the server. use of what is likely to impose the lowest cost on the server. Thus,
Thus, the NFS client SHOULD NOT insist on using a writable copy of the NFS client SHOULD NOT insist on using a writable copy of the file
the filesystem if read-only copies exist, or a zero-age copy rather system if read-only copies exist, or a zero-age copy rather than a
than a copy that may be a little older. The organization's file copy that may be a little older. The organization's file system
system representatives can be navigated to provide access to higher- representatives can be navigated to provide access to higher-cost
cost properties such as writability or freshness as necessary, but properties such as writability or freshness as necessary, but the
that the default use when navigating to the base information for an default use when navigating to the base information for 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. File System 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 namespace. A further refinement is RECOMMENDED: that only
only fully-qualified domain names appear as directories. That is, in fully qualified domain names appear as directories. That is, in many
many environments, DNS names may be abbreviated from their fully- environments, DNS names may be abbreviated from their fully qualified
qualified form. In such circumstances, multiple names might be given form. In such circumstances, multiple names might be given to NFS
to NFS clients that all resolve to the same DNS SRV RRs. The clients that all resolve to the same DNS SRV RRs. The abbreviated
abbreviated form SHOULD be represented in the client's name space form SHOULD be represented in the client's namespace cache as a
cache as a symbolic link, pointing to the fully-qualified name. This symbolic link, pointing to the fully qualified name. This will allow
will allow pathnames obtained with, say, getcwd() to include the DNS pathnames obtained with, say, getcwd() to include the DNS name that
name that is most likely to be usable outside the scope of any is most likely to be usable outside the scope of any particular DNS
particular DNS abbreviation convention. abbreviation convention.
4.4. Multicast DNS 4.4. Multicast DNS
Location of the NFS domain root by this SRV record is intended to be Location of the NFS domain root by this SRV record is intended to be
performed with unicast by using ordinary DNS [RFC1034][RFC1035] performed with unicast by using the ordinary DNS [RFC1034][RFC1035]
protocol. protocol.
This document does not define the use of this DNS SRV record format This document does not define the use of this DNS SRV record format
in conjunction with Multicast DNS (mDNS). While mDNS could be used in conjunction with Multicast DNS (mDNS). While mDNS could be used
to locate a local domain root via these SRV records, no other to locate a local domain root via these SRV records, no other
domain's root could be discovered. This means that mDNS has too domain's root could be discovered. This means that mDNS has too
little value to use in locating NFSv4 domain roots. little value to use in locating 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, by first discovering
appropriate filesystem to mount, and mounting it in the specified the appropriate file system to mount and then mounting it in the
place in the client name space before returning control to the specified place in the client namespace before returning control to
application doing a lookup. The result of the DNS lookup should be the application doing a lookup. The result of the DNS lookup should
cached (obeying TTL) so that the result could be returned more be cached (obeying Time to Live (TTL)) so that the result could be
quickly the next time. returned more quickly the next time.
6. Security Considerations 6. Security Considerations
This functionality introduces a new reliance of NFSv4 on the This functionality introduces a new reliance of NFSv4 on the
integrity of DNS. Forged SRV records in DNS could cause the NFSv4 integrity of DNS. Forged SRV records in DNS could cause the NFSv4
client to connect to the file servers of an attacker, not the file client to connect to the file servers of an attacker, rather than the
servers of an organization. This is similar to attacks that can be legitimate file servers of an organization. This is similar to
made on the base NFSv4 protocol, if server names are given in attacks that can be made on the base NFSv4 protocol, if server names
fs_location attributes: the client can be made to connect to the file are given in fs_location attributes: the client can be made to
servers of an attacker, not the file servers intended to be the connect to the file servers of an attacker, not the file servers
target for the fs_location attributes. intended to be the target for the fs_location attributes.
If DNSSEC [RFC4033] is available, it SHOULD be used to avoid both If DNS Security Extensions (DNSSEC) [RFC4033] is available, it SHOULD
such attacks. Domain-based service principal names are an additional be used to avoid both such attacks. Domain-based service principal
mechanism that also apply in this case, and it would be prudent to names are an additional mechanism that also apply in this case, and
use them. They provide a mapping from the domain name that the user it would be prudent to use them. They provide a mapping from the
specified to names of security principals used on the NFSv4 servers domain name that the user specified to names of security principals
that are indicated as the targets in the SRV records (as providing used on the NFSv4 servers that are indicated as the targets in the
file service for the root filesystems). SRV records (as providing file service for the root file systems).
With domain-based service principal names, the idea is that one wants With domain-based service principal names, the idea is that one wants
to authenticate {nfs, domainname, host.fqdn}, not simply {nfs, to authenticate {nfs, domainname, host.fqdn}, not simply {nfs,
host.fqdn}, when the server is a domain's root file server obtained 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. through a DNS SRV RR lookup that may or may not have been secure.
The domain administrator can thus ensure that only domain root NFSv4 The domain administrator can thus ensure that only domain root NFSv4
servers have credentials for such domain-based service principal servers have credentials for such domain-based service principal
names. names.
Domain-based service principal names are defined in RFCs 5178 Domain-based service principal names are defined in RFCs 5178
[RFC5178] and 5179 [RFC5179]. 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 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 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 file system is being sought, and a hostname given in the target of
DNS SRV resource record. Thus, in the example above, two file the DNS SRV RR. Thus, in the example above, two file servers
servers (nfs1tr.example.net and nfs2ex.example.net) are located as (nfs1tr.example.net and nfs2ex.example.net) are located as hosting
hosting the root filesystem for the organization example.net. To the root file system for the organization example.net. To
communicate with, for instance, the second of the given file servers, communicate with, for instance, the second of the given file servers,
GSS-API is used with the name-type of GSS_C_NT_DOMAINBASED_SERVICE Generic Security Service Application Program Interface (GSS-API) is
defined in RFC 5178 and with a symbolic name of 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 nfs@example.net@nfs2ex.example.net
in order to verify that the named server (nfs2ex.example.net) is in order to verify that the named server (nfs2ex.example.net) is
authorized to provide the root filesystem for the example.net authorized to provide the root file system for the example.net
organization. organization.
NFSv4 itself contains a facility for the negotiation of security NFSv4 itself contains a facility for the negotiation of security
mechanisms to be used between NFS clients and NFS servers. Section 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 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, describe how security mechanisms are to be negotiated. As such,
there is no need for this document to describe how that negotiation 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 is to be carried out when the NFS client contacts the NFS server for
the specified domain root filesystem(s). the specified domain root file system(s).
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
an associated port number (as defined in RFC 6335 [RFC6335]), for IANA has assigned a new Service name without an associated port
TCP. For this new Service, the Reference is this document. number (as defined in RFC 6335 [RFC6335]) for TCP. For this new
Service, the Reference is this document.
Service name: nfs-domainroot Service name: nfs-domainroot
Transport Protocol(s) TCP 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 service for the domain root, the root of Description (REQUIRED) NFS service for the domain root, the root of
an organization's published file name space. an organization's published file namespace.
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
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
Specification", RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
skipping to change at page 11, line 8 skipping to change at page 10, line 10
[RFC5178] Williams, N. and A. Melnikov, "Generic Security Service [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service
Application Program Interface (GSS-API) Application Program Interface (GSS-API)
Internationalization and Domain-Based Service Names and Internationalization and Domain-Based Service Names and
Name Type", RFC 5178, May 2008. Name Type", RFC 5178, May 2008.
[RFC5179] Williams, N., "Generic Security Service Application [RFC5179] Williams, N., "Generic Security Service Application
Program Interface (GSS-API) Domain-Based Service Names Program Interface (GSS-API) Domain-Based Service Names
Mapping for the Kerberos V GSS Mechanism", RFC 5179, Mapping for the Kerberos V GSS Mechanism", RFC 5179,
May 2008. May 2008.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, Editors, "Network [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
File System (NFS) Version 4 Minor Version 1 Protocol", "Network File System (NFS) Version 4 Minor Version 1
RFC 5661, January 2010. Protocol", RFC 5661, January 2010.
[RFC5864] Allbery, R., "DNS SRV Resource Records for AFS", RFC 5864, [RFC5864] Allbery, R., "DNS SRV Resource Records for AFS", RFC 5864,
April 2010. April 2010.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", RFC 6335, Transport Protocol Port Number Registry", BCP 165,
August 2011. RFC 6335, August 2011.
8.2. Informative References 8.2. Informative References
[AFS] Howard, J., "An Overview of the Andrew File System"", [AFS] Howard, J., "An Overview of the Andrew File System", Proc.
Proc. USENIX Winter Tech. Conf. Dallas, February 1988. USENIX Winter Tech. Conf. Dallas, February 1988.
[AMD1] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter [AMD1] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter
Reference Manual", March 1991, Reference Manual", March 1991,
<http://docs.freebsd.org/info/amdref/amdref.pdf>. <http://docs.freebsd.org/info/amdref/amdref.pdf>.
[AMD2] Crosby, M., "AMD--AutoMount Daemon", Linux Journal 1997, [AMD2] Crosby, M., "AMD--AutoMount Daemon", Linux Journal,
35es Article 4, March 1997. 35es Article 4, March 1997.
[DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V., [DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V.,
Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S., Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S.,
and E. Zayas, "DEcorum File System Architectural and E. Zayas, "DEcorum File System Architectural
Overview", Proc. USENIX Summer Conf. Anaheim, Calif., Overview", Proc. USENIX Summer Conf. Anaheim, Calif.,
June 1990. June 1990.
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813, June 1995.
Authors' Addresses Authors' Addresses
Craig Everhart Craig Everhart
NetApp NetApp
800 Cranberry Woods Drive, Ste. 300 800 Cranberry Woods Drive, Ste. 300
Cranberry Township, PA 16066 Cranberry Township, PA 16066
US USA
Phone: +1 724 741 5101 Phone: +1 724 741 5101
Email: everhart@netapp.com EMail: everhart@netapp.com
W.A. (Andy) Adamson W.A. (Andy) Adamson
NetApp NetApp
495 East Java Drive 495 East Java Drive
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US USA
Phone: +1 734 665 1204 Phone: +1 734 665 1204
Email: andros@netapp.com EMail: andros@netapp.com
Jiaying Zhang Jiaying Zhang
Google Google
604 Arizona Avenue 604 Arizona Avenue
Santa Monica, CA 90401 Santa Monica, CA 90401
US USA
Phone: +1 310 309 6884 Phone: +1 310 309 6884
Email: jiayingz@google.com EMail: jiayingz@google.com
 End of changes. 65 change blocks. 
220 lines changed or deleted 212 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/