draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08.txt   draft-ietf-nfsv4-federated-fs-dns-srv-namespace-09.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: March 5, 2012 J. Zhang Expires: April 9, 2012 J. Zhang
Google Google
September 2, 2011 October 7, 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-08.txt draft-ietf-nfsv4-federated-fs-dns-srv-namespace-09.txt
Abstract Abstract
The NFS version 4 protocol provides a natural way 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 and appropriate way file name space. The DNS SRV RR allows a simple and appropriate way
for an organization to publish the root of its name space, even to for an organization to publish the root of its filesystem name space,
clients that might not be intimately associated with such an even 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,
uniform NFS version 4 file name space. uniform NFS file name space.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 5, 2012. This Internet-Draft will expire on April 9, 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 9 skipping to change at page 3, line 9
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. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Proposed 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 . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Filesystem integration issues . . . . . . . . . . . . . . 8 4.3. Filesystem integration issues . . . . . . . . . . . . . . 8
4.4. Multicast, mDNS, and DNS-SD . . . . . . . . . . . . . . . 8
5. Where is this integration carried out? . . . . . . . . . . . . 8 5. Where is this integration carried out? . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Background 2. Background
The NFS Version 4 protocol [RFC3530] introduced the fs_locations Version 4 of the NFS protocol [RFC3530] introduced the fs_locations
attribute. Its use was elaborated further in the NFS Version 4 Minor attribute. Use of this attribute was elaborated further in the NFS
Version 1 protocol [RFC5661], which also defined an extended version Version 4 Minor Version 1 protocol [RFC5661], which also defined an
of the attribute as fs_locations_info. With the advent of these extended version of the attribute as fs_locations_info. With the
attributes, NFS servers can cooperate to build a file name space that advent of these attributes, NFS servers can cooperate to build a file
crosses server boundaries. The fs_locations and fs_locations_info name space that crosses server boundaries. The fs_locations and
attributes are used as referrals, so that a file server may indicate fs_locations_info attributes are used as referrals, so that a file
to its client that the file name tree beneath a given name in the server may indicate to its client that the file name tree beneath a
server is not present on itself, but is represented by a filesystem given name in the server is not present on itself, but is represented
in some other set of servers. The mechanism is general, allowing by a filesystem in some other set of servers. The mechanism is
servers to describe any filesystem as being reachable by requests to general, allowing servers to describe any filesystem as being
any of a set of servers. Thus, starting with a single NFS Version 4 reachable by requests to any of a set of servers. Thus, starting
server, using these referrals, an NFS Version 4 client might be able with a single NFS Version 4 server, using these referrals, an NFS
to see a large name space associated with a collection of Version 4 client could see a large name space associated with a
interrelated NFS Version 4 file servers. An organization could use collection of interrelated NFS Version 4 file servers. An
this capability to construct a uniform file name space for itself. 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 An organization might wish to publish the starting point for this
name space to its clients. In many cases, the organization will want name space 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 clients to 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 name space. Simultaneously, that required information should be
constant through the life of an organization if the clients are not constant through the life of an organization if the clients are not
to require reconfiguration as administrative events change, for to require reconfiguration as administrative events change, for
instance, a server's name or address. instance, a server's name or address.
3. Proposed Use of SRV Resource Record in DNS 3. Use of SRV Resource Record in DNS
Providing an organization's published filesystem name space is a Providing an organization's published filesystem name space is a
service, and it is appropriate to use the DNS [RFC1034][RFC1035] to service, and the DNS [RFC1034][RFC1035] provides methods for
locate it. As with the AFSDB resource record type [RFC1183], the discovery of that service. This standard defines a mapping from a
client need only utter the (relatively) constant domain name for an domain name to the NFS filesystem(s) associated with that name; such
organization in order to locate its filesystem name space service. filesystems are called "domain root" filesystems. From such
Once a client uses the DNS to locate one or more servers for the root filesystems, like other NFS filesystems, an NFS client can use the
of the organization's name space, it can use the standard NFS Version standard NFS mechanisms to navigate the rest of the NFS file servers
4 mechanisms to navigate the remainder of the NFS servers for that that make up the filesystem name space for the given domain.
organization. The use of this proposed mechanism results in a useful
cross-organizational name space, just as in AFS [AFS] and DCE/DFS
[DFS] before it. A client need know only the name of the
organization in order to locate the filesystem name space published
by that organization.
We propose the use of the DNS SRV resource record type [RFC2782] to Such "domain root" filesystems are mounted at a conventional point in
fulfill this function. The format of the DNS SRV record is as the NFS client namespace. The mechanism results in a uniform cross-
follows: 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 _Service._Proto.Name TTL Class SRV Priority Weight Port Target
In our case, we use a Service name of "_nfs4._domainroot" and a The Service name is "_nfs._domainroot". The Protocol as of this
conventional Protocol of "_tcp". The Target fields give the domain writing could be either "_tcp" or "_sctp"; version 4 NFS is not
names of the NFS Version 4 servers that export filesystems for the defined over UDP. Other transport protocols could be defined in the
domain's root. An NFS Version 4 client SHOULD interpret any of the future, and SRV records that advertise domain root file services with
exported root filesystems as the filesystem published by the other transport protocols would use the same Service name. The
organization with the given domain name. 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 organization with the given domain name.
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 SHOULD 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 could publish records like for the domain would publish records like
$ORIGIN example.net. $ORIGIN example.net.
_nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. _nfs._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
_nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net. _nfs._domainroot._tcp IN SRV 1 0 2049 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. accordance with the ordinary NFS Version 4 protocol.
We use a composite Service name (built from "_nfs4" and Other filesystem protocols could make use of the same "domain root"
"_domainroot") so that other filesystem protocols could make use of abstraction, but this document discusses only the SRV records
the same "_domainroot" abstraction. indicating NFS servers.
4. Integration with Use of NFS Version 4 4. Integration with Use of NFS Version 4
We expect that NFSv4 clients will implement a special directory, NFSv4 clients adhering to this specification implement a special
analogous to an Automounter [AMD] directory, the entries in which are directory, analogous to an Automounter [AMD1][AMD2] directory, the
domain names that have recently been traversed. When an application entries in which are domain names that have recently been traversed.
attempts to traverse a new name in that special directory, the NFSv4 When an application attempts to traverse a new name in that special
client consults DNS to obtain the SRV data for the given name, and if directory, the NFSv4 client consults DNS to obtain the SRV data for
successful, it mounts the indicated filesystem(s) in that name in the the given name, and if successful, it mounts the indicated
special directory. The goal is that NFSv4 applications will be able filesystem(s) in that name in the special directory. The goal is
to lookup an organization's domain name in the special directory, and that NFS applications will be able to lookup an organization's domain
the NFSv4 client will be able to discover the filesystem that that name in the special directory, and the NFSv4 client will be able to
organization publishes. Entries in the special directory will be discover the filesystem that that organization publishes. Entries in
domain names, and they will each appear to the application as a the special directory will be domain names, and they will each appear
directory name pointing to the root directory of the filesystem to the application as a directory name pointing to the root directory
published by the organization responsible for that domain name. of the filesystem published by the organization responsible for that
domain name.
This functionality does not require or use any list of organizations
that are known to provide file service, such as was required with the
"root.afs" functionality in AFS.
This DNS SRV record evaluation could, in principle, be done either in 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 the NFSv4 client or in an NFSv4 server. In either case, the result
would appear the same to applications on the NFSv4 client. This is would appear the same to applications on the NFSv4 client. This is
discussed further in section 5 of this document. discussed further in section 5 of this document.
4.1. Globally-useful names: conventional mount point 4.1. Globally-useful names: conventional mount point
For the inter-organizational name space to be a global name space, it In order that the inter-organizational name space function as a
is useful for its mount point in local systems to be uniform as well. global name space, the client-side mount point for that name space
On POSIX machines, the name /nfs4/ SHOULD be used so that names on must be the same on different clients. Conventionally, on POSIX
one machine will be directly usable on any machine. Thus, the machines, the name /nfs4/ is be used so that names on one machine
example.net published filesystem would be accessible as will be directly usable on any machine. Thus, the example.net
published filesystem 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 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, we use the "/.domainroot- or the fli_fs_root of fs_locations_info, NFS servers MUST use the
{Name}" string. Thus, the servers listed as targets for the SRV "/.domainroot-{Name}" string. Thus, the servers listed as targets
resource records should export the root of the organization's for the SRV resource records MUST export the root of the
published filesystem as the directory "/.domainroot-{Name}" (for the organization's published filesystem as the directory "/.domainroot-
given organization Name) in its exported namespace. For example, for {Name}" (for the given organization Name) in their exported NFS
organization "example.net", the directory "/.domainroot-example.net" namespaces. For example, for organization "example.net", the
should be used. directory "/.domainroot-example.net" would be used.
As for the other attributes in fs_locations_info, the recommended Chapter 11 of the NFS Version 4.1 document [RFC5661] describes the
approach is for a client to make its first possible contact with any approach that an NFS client should take to navigating
of the referred-to servers, obtain the fs_locations_info structure fs_locations_info information.
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.
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. We presume that the
organization's file name space can be navigated to provide access to organization's file name space can be navigated to provide access to
higher-cost properties such as writability or currency as necessary, higher-cost properties such as writability or freshness as necessary,
but that the default use when navigating to the base information for but that the default use when navigating to the base information for
an organization ought to be as low-overhead as possible. an organization ought to be as low-overhead as possible.
Because of the possible distinction between read-only and read-write Because of the possible distinction between read-only and read-write
versions of a filesystem, organizations SHOULD also publish the versions of a filesystem, organizations MAY also publish the location
location of a writable instance of their root filesystems, and that of a writable instance of their domain root filesystems, and that
NFSv4 clients SHOULD mount that filesystem under the organizational NFSv4 clients would conventionally mount that filesystem under the
domain name preceded by a period ("."). Therefore, when names organizational domain name preceded by a period ("."). Therefore,
beginning with a period are looked up under the NFSv4 client's when names beginning with a period are looked up under the NFSv4
special directory, the SRV RR looked up in DNS uses a Service name of client's special directory, the SRV RR looked up in DNS uses a
"_nfs4._write._domainroot", and the indicated server (or servers) Service name of "_nfs._write._domainroot", and any indicated server
SHOULD export the writable instance at "/.domainroot-write-{Name}" (or servers) MUST export the writable instance at "/.domainroot-
for a domain name Name. write-{Name}" for a domain name Name.
Extending the opening example, suppose a client wished to locate the Extending the opening example, suppose a client wished to locate the
read-only and read-write roots of the filesystem published by read-only and read-write roots of the filesystem published by
organization example.net. Suppose a read-write instance were hosted organization example.net. Suppose a read-write instance were hosted
on server nfs1tr.example.net, and read-only instances were on that on server nfs1tr.example.net, and read-only instances were on that
server and also on server nfs2ex.example.net. The DNS servers for server and also on server nfs2ex.example.net. The DNS servers for
the domain would publish records like the domain would publish records like
$ORIGIN example.net. $ORIGIN example.net.
_nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. _nfs._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
_nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net. _nfs._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net.
_nfs4._write._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. _nfs._write._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
The nfs1tr.example.net server would export filesystems at both The nfs1tr.example.net server would export filesystems at both
"/.domainroot-example.net" (the read-only instance) and "/.domainroot-example.net" (the read-only instance) and
"/.domainroot-write-example.net" (the read-write instance). The "/.domainroot-write-example.net" (the read-write instance). The
nfs2ex.example.net server need export only the "/.domainroot- nfs2ex.example.net server need export only the "/.domainroot-
example.net" name for its read-only instance. example.net" name for its read-only instance.
The read-write version of the filesystem would be mounted (upon use) The read-write version of the filesystem would be mounted (upon use)
under ".example.net" in the special directory, and a read-only under ".example.net" in the special directory, and a read-only
version would be mounted under "example.net". Thus, version would be mounted under "example.net". Thus,
/nfs4/example.net/users /nfs4/example.net/users
might be a directory in a read-only instance of the root filesystem might be a directory in a read-only instance of the root filesystem
of the organization "example.net", while of the organization "example.net", while
/nfs4/.example.net/users /nfs4/.example.net/users
would be a writable form of that same directory. A small benefit of would be a writable form of that same directory.
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. 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 advisable, and SHOULD the client name space. A further refinement is RECOMMENDED: that
be deployed: that only fully-qualified domain names appear as only fully-qualified domain names appear as directories. That is, in
directories. That is, in many environments, DNS names may be many environments, DNS names may be abbreviated from their fully-
abbreviated from their fully-qualified form. In such circumstances, qualified form. In such circumstances, multiple names might be given
multiple names might be given to filesystem code that all resolve to to NFS clients that all resolve to the same DNS SRV RRs. The
the same DNS SRV RRs. The abbreviated form SHOULD be represented in abbreviated form SHOULD be represented in the client's name space
the client's name space cache as a symbolic link, pointing to the cache as a symbolic link, pointing to the fully-qualified name, case-
fully-qualified name, case-canonicalized when appropriate. This will folded if the client filesystem is case-sensitive. This will allow
allow pathnames obtained with, say, getcwd() to include the DNS name pathnames obtained with, say, getcwd() to include the DNS name that
that is most likely to be usable outside the scope of any particular is most likely to be usable outside the scope of any particular DNS
DNS abbreviation convention. abbreviation convention.
4.4. Multicast, mDNS, and DNS-SD
Location of the NFS domain root does not involve IP-layer broadcast,
multicast, or anycast communication.
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.
5. Where is this integration carried out? 5. Where is this integration carried out?
Another consideration is what agent should be responsible for The NFS client is responsible for interpreting SRV records. Using
interpreting the SRV records. It could be done just as well by the something like Automounter [AMD1] [AMD2] technology, the client
NFS client or by the NFS server, though we expect that most clients interprets names under a particular directory, discovering the
will include this function themselves. Using something like appropriate filesystem to mount, and mounting it in the specified
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 client name space before returning control to the place in the client name space before returning control to the
application doing a lookup. Alternatively, one could imagine the application doing a lookup. The result of the DNS lookup should be
existence of an NFS version 4 server that awaited similar domain-name cached (obeying TTL) so that the result could be returned more
lookups, then consulted the SRV records in DNS to determine the quickly the next time.
servers for the indicated published filesystem, and then returned
that information as an NFS Version 4 referral. In either case, the
result of the DNS lookup should be cached (obeying TTL) so that the
result could be returned more quickly the next time.
NFS clients compliant to this standard MUST implement this
functionality. While we recognize that it would be possible to
configure clients so that they relied on a specially-configured
server to do their SRV lookups for them, we feel that such a
requirement would impose unusual dependencies and vulnerabilities for
the deployers of such clients.
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. Spoofed 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, not the file
servers of an organization. This is similar to attacks that can be servers of an organization. This is similar to attacks that can be
made on the base NFSv4 protocol, if server names are given in made on the base NFSv4 protocol, if server names are given in
fs_location attributes: the client can be made to connect to the file fs_location attributes: the client can be made to connect to the file
servers of an attacker, not the file servers intended to be the servers of an attacker, not the file servers intended to be the
target for the fs_location attributes. target for the fs_location attributes.
If DNSSEC [RFC4033] is available, it SHOULD be used to avoid both If DNSSEC [RFC4033] is available, it SHOULD be used to avoid both
such attacks. Domain-based service principal names are a mechanism such attacks. Domain-based service principal names are an additional
that also apply in this case, and it would be prudent to use them. mechanism that also apply in this case, and it would be prudent to
They provide a mapping from the domain name that the user specified use them. They provide a mapping from the domain name that the user
to names of security principals used on the NFSv4 servers that are specified to names of security principals used on the NFSv4 servers
indicated as the targets in the SRV records (as providing file that are indicated as the targets in the SRV records (as providing
service for the root filesystems). file service for the root filesystems).
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
skipping to change at page 10, line 15 skipping to change at page 10, line 9
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 GSS-API is used with the name-type of GSS_C_NT_DOMAINBASED_SERVICE
defined in RFC 5178 and with a symbolic name of 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 filesystem for the example.net
organization. organization.
NFSv4 itself contains a facility for the negotiation of security
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
describe how security mechanisms are to be negotiated. As such,
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
the specified domain root filesystem(s).
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 7. IANA Considerations
This document requests the assignment of two new Service names
without associated port numbers, each for both TCP and SCTP. For
both Services, the Reference is this document.
None. Service name: _nfs._domainroot
Transport Protocol(s) TCP, SCTP
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
Reference (REQUIRED) This document
Port Number (OPTIONAL)
Service Code (REQUIRED for DCCP only)
Known Unauthorized Uses (OPTIONAL)
Assignment Notes (OPTIONAL)
Service name: _nfs._write._domainroot
Transport Protocol(s) TCP, SCTP
Assignee (REQUIRED) IESG (iesg@ietf.org)
Contact (REQUIRED) IETF Chair (chair@ietf.org)
Description (REQUIRED) Writable file server for the NFS file service
for the domain root, the root of the 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. 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. RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987. Specification", RFC 1035, November 1987.
skipping to change at page 11, line 12 skipping to change at page 12, line 27
[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., Eisler, M., and D. Noveck, Editors, "Network
File System (NFS) Version 4 Minor Version 1 Protocol", File System (NFS) Version 4 Minor Version 1 Protocol",
RFC 5661, January 2010. RFC 5661, January 2010.
[RFC5864] Allbery, R., "DNS SRV Resource Records for AFS", RFC 5864,
April 2010.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", 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. USENIX Winter Tech. Conf. Dallas, February 1988. Proc. USENIX Winter Tech. Conf. Dallas, February 1988.
[AMD] 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,
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.
[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P.
Mockapetris, "New DNS RR Definitions", RFC 1183,
October 1990.
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 US
Phone: +1 724 741 5101 Phone: +1 724 741 5101
Email: everhart@netapp.com Email: everhart@netapp.com
 End of changes. 39 change blocks. 
156 lines changed or deleted 200 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/