idnits 2.17.1 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2011) is 4811 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Everhart 3 Internet-Draft W. Adamson 4 Intended status: Standards Track NetApp 5 Expires: August 26, 2011 J. Zhang 6 Google 7 February 22, 2011 9 Using DNS SRV to Specify a Global File Name Space with NFS version 4 10 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-06.txt 12 Abstract 14 The NFS version 4 protocol provides a natural way for a collection of 15 NFS file servers to collaborate in providing an organization-wide 16 file name space. The DNS SRV RR allows a simple and appropriate way 17 for an organization to publish the root of its name space, even to 18 clients that might not be intimately associated with such an 19 organization. The DNS SRV RR can be used to join these organization- 20 wide file name spaces together to allow construction of a global, 21 uniform NFS version 4 file name space. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 26, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 70 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Proposed Use of SRV Resource Record in DNS . . . . . . . . . . 4 72 4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 6 73 4.1. Globally-useful names: conventional mount point . . . . . 6 74 4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 6 75 4.3. Filesystem integration issues . . . . . . . . . . . . . . 8 76 5. Where is this integration carried out? . . . . . . . . . . . . 8 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Requirements notation 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 2. Background 92 The NFS Version 4 protocol [RFC3530] introduced the fs_locations 93 attribute. Its use was elaborated further in the NFS Version 4 Minor 94 Version 1 protocol [RFC5661], which also defined an extended version 95 of the attribute as fs_locations_info. With the advent of these 96 attributes, NFS servers can cooperate to build a file name space that 97 crosses server boundaries. The fs_locations and fs_locations_info 98 attributes are used as referrals, so that a file server may indicate 99 to its client that the file name tree beneath a given name in the 100 server is not present on itself, but is represented by a filesystem 101 in some other set of servers. The mechanism is general, allowing 102 servers to describe any filesystem as being reachable by requests to 103 any of a set of servers. Thus, starting with a single NFS Version 4 104 server, using these referrals, an NFS Version 4 client might be able 105 to see a large name space associated with a collection of 106 interrelated NFS Version 4 file servers. An organization could use 107 this capability to construct a uniform file name space for itself. 109 An organization might wish to publish the starting point for this 110 name space to its clients. In many cases, the organization will want 111 to publish this starting point to a broader set of possible clients. 112 At the same time, it is useful to require clients to know only the 113 smallest amount of information in order to locate the appropriate 114 name space. Simultaneously, that required information should be 115 constant through the life of an organization if the clients are not 116 to require reconfiguration as administrative events change, for 117 instance, a server's name or address. 119 3. Proposed Use of SRV Resource Record in DNS 121 Providing an organization's published filesystem name space is a 122 service, and it is appropriate to use the DNS [RFC1034][RFC1035] to 123 locate it. As with the AFSDB resource record type [RFC1183], the 124 client need only utter the (relatively) constant domain name for an 125 organization in order to locate its filesystem name space service. 126 Once a client uses the DNS to locate one or more servers for the root 127 of the organization's name space, it can use the standard NFS Version 128 4 mechanisms to navigate the remainder of the NFS servers for that 129 organization. The use of this proposed mechanism results in a useful 130 cross-organizational name space, just as in AFS [AFS] and DCE/DFS 131 [DFS] before it. A client need know only the name of the 132 organization in order to locate the filesystem name space published 133 by that organization. 135 We propose the use of the DNS SRV resource record type [RFC2782] to 136 fulfill this function. The format of the DNS SRV record is as 137 follows: 139 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 141 In our case, we use a Service name of "_nfs4._domainroot" and a 142 conventional Protocol of "_tcp". The Target fields give the domain 143 names of the NFS Version 4 servers that export filesystems for the 144 domain's root. An NFS Version 4 client SHOULD interpret any of the 145 exported root filesystems as the filesystem published by the 146 organization with the given domain name. 148 In order to allow the NFSv4 servers so given to export a variety of 149 filesystems, those file servers SHOULD export the given domain's root 150 filesystems at "/.domainroot-{Name}" within their pseudo-filesystems, 151 where the "{Name}" is the name of the organization as used in the SRV 152 RR. 154 As an example, suppose a client wished to locate the root of the 155 filesystem published by organization example.net. The DNS servers 156 for the domain could publish records like 158 $ORIGIN example.net. 159 _nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. 160 _nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net. 162 The result domain names nfs1tr.example.net and nfs2ex.example.net 163 indicate NFS Version 4 file servers that export the root of the 164 published name space for the example.net domain. In accordance with 165 RFC 2782 [RFC2782], these records are to be interpreted using the 166 Priority and Weight field values, selecting an appropriate file 167 server with which to begin a network conversation. The two file 168 servers would export filesystems that would be found at 169 "/.domainroot-example.net" in their pseudo-filesystems, which clients 170 would mount. Clients then carry out subsequent accesses in 171 accordance with the ordinary NFS Version 4 protocol. 173 We use a composite Service name (built from "_nfs4" and 174 "_domainroot") so that other filesystem protocols could make use of 175 the same "_domainroot" abstraction. 177 4. Integration with Use of NFS Version 4 179 We expect that NFSv4 clients will implement a special directory, 180 analogous to an Automounter [AMD] directory, the entries in which are 181 domain names that have recently been traversed. When an application 182 attempts to traverse a new name in that special directory, the NFSv4 183 client consults DNS to obtain the SRV data for the given name, and if 184 successful, it mounts the indicated filesystem(s) in that name in the 185 special directory. The goal is that NFSv4 applications will be able 186 to lookup an organization's domain name in the special directory, and 187 the NFSv4 client will be able to discover the filesystem that that 188 organization publishes. Entries in the special directory will be 189 domain names, and they will each appear to the application as a 190 directory name pointing to the root directory of the filesystem 191 published by the organization responsible for that domain name. 193 This functionality does not require or use any list of organizations 194 that are known to provide file service, as AFS did with its 195 "root.afs" functionality. 197 This DNS SRV record evaluation could, in principle, be done either in 198 the NFSv4 client or in an NFSv4 server. In either case, the result 199 would appear the same to applications on the NFSv4 client. 201 4.1. Globally-useful names: conventional mount point 203 For the inter-organizational name space to be a global name space, it 204 is useful for its mount point in local systems to be uniform as well. 205 On POSIX machines, the name /nfs4/ SHOULD be used so that names on 206 one machine will< be directly usable on any machine. Thus, the 207 example.net published filesystem would be accessible as 209 /nfs4/example.net/ 211 on any POSIX client. Using this convention, "/nfs4/" is the name of 212 the special directory that is populated with domain names, leading to 213 file servers and filesystems that capture the results of SRV record 214 lookups. 216 4.2. Mount options 218 SRV records are necessarily less complete than the information in the 219 existing NFS Version 4 attributes fs_locations [RFC3530] or 220 fs_locations_info [RFC5661]. For the rootpath field of fs_location, 221 or the fli_fs_root of fs_locations_info, we use the "/.domainroot- 222 {Name}" string. Thus, the servers listed as targets for the SRV 223 resource records should export the root of the organization's 224 published filesystem as the directory "/.domainroot-{Name}" (for the 225 given organization Name) in its exported namespace. For example, for 226 organization "example.net", the directory "/.domainroot-example.net" 227 should be used. 229 As for the other attributes in fs_locations_info, the recommended 230 approach is for a client to make its first possible contact with any 231 of the referred-to servers, obtain the fs_locations_info structure 232 from that server, and use the information from that obtained 233 structure as the basis for its judgment of whether it would be better 234 to use a different server representative from the set of servers for 235 that filesystem. 237 The process of mounting an organization's name space should permit 238 the use of what is likely to impose the lowest cost on the server. 239 Thus, the NFS client SHOULD NOT insist on using a writable copy of 240 the filesystem if read-only copies exist, or a zero-age copy rather 241 than a copy that may be a little older. We presume that the 242 organization's file name space can be navigated to provide access to 243 higher-cost properties such as writability or currency as necessary, 244 but that the default use when navigating to the base information for 245 an organization ought to be as low-overhead as possible. 247 Because of the possible distinction between read-only and read-write 248 versions of a filesystem, organizations SHOULD also publish the 249 location of a writable instance of their root filesystems, and that 250 NFSv4 clients SHOULD mount that filesystem under the organizational 251 domain name preceded by a period ("."). Therefore, when names 252 beginning with a period are looked up under the NFSv4 client's 253 special directory, the SRV RR looked up in DNS uses a Service name of 254 "_nfs4._write._domainroot", and the indicated server (or servers) 255 SHOULD export the writable instance at "/.domainroot-write-{Name}" 256 for a domain name Name. 258 Extending the opening example, suppose a client wished to locate the 259 read-only and read-write roots of the filesystem published by 260 organization example.net. Suppose a read-write instance were hosted 261 on server nfs1tr.example.net, and read-only instances were on that 262 server and also on server nfs2ex.example.net. The DNS servers for 263 the domain would publish records like 265 $ORIGIN example.net. 266 _nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. 267 _nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net. 268 _nfs4._write._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. 270 The nfs1tr.example.net server would export filesystems at both 271 "/.domainroot-example.net" (the read-only instance) and 272 "/.domainroot-write-example.net" (the read-write instance). The 273 nfs2ex.example.net server need export only the "/.domainroot- 274 example.net" name for its read-only instance. 276 The read-write version of the filesystem would be mounted (upon use) 277 under ".example.net" in the special directory, and a read-only 278 version would be mounted under "example.net". Thus, 280 /nfs4/example.net/users 282 might be a directory in a read-only instance of the root filesystem 283 of the organization "example.net", while 285 /nfs4/.example.net/users 287 would be a writable form of that same directory. A small benefit of 288 following this convention is that names with the period prefix are 289 treated as "hidden" in many operating systems, so that the visible 290 name remains the lowest-overhead name. 292 4.3. Filesystem integration issues 294 The result of the DNS search SHOULD appear as a (pseudo-)directory in 295 the client name space. A further refinement is advisable, and SHOULD 296 be deployed: that only fully-qualified domain names appear as 297 directories. That is, in many environments, DNS names may be 298 abbreviated from their fully-qualified form. In such circumstances, 299 multiple names might be given to filesystem code that all resolve to 300 the same DNS SRV RRs. The abbreviated form SHOULD be represented in 301 the client's name space cache as a symbolic link, pointing to the 302 fully-qualified name, case-canonicalized when appropriate. This will 303 allow pathnames obtained with, say, getcwd() to include the DNS name 304 that is most likely to be usable outside the scope of any particular 305 DNS abbreviation convention. 307 5. Where is this integration carried out? 309 Another consideration is what agent should be responsible for 310 interpreting the SRV records. It could be done just as well by the 311 NFS client or by the NFS server, though we expect that most clients 312 will include this function themselves. Using something like 313 Automounter [AMD] technology, the client would be responsible for 314 interpreting names under a particular directory, discovering the 315 appropriate filesystem to mount, and mounting it in the appropriate 316 place in the client name space before returning control to the 317 application doing a lookup. Alternatively, one could imagine the 318 existence of an NFS version 4 server that awaited similar domain-name 319 lookups, then consulted the SRV records in DNS to determine the 320 servers for the indicated published filesystem, and then returned 321 that information as an NFS Version 4 referral. In either case, the 322 result of the DNS lookup should be cached (obeying TTL) so that the 323 result could be returned more quickly the next time. 325 We strongly suggest that this functionality be implemented by NFS 326 clients. While we recognize that it would be possible to configure 327 clients so that they relied on a specially-configured server to do 328 their SRV lookups for them, we feel that such a requirement would 329 impose unusual dependencies and vulnerabilities for the deployers of 330 such clients. Yet even if it is desirable to deploy this 331 functionality on the NFS client side, it may be valuable as a 332 transition aid for a site to be able to deploy it on the NFS server 333 side: it may be easier for them to install it on special NFS servers 334 rather than install it on all their NFS clients. Thus, from an 335 implementation standpoint, NFS clients SHOULD implement the 336 functionality, and NFS servers MAY implement it. 338 6. Security Considerations 340 Naive use of the DNS may effectively give clients published server 341 referrals that are intrusive substitutes for the servers intended by 342 domain administrators. 344 It may be possible to build a trust chain by using DNSSEC [RFC4033] 345 to implement this function on the client, or by implementing this 346 function on an NFS Version 4 server that uses DNSSEC and maintaining 347 a trust relationship with that server. This trust chain also breaks 348 if the SRV interpreter accepts responses from insecure DNS zones. 349 Thus, it would likely be prudent also to use domain-based service 350 principal names for the servers for the root filesystems as indicated 351 as the targets of the SRV records. The idea here is that one wants 352 to authenticate {nfs, domainname, host.fqdn}, not simply {nfs, 353 host.fqdn}, when the server is a domain's root file server obtained 354 through an insecure DNS SRV RR lookup. The domain administrator can 355 thus ensure that only domain root NFSv4 servers have credentials for 356 such domain-based service principal names. 358 Domain-based service principal names are defined in RFCs 5178 359 [RFC5178] and 5179 [RFC5179]. To make use of RFC 5178's domain-based 360 names, the syntax for "domain-based-name" MUST be used with a service 361 of "nfs", a domain matching the name of the organization whose root 362 filesystem is being sought, and a hostname given in the target of the 363 DNS SRV resource record. Thus, in the example above, two file 364 servers (nfs1tr.example.net and nfs2ex.example.net) are located as 365 hosting the root filesystem for the organization example.net. To 366 communicate with, for instance, the second of the given file servers, 367 GSS-API should be used with the name-type of 368 GSS_C_NT_DOMAINBASED_SERVICE defined in RFC 5178 and with a symbolic 369 name of 371 nfs@example.net@nfs2ex.example.net 373 in order to verify that the named server (nfs2ex.example.net) is 374 authorized to provide the root filesystem for the example.net 375 organization. 377 7. IANA Considerations 379 None. 381 8. References 383 8.1. Normative References 385 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 386 RFC 1034, November 1987. 388 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 389 Specification", RFC 1035, November 1987. 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", March 1997. 394 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 395 specifying the location of services (DNS SRV)", RFC 2782, 396 February 2000. 398 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 399 Beame, C., Eisler, M., and D. Noveck, "Network File System 400 (NFS) version 4 Protocol", RFC 3530, April 2003. 402 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 403 Rose, "DNS Security Introduction and Requirements", 404 RFC 4033, March 2005. 406 [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service 407 Application Program Interface (GSS-API) 408 Internationalization and Domain-Based Service Names and 409 Name Type", RFC 5178, May 2008. 411 [RFC5179] Williams, N., "Generic Security Service Application 412 Program Interface (GSS-API) Domain-Based Service Names 413 Mapping for the Kerberos V GSS Mechanism", RFC 5179, 414 May 2008. 416 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, Editors, "Network 417 File System (NFS) Version 4 Minor Version 1 Protocol", 418 RFC 5661, January 2010. 420 8.2. Informative References 422 [AFS] Howard, J., "An Overview of the Andrew File System"", 423 Proc. USENIX Winter Tech. Conf. Dallas, February 1988. 425 [AMD] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter 426 Reference Manual", March 1991, 427 . 429 [DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V., 430 Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S., 431 and E. Zayas, "DEcorum File System Architectural 432 Overview", Proc. USENIX Summer Conf. Anaheim, Calif., 433 June 1990. 435 [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. 436 Mockapetris, "New DNS RR Definitions", RFC 1183, 437 October 1990. 439 Authors' Addresses 441 Craig Everhart 442 NetApp 443 800 Cranberry Woods Drive, Ste. 300 444 Cranberry Township, PA 16066 445 US 447 Phone: +1 724 741 5101 448 Email: everhart@netapp.com 450 Andy Adamson 451 NetApp 452 495 East Java Drive 453 Sunnyvale, CA 94089 454 US 456 Phone: +1 734 665 1204 457 Email: andros@netapp.com 458 Jiaying Zhang 459 Google 460 604 Arizona Avenue 461 Santa Monica, CA 90401 462 US 464 Phone: +1 310 309 6884 465 Email: jiayingz@google.com