Network Working Group C. Everhart
Internet-Draft Network Appliance, Inc.
Expires: August 26, 2006 A. Adamson
CITI, University of Michigan
J. Zhang
University of Michigan
E. Brunner-Williams
Panasas, Inc.
February 22, 2006
Using DNS SRV to Specify a Global File Name Space with NFS version 4
draft-everhart-nfsv4-namespace-via-dns-srv-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The NFS version 4 protocol provides a natural way for a collection of
NFS file servers to collaborate in providing an organization-wide
file name space. The DNS SRV RR allows a simple and appropriate way
Everhart, et al. Expires August 26, 2006 [Page 1]
Internet-Draft NFSv4 Global Name Space with DNS SRV February 2006
for an organization to publish the root of its name space, even to
clients that might not be intimately associated with such an
organization. DNS SRV can be used to join these organization-wide
file name spaces together to allow construction of a global, uniform
NFS version 4 file name space.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Proposed Use of SRV Resource Record in DNS . . . . . . . . . . 5
4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 6
4.1. Globally-useful names: conventional mount point . . . . . 6
4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 7
5. Where is this integration carried out? . . . . . . . . . . . . 8
6. Relationship to DNS NFS4ID RR . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Everhart, et al. Expires August 26, 2006 [Page 2]
Internet-Draft NFSv4 Global Name Space with DNS SRV February 2006
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].
Everhart, et al. Expires August 26, 2006 [Page 3]
Internet-Draft NFSv4 Global Name Space with DNS SRV February 2006
2. Background
With the advent of fs_locations attributes in the NFS Version 4
protocol [RFC3530], NFS servers can cooperative to build a file name
space that crosses server boundaries, as detailed in the description
of referrals in [NB0510]. With NFS Version 4 referrals, a file
server may indicate to its client that the file system name tree
beneath a given name in the server is not present on itself, but is
represented by a filesystem in some other set of servers. The
mechanism is general, allowing servers to describe any filesystem as
being reachable by requests to any of a set of servers.
Thus, given one NFS Version 4 server, an NFS Version 4 client might
be able to see a large name space associated with a collection of
interrelated NFS Version 4 file servers.
Given this ability for organizations to construct file name spaces,
some organizations may wish to advertise a starting point for clients
to use in the navigation of the name spaces. In some cases, the
organizations may wish to advertise this starting point (the root of
the organization's file system name space) to a broad set of possible
clients. At the same time, it is useful to require clients to know
only the smallest amount of information in order to begin to locate
the appropriate name space. Simultaneously, that required
information should be constant through the life of an organization if
the clients are not to require reconfiguration as administrative
events change, for instance, a server's name or address.
Everhart, et al. Expires August 26, 2006 [Page 4]
Internet-Draft NFSv4 Global Name Space with DNS SRV February 2006
3. Proposed Use of SRV Resource Record in DNS
Providing an organization's published file system name space is a
service, and it is appropriate to use the DNS [RFC1035] to locate it.
As with the AFSDB resource record type in RFC 1183, the client need
only utter the (relatively) constant domain name for an organization
in order to locate its file system name space service. Once a client
uses the DNS to locate one or more servers for the root of the
organization's name space, it can use the standard NFS Version 4
mechanisms to navigate the remainder of the NFS servers for that
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 file system name space published
by that organization.
We propose the use of the DNS SRV resource record type [RFC2782] to
fulfill this function. The format of the DNS SRV record is as
follows:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
In our case, the protocol need not be given, so we elide it and utter
only the Service name. The Target fields give the domain names of
the NFS Version 4 servers that export root filesystems. An NFS
Version 4 client SHOULD interpret any of the exported pseudo-root
filesystems as the filesystem published by the organization with the
given domain name.
Suppose a client wished to locate the root of the file system
published by organization example.com. The DNS servers for the
domain could publish records like
_nfsv4 IN SRV 0 0 2049 nfs1tr.example.com
_nfsv4 IN SRV 1 0 2049 nfs2ex.example.com
The result domain names nfs1tr.example.com and nfs2ex.example.com
indicate NFS Version 4 file servers that export the root of the
published name space for the example.com domain. In accordance with
RFC 2782, these records are to be interpreted using the Priority and
Weight field values, selecting an appropriate file server with which
to begin a network conversation. Subsequent accesses are carried out
in accordance with ordinary NFS Version 4 protocol.
Everhart, et al. Expires August 26, 2006 [Page 5]
Internet-Draft NFSv4 Global Name Space with DNS SRV February 2006
4. Integration with Use of NFS Version 4
There are at least two remaining questions: whether this DNS SRV
record evaluation is done in the NFS server or client, and also how
the domain names of the organizations are passed to client or server.
A third question is whether how this might produce a uniform global
file name space, and what prefix should be used for such file names.
This specification anticipates that these SRV records will most
commonly be used to define the second directory level in an inter-
organizational file name space. This directory will be populated
principally with domain names pointing to the file systems published
for use under those domain names. Thus, the root directory for the
file system published by example.com will effectively be mounted
underneath the example.com name in a second-level directory.
Arguably, clients intimately associated with the example.com
organization, as well as clients without prior association, SHOULD be
able to refer to files in the example.com published name space with
the example.com/ (or example.com\) prefix, thus allowing greater
sharing of published content across organizational boundaries.
Ideally, also, the client should represent the '..' entry of the
published root filesystem as the full example.com directory name, so
that 'getcwd' and similar functions might display a content name that
would be usable inside and outside the organization.
Thus, a domain name will appear to a client as a directory name
pointing to the root directory of the file system published by the
organization responsible for that domain name. Symbolic links, and
other DNS navigational artifacts like case-folding, might appear to
the client as relative symbolic names in that directory, pointing to
the case-folded full domain name under which the published file
system is mounted.
4.1. Globally-useful names: conventional mount point
For the inter-organizational name space to be a global name space, it
may be useful for its mount point in local systems to be uniform as
well. We suggest mounting it as /nfs4/ so that names on one machine
will be directly usable on any machine. Thus, the example.com
published file system would be accessible as
/nfs4/example.com/
on any client. Using this convention, "/nfs4/" is a mount for a
special file system that is populated with the results of SRV record
lookups. This is the convention that we will observe in examples in
the current document.
Everhart, et al. Expires August 26, 2006 [Page 6]
Internet-Draft NFSv4 Global Name Space with DNS SRV February 2006
4.2. Mount options
SRV records are necessarily less complete than the information in the
existing NFS Version 4 attributes fs_locations and location_info.
For the rootpath field of fs_location, we assume that the empty
string is adequate. Thus, the servers listed as targets for the SRV
resource records should export the root of the organization's
published file system as the pseudo-root in its exported namespace.
As for the other attributes in location_info, the recommended
approach is for a client to make its first possible contact with any
of the referred-to servers, obtain the location_info structure from
that server, and use the information from that obtained structure as
the basis for its judgment of whether it would be better to use a
different server representative from the set of servers for that
filesystem.
We recommend, though, that the process of mounting an organization's
name space should permit the use of what is likely to impose the
lowest cost on the server. Thus, we suggest that the client not
insist on using a writable copy of the filesystem if read-only copies
exist, or a zero-age copy rather than a copy that may be a little
older. We presume that the organization's file name space can be
navigated to provide access to higher-cost properties such as
writability or currency as necessary, but that the default use when
navigating to the base information for an organization ought to be as
low-overhead as possible.
One extension of this rule that we might choose to inherit from AFS,
though, is to give a special meaning to the domain name of an
organization preceded by a period ("."). It might be reasonable to
have names mounting the filesystem for a period-prefixed domain name
(e.g., ".example.com") attempt to mount only a read-write instance of
that organization's root filesystem, rather than permitting the use
of read-only instances of that filesystem. Thus,
/nfs4/example.com/users
might be a directory in a read-only instance of the root filesystem
of the organization "example.com", while
/nfs4/.example.com/users
would be a writable form of that same directory. A small benefit of
following this convention is that names with the period prefix are
treated as "hidden" in many operating systems, so that the visible
name remains the lowest-overhead name.
Everhart, et al. Expires August 26, 2006 [Page 7]
Internet-Draft NFSv4 Global Name Space with DNS SRV February 2006
5. Where is this integration carried out?
Another consideration is what agent should be responsible for
interpreting the SRV records. It could be done just as well on the
client or on the server, and this specification takes no position.
Using something like Automounter [AMT] technology, the client might
be responsible for interpreting names under a given directory,
discovering the appropriate filesystem to mount, and mounting it in
the appropriate place in the client name space before returning
control to the application doing a lookup. Alternatively, one could
imagine the existence of an NFS version 4 server that awaited similar
domain-name lookups, then consulted the DNS SRV records to determine
the servers for the indicated published file system, then returned
that information via NFS Version 4 attributes as a referral in the
way outlined by Noveck and Burnett [NB0510]. The server would likely
cache the DNS results (obeying TTL) so that it could return the
results more quickly the next time.
Everhart, et al. Expires August 26, 2006 [Page 8]
Internet-Draft NFSv4 Global Name Space with DNS SRV February 2006
6. Relationship to DNS NFS4ID RR
This DNS use has no obvious relationship to the NFS4ID RR. The
NFS4ID RR is a mechanism to help clients and servers configure
themselves with respect to the domain strings used in "who" strings
in ACL entries and in owner and group names. The authentication/
authorization domain string of a server need have no direct
relationship to the name of the organization that is publishing a
file name space of which this server's filesystems form a part. At
the same time, it might be seen as straightforward or normal for such
a server to refer to the ownership of most of its files using a
domain string with an evident relationship to that NFS4ID-given
domain name, but this document imposes no such requirement.
Everhart, et al. Expires August 26, 2006 [Page 9]
Internet-Draft NFSv4 Global Name Space with DNS SRV February 2006
7. Security Considerations
Naive use of the DNS may effectively give clients published server
referrals that are intrusive substitutes for the servers intended by
domain administrators.
It may be possible to build a trust chain by using DNSSEC [RFC4033]
to implement this function on the client, or by implementing this
function on an NFS Version 4 server that uses DNSSEC and maintaining
a trust relationship with that server. This trust chain also breaks
if the SRV interpreter accepts responses from insecure DNS zones.
Thus, it would likely be prudent also to use domain-based service
principal names for the servers for the root filesystems as indicated
as the targets of the SRV records.
The idea is that you want to authenticate {nfs, domainname,
host.fqdn}, not {nfs, host.fqdn} when the server is a domain root
server obtained through an insecure DNS SRV RR lookup. Then the
domain administrator could ensure that only domain root NFSv4 servers
have credentials for such domain-based service principal names.
Domain-based service principal names are being proposed in the KITTEN
WG [KITTEN].
8. Normative References
[RFC1035] Mockapetris, P., "Domain Names - Implementation And
Specification," RFC 1035, November 1987.
[RFC2782] Golbrandsen, A. et al., "A DNS RR for specifying the
location of services (DNS SRV)," RFC 2782, February 2000.
[RFC3530] Shepler, S. et al., "Network File System (NFS) version 4
Protocol," RFC 3530, April 2003.
Everhart, et al. Expires August 26, 2006 [Page 10]
Internet-Draft NFSv4 Global Name Space with DNS SRV February 2006
9. Informative References
[AFS] Howard, J. et al., "An Overview of the Andrew File
System," in Proc. USENIX Winter Tech. Conf., Dallas,
February 1988.
[AMT] Pendry, J.-S. and N. Williams, "Amd: The 4.4 BSD
Automounter Reference Manual," Imperial College, London,
March 1991.
Also: http://docs.freebsd.org/info/amdref/amdref.pdf
[DFS] Kazar, M. L. et al., "DEcorum File System Architectural
Overview," in Proc. USENIX Summer Conf., Anaheim, Calif.,
June 1990.
[KITTEN] IETF working group, GSS-API Next Generation, reference
http://ietf.org/html.charters/kitten-charter.html, October
2005.
[NB0510] Noveck, D., and C. Burnett, "Next Steps for NFSv4
Migration/Replication," Internet Draft
draft-noveck-nfsv4-migrep-00.txt, October 2005.
[RFC1183] Everhart, C. et al., "New DNS RR Definitions," RFC 1183,
October 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, P. et al., "DNS Security Introduction and
Requirements," RFC 4033, March 2005.
Everhart, et al. Expires August 26, 2006 [Page 11]
Internet-Draft NFSv4 Global Name Space with DNS SRV February 2006
Authors' Addresses
Craig Everhart
Network Appliance, Inc.
7301 Kit Creek Road
P.O. Box 13917
Research Triangle Park, NC 27709
US
Phone: +1 919 476 5320
Email: everhart@netapp.com
Andy Adamson
CITI, University of Michigan
CITI, 3rd Floor Argus
535 W. William Street
Ann Arbor, MI 48103
US
Phone: +1 734 764 9465
Email: andros@umich.edu
Jiaying Zhang
University of Michigan
535 W. William Street, Suite 3100
Ann Arbor, MI 48103
US
Phone: +1 734 647 4216
Email: jiajingz@umich.edu
Eric Brunner-Williams
Panasas, Inc.
1501 Reedsdale Street
Suite 400
Pittsburgh, PA 15233-2341
US
Phone: +1 412 323 6408
Email: ebw@panasas.com
Everhart, et al. Expires August 26, 2006 [Page 12]
Internet-Draft NFSv4 Global Name Space with DNS SRV February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Everhart, et al. Expires August 26, 2006 [Page 13]