draft-ietf-nfsv4-federated-fs-dns-srv-namespace-04.txt   draft-ietf-nfsv4-federated-fs-dns-srv-namespace-05.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: November 26, 2010 J. Zhang Expires: February 27, 2011 J. Zhang
Google Google
May 25, 2010 August 26, 2010
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-04.txt draft-ietf-nfsv4-federated-fs-dns-srv-namespace-05.txt
Abstract Abstract
The NFS version 4 protocol provides a natural way for a collection of The NFS version 4 protocol provides a natural way 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 name space, even to
clients that might not be intimately associated with such an clients that might not be intimately associated with such an
organization. The DNS SRV RR can be used to join these organization- organization. The DNS SRV RR can be used to join these organization-
wide file name spaces together to allow construction of a global, wide file name spaces together to allow construction of a global,
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 26, 2010. This Internet-Draft will expire on February 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 15 skipping to change at page 3, line 15
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. Proposed 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
5. Where is this integration carried out? . . . . . . . . . . . . 8 5. Where is this integration carried out? . . . . . . . . . . . . 8
6. Relationship to DNS NFS4ID RR . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
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
With the advent of fs_locations attributes in the NFS Version 4 The NFS Version 4 protocol [RFC3530] introduced the fs_locations
protocol [RFC3530], NFS servers can cooperate to build a file name attribute. Its use was elaborated further in the NFS Version 4 Minor
space that crosses server boundaries, as detailed in the description Version 1 protocol [RFC5661], which also defined an extended version
of referrals in [NB0510] and as further developed in the NFS Version of the attribute as fs_locations_info. With the advent of these
4 Minor Version 1 protocol [RFC5661]. With NFS Version 4 referrals, attributes, NFS servers can cooperate to build a file name space that
a file server may indicate to its client that the file name tree crosses server boundaries. The fs_locations and fs_locations_info
beneath a given name in the server is not present on itself, but is attributes are used as referrals, so that a file server may indicate
represented by a filesystem in some other set of servers. The to its client that the file name tree beneath a given name in the
mechanism is general, allowing servers to describe any filesystem as server is not present on itself, but is represented by a filesystem
being reachable by requests to any of a set of servers. Thus, in some other set of servers. The mechanism is general, allowing
starting with a single NFS Version 4 server, using these referrals, servers to describe any filesystem as being reachable by requests to
an NFS Version 4 client might be able to see a large name space any of a set of servers. Thus, starting with a single NFS Version 4
associated with a collection of interrelated NFS Version 4 file server, using these referrals, an NFS Version 4 client might be able
servers. An organization could use this capability to construct a to see a large name space associated with a collection of
uniform file name space for itself. interrelated NFS Version 4 file servers. An 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.
skipping to change at page 5, line 16 skipping to change at page 5, line 16
organization in order to locate the filesystem name space published organization in order to locate the filesystem name space published
by that organization. by that organization.
We propose the use of the DNS SRV resource record type [RFC2782] to 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 fulfill this function. The format of the DNS SRV record is as
follows: 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 In our case, we use a Service name of "_nfs4._domainroot" and a
conventional Protocol of "_tcp". (In accordance with RFC 2782 conventional Protocol of "_tcp". The Target fields give the domain
[RFC2782], we use "_" prefix characters on the Service and Protocol names of the NFS Version 4 servers that export filesystems for the
names, but we recognize that there is work in progress [Gudmundsson] domain's root. An NFS Version 4 client SHOULD interpret any of the
to create a registry of these names and to no longer use the "_" exported root filesystems as the filesystem published by the
prefix for some names.) The Target fields give the domain names of organization with the given domain name.
the NFS Version 4 servers that export filesystems for the domain's
root. An NFS Version 4 client SHOULD 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 SHOULD 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 could publish records like
skipping to change at page 9, line 25 skipping to change at page 9, line 22
their SRV lookups for them, we feel that such a requirement would their SRV lookups for them, we feel that such a requirement would
impose unusual dependencies and vulnerabilities for the deployers of impose unusual dependencies and vulnerabilities for the deployers of
such clients. Yet even if it is desirable to deploy this such clients. Yet even if it is desirable to deploy this
functionality on the NFS client side, it may be valuable as a functionality on the NFS client side, it may be valuable as a
transition aid for a site to be able to deploy it on the NFS server transition aid for a site to be able to deploy it on the NFS server
side: it may be easier for them to install it on special NFS servers side: it may be easier for them to install it on special NFS servers
rather than install it on all their NFS clients. Thus, from an rather than install it on all their NFS clients. Thus, from an
implementation standpoint, NFS clients SHOULD implement the implementation standpoint, NFS clients SHOULD implement the
functionality, and NFS servers MAY implement it. functionality, and NFS servers MAY implement it.
6. Relationship to DNS NFS4ID RR 6. Security Considerations
This DNS use has no obvious relationship to the NFS4ID RR [Mesta].
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.
7. Security Considerations
Naive use of the DNS may effectively give clients published server Naive use of the DNS may effectively give clients published server
referrals that are intrusive substitutes for the servers intended by referrals that are intrusive substitutes for the servers intended by
domain administrators. domain administrators.
It may be possible to build a trust chain by using DNSSEC [RFC4033] It may be possible to build a trust chain by using DNSSEC [RFC4033]
to implement this function on the client, or by implementing this to implement this function on the client, or by implementing this
function on an NFS Version 4 server that uses DNSSEC and maintaining function on an NFS Version 4 server that uses DNSSEC and maintaining
a trust relationship with that server. This trust chain also breaks a trust relationship with that server. This trust chain also breaks
if the SRV interpreter accepts responses from insecure DNS zones. if the SRV interpreter accepts responses from insecure DNS zones.
skipping to change at page 10, line 33 skipping to change at page 10, line 14
GSS-API should be used with the name-type of GSS-API should be used with the name-type of
GSS_C_NT_DOMAINBASED_SERVICE defined in RFC 5178 and with a symbolic GSS_C_NT_DOMAINBASED_SERVICE defined in RFC 5178 and with a symbolic
name of 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.
8. IANA Considerations 7. IANA Considerations
This document does not raise actions for IANA, but it may require None.
cosmetic changes if the in-progress work in the Gudmundsson/Hoenes
draft [Gudmundsson] is adopted.
9. References 8. References
9.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.
[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", March 1997.
skipping to change at page 11, line 31 skipping to change at page 11, line 11
[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.
9.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 [AMD] 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>.
[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.
[Gudmundsson]
Gudmundsson, O. and A. Hoenes, "Creation of a Registry for
DNS SRV Record Service Prefixes", October 2009, <ftp://
ftp.rfc-editor.org/in-notes/internet-drafts/
draft-gudmundsson-dns-srv-iana-registry-04.txt>.
[Mesta] Mesta, R., "A DNS RR for NFSv4 ID Domains", October 2005,
<http://tools.ietf.org/id/draft-ietf-nfsv4-dns-rr-00.txt>.
[NB0510] Noveck, D. and R. Burnett, "Next Steps for NFSv4
Migration/Replication", October 2005, <ftp://www.ietf.org/
internet-drafts/draft-noveck-nfsv4-migrep-00.txt>.
[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P.
Mockapetris, "New DNS RR Definitions", RFC 1183, Mockapetris, "New DNS RR Definitions", RFC 1183,
October 1990. 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
 End of changes. 14 change blocks. 
70 lines changed or deleted 37 lines changed or added

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