idnits 2.17.1 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (March 30, 2010) is 5141 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) 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: October 1, 2010 J. Zhang 6 Google 7 March 30, 2010 9 Using DNS SRV to Specify a Global File Name Space with NFS version 4 10 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-03.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 to IETF 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), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 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 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on October 1, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 76 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 3. Proposed Use of SRV Resource Record in DNS . . . . . . . . . . 3 78 4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 5 79 4.1. Globally-useful names: conventional mount point . . . . . 5 80 4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 5 81 4.3. Filesystem integration issues . . . . . . . . . . . . . . 7 82 5. Where is this integration carried out? . . . . . . . . . . . . 7 83 6. Relationship to DNS NFS4ID RR . . . . . . . . . . . . . . . . 8 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 91 1. Requirements notation 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Background 99 With the advent of fs_locations attributes in the NFS Version 4 100 protocol [RFC3530], NFS servers can cooperate to build a file name 101 space that crosses server boundaries, as detailed in the description 102 of referrals in [NB0510]. With NFS Version 4 referrals, a file 103 server may indicate to its client that the file name tree beneath a 104 given name in the server is not present on itself, but is represented 105 by a filesystem in some other set of servers. The mechanism is 106 general, allowing servers to describe any filesystem as being 107 reachable by requests to any of a set of servers. Thus, starting 108 with a single NFS Version 4 server, using these referrals, an NFS 109 Version 4 client might be able to see a large name space associated 110 with a collection of interrelated NFS Version 4 file servers. An 111 organization could use this capability to construct a uniform file 112 name space for itself. 114 An organization might wish to publish the starting point for this 115 name space to its clients. In many cases, the organization will want 116 to publish this starting point to a broader set of possible clients. 117 At the same time, it is useful to require clients to know only the 118 smallest amount of information in order to locate the appropriate 119 name space. Simultaneously, that required information should be 120 constant through the life of an organization if the clients are not 121 to require reconfiguration as administrative events change, for 122 instance, a server's name or address. 124 3. Proposed Use of SRV Resource Record in DNS 126 Providing an organization's published filesystem name space is a 127 service, and it is appropriate to use the DNS [RFC1034][RFC1035] to 128 locate it. As with the AFSDB resource record type [RFC1183], the 129 client need only utter the (relatively) constant domain name for an 130 organization in order to locate its filesystem name space service. 131 Once a client uses the DNS to locate one or more servers for the root 132 of the organization's name space, it can use the standard NFS Version 133 4 mechanisms to navigate the remainder of the NFS servers for that 134 organization. The use of this proposed mechanism results in a useful 135 cross-organizational name space, just as in AFS [AFS] and DCE/DFS 136 [DFS] before it. A client need know only the name of the 137 organization in order to locate the filesystem name space published 138 by that organization. 140 We propose the use of the DNS SRV resource record type [RFC2782] to 141 fulfill this function. The format of the DNS SRV record is as 142 follows: 144 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 146 In our case, we use a Service name of "_nfs4._domainroot" and a 147 conventional Protocol of "_tcp". (In accordance with RFC 2782 148 [RFC2782], we use "_" prefix characters on the Service and Protocol 149 names, but we recognize that there is work in progress [Gudmundsson] 150 to create a registry of these names and to no longer use the "_" 151 prefix for some names.) The Target fields give the domain names of 152 the NFS Version 4 servers that export filesystems for the domain's 153 root. An NFS Version 4 client SHOULD interpret any of the exported 154 root filesystems as the filesystem published by the organization with 155 the given domain name. 157 In order to allow the NFSv4 servers so given to export a variety of 158 filesystems, those file servers SHOULD export the given domain's root 159 filesystems at "/.domainroot-{Name}" within their pseudo-filesystems, 160 where the "{Name}" is the name of the organization as used in the SRV 161 RR. 163 As an example, suppose a client wished to locate the root of the 164 filesystem published by organization example.net. The DNS servers 165 for the domain could publish records like 167 $ORIGIN example.net. 168 _nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. 169 _nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net. 171 The result domain names nfs1tr.example.net and nfs2ex.example.net 172 indicate NFS Version 4 file servers that export the root of the 173 published name space for the example.net domain. In accordance with 174 RFC 2782 [RFC2782], these records are to be interpreted using the 175 Priority and Weight field values, selecting an appropriate file 176 server with which to begin a network conversation. The two file 177 servers would export filesystems that would be found at 178 "/.domainroot-example.net" in their pseudo-filesystems, which clients 179 would mount. Clients then carry out subsequent accesses in 180 accordance with the ordinary NFS Version 4 protocol. 182 We use a composite Service name (built from "_nfs4" and 183 "_domainroot") so that other filesystem protocols could make use of 184 the same "_domainroot" abstraction. 186 4. Integration with Use of NFS Version 4 188 We expect that NFSv4 clients will implement a special directory, 189 analogous to an Automounter [AMD] directory, the entries in which are 190 domain names that have recently been traversed. When an application 191 attempts to traverse a new name in that special directory, the NFSv4 192 client consults DNS to obtain the SRV data for the given name, and if 193 successful, it mounts the indicated filesystem(s) in that name in the 194 special directory. The goal is that NFSv4 applications will be able 195 to lookup an organization's domain name in the special directory, and 196 the NFSv4 client will be able to discover the filesystem that that 197 organization publishes. Entries in the special directory will be 198 domain names, and they will each appear to the application as a 199 directory name pointing to the root directory of the filesystem 200 published by the organization responsible for that domain name. 202 This functionality does not require or use any list of organizations 203 that are known to provide file service, as AFS did with its 204 "root.afs" functionality. 206 This DNS SRV record evaluation could, in principle, be done either in 207 the NFSv4 client or in an NFSv4 server. In either case, the result 208 would appear the same to applications on the NFSv4 client. 210 4.1. Globally-useful names: conventional mount point 212 For the inter-organizational name space to be a global name space, it 213 is useful for its mount point in local systems to be uniform as well. 214 On POSIX machines, the name /nfs4/ SHOULD be used so that names on 215 one machine will be directly usable on any machine. Thus, the 216 example.net published filesystem would be accessible as 218 /nfs4/example.net/ 220 on any POSIX client. Using this convention, "/nfs4/" is the name of 221 the special directory that is populated with domain names, leading to 222 file servers and filesystems that capture the results of SRV record 223 lookups. 225 4.2. Mount options 227 SRV records are necessarily less complete than the information in the 228 existing NFS Version 4 attributes fs_locations and the proposed 229 fs_locations_info. For the rootpath field of fs_location, as 230 mentioned, we use the "/.domainroot-{Name}" string. Thus, the 231 servers listed as targets for the SRV resource records should export 232 the root of the organization's published filesystem as the directory 233 "/.domainroot-{Name}" (for the given organization Name) in its 234 exported namespace. For example, for organization "example.net", the 235 directory "/.domainroot-example.net" should be used. 237 As for the other attributes in fs_locations_info, the recommended 238 approach is for a client to make its first possible contact with any 239 of the referred-to servers, obtain the fs_locations_info structure 240 from that server, and use the information from that obtained 241 structure as the basis for its judgment of whether it would be better 242 to use a different server representative from the set of servers for 243 that filesystem. 245 The process of mounting an organization's name space should permit 246 the use of what is likely to impose the lowest cost on the server. 247 Thus, the NFS client SHOULD NOT insist on using a writable copy of 248 the filesystem if read-only copies exist, or a zero-age copy rather 249 than a copy that may be a little older. We presume that the 250 organization's file name space can be navigated to provide access to 251 higher-cost properties such as writability or currency as necessary, 252 but that the default use when navigating to the base information for 253 an organization ought to be as low-overhead as possible. 255 Because of the possible distinction between read-only and read-write 256 versions of a filesystem, organizations SHOULD also publish the 257 location of a writable instance of their root filesystems, and that 258 NFSv4 clients SHOULD mount that filesystem under the organizational 259 domain name preceded by a period ("."). Therefore, when names 260 beginning with a period are looked up under the NFSv4 client's 261 special directory, the SRV RR looked up in DNS uses a Service name of 262 "_nfs4._write._domainroot", and the indicated server (or servers) 263 SHOULD export the writable instance at "/.domainroot-write-{Name}" 264 for a domain name Name. 266 Extending the opening example, suppose a client wished to locate the 267 read-only and read-write roots of the filesystem published by 268 organization example.net. Suppose a read-write instance were hosted 269 on server nfs1tr.example.net, and read-only instances were on that 270 server and also on server nfs2ex.example.net. The DNS servers for 271 the domain would publish records like 273 $ORIGIN example.net. 274 _nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. 275 _nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net. 276 _nfs4._write._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. 278 The nfs1tr.example.net server would export filesystems at both 279 "/.domainroot-example.net" (the read-only instance) and 280 "/.domainroot-write-example.net" (the read-write instance). The 281 nfs2ex.example.net server need export only the "/.domainroot- 282 example.net" name for its read-only instance. 284 The read-write version of the filesystem would be mounted (upon use) 285 under ".example.net" in the special directory, and a read-only 286 version would be mounted under "example.net". Thus, 288 /nfs4/example.net/users 290 might be a directory in a read-only instance of the root filesystem 291 of the organization "example.net", while 293 /nfs4/.example.net/users 295 would be a writable form of that same directory. A small benefit of 296 following this convention is that names with the period prefix are 297 treated as "hidden" in many operating systems, so that the visible 298 name remains the lowest-overhead name. 300 4.3. Filesystem integration issues 302 The result of the DNS search SHOULD appear as a (pseudo-)directory in 303 the client name space. A further refinement is advisable, and SHOULD 304 be deployed: that only fully-qualified domain names appear as 305 directories. That is, in many environments, DNS names may be 306 abbreviated from their fully-qualified form. In such circumstances, 307 multiple names might be given to filesystem code that all resolve to 308 the same DNS SRV RRs. The abbreviated form SHOULD be represented in 309 the client's name space cache as a symbolic link, pointing to the 310 fully-qualified name, case-canonicalized when appropriate. This will 311 allow pathnames obtained with, say, getcwd() to include the DNS name 312 that is most likely to be usable outside the scope of any particular 313 DNS abbreviation convention. 315 5. Where is this integration carried out? 317 Another consideration is what agent should be responsible for 318 interpreting the SRV records. It could be done just as well by the 319 NFS client or by the NFS server, though we expect that most clients 320 will include this function themselves. Using something like 321 Automounter [AMD] technology, the client would be responsible for 322 interpreting names under a particular directory, discovering the 323 appropriate filesystem to mount, and mounting it in the appropriate 324 place in the client name space before returning control to the 325 application doing a lookup. Alternatively, one could imagine the 326 existence of an NFS version 4 server that awaited similar domain-name 327 lookups, then consulted the SRV records in DNS to determine the 328 servers for the indicated published filesystem, and then returned 329 that information as an NFS Version 4 referral. In either case, the 330 result of the DNS lookup should be cached (obeying TTL) so that the 331 result could be returned more quickly the next time. 333 We strongly suggest that this functionality be implemented by NFS 334 clients. While we recognize that it would be possible to configure 335 clients so that they relied on a specially-configured server to do 336 their SRV lookups for them, we feel that such a requirement would 337 impose unusual dependencies and vulnerabilities for the deployers of 338 such clients. Yet even if it is desirable to deploy this 339 functionality on the NFS client side, it may be valuable as a 340 transition aid for a site to be able to deploy it on the NFS server 341 side: it may be easier for them to install it on special NFS servers 342 rather than install it on all their NFS clients. Thus, from an 343 implementation standpoint, NFS clients SHOULD implement the 344 functionality, and NFS servers MAY implement it. 346 6. Relationship to DNS NFS4ID RR 348 This DNS use has no obvious relationship to the NFS4ID RR. The 349 NFS4ID RR is a mechanism to help clients and servers configure 350 themselves with respect to the domain strings used in "who" strings 351 in ACL entries and in owner and group names. The authentication/ 352 authorization domain string of a server need have no direct 353 relationship to the name of the organization that is publishing a 354 file name space of which this server's filesystems form a part. At 355 the same time, it might be seen as straightforward or normal for such 356 a server to refer to the ownership of most of its files using a 357 domain string with an evident relationship to that NFS4ID-given 358 domain name, but this document imposes no such requirement. 360 7. Security Considerations 362 Naive use of the DNS may effectively give clients published server 363 referrals that are intrusive substitutes for the servers intended by 364 domain administrators. 366 It may be possible to build a trust chain by using DNSSEC [RFC4033] 367 to implement this function on the client, or by implementing this 368 function on an NFS Version 4 server that uses DNSSEC and maintaining 369 a trust relationship with that server. This trust chain also breaks 370 if the SRV interpreter accepts responses from insecure DNS zones. 371 Thus, it would likely be prudent also to use domain-based service 372 principal names for the servers for the root filesystems as indicated 373 as the targets of the SRV records. The idea here is that one wants 374 to authenticate {nfs, domainname, host.fqdn}, not simply {nfs, 375 host.fqdn}, when the server is a domain's root file server obtained 376 through an insecure DNS SRV RR lookup. The domain administrator can 377 thus ensure that only domain root NFSv4 servers have credentials for 378 such domain-based service principal names. 380 Domain-based service principal names are defined in RFCs 5178 381 [RFC5178] and 5179 [RFC5179]. To make use of RFC 5178's domain-based 382 names, the syntax for "domain-based-name" MUST be used with a service 383 of "nfs", a domain matching the name of the organization whose root 384 filesystem is being sought, and a hostname given in the target of the 385 DNS SRV resource record. Thus, in the example above, two file 386 servers (nfs1tr.example.net and nfs2ex.example.net) are located as 387 hosting the root filesystem for the organization example.net. To 388 communicate with, for instance, the second of the given file servers, 389 GSS-API should be used with the name-type of 390 GSS_C_NT_DOMAINBASED_SERVICE defined in RFC 5178 and with a symbolic 391 name of 393 nfs@example.net@nfs2ex.example.net 395 in order to verify that the named server (nfs2ex.example.net) is 396 authorized to provide the root filesystem for the example.net 397 organization. 399 8. IANA Considerations 401 This document does not raise actions for IANA, but it may require 402 cosmetic changes if the in-progress work in the Gudmundsson/Hoenes 403 draft [Gudmundsson] is adopted. 405 9. References 407 9.1. Normative References 409 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 410 RFC 1034, November 1987. 412 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 413 Specification", RFC 1035, November 1987. 415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", March 1997. 418 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 419 specifying the location of services (DNS SRV)", RFC 2782, 420 February 2000. 422 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 423 Beame, C., Eisler, M., and D. Noveck, "Network File System 424 (NFS) version 4 Protocol", RFC 3530, April 2003. 426 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 427 Rose, "DNS Security Introduction and Requirements", 428 RFC 4033, March 2005. 430 [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service 431 Application Program Interface (GSS-API) 432 Internationalization and Domain-Based Service Names and 433 Name Type", RFC 5178, May 2008. 435 [RFC5179] Williams, N., "Generic Security Service Application 436 Program Interface (GSS-API) Domain-Based Service Names 437 Mapping for the Kerberos V GSS Mechanism", RFC 5179, 438 May 2008. 440 9.2. Informative References 442 [AFS] Howard, J., "An Overview of the Andrew File System"", 443 Proc. USENIX Winter Tech. Conf. Dallas, February 1988. 445 [AMD] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter 446 Reference Manual", March 1991, 447 . 449 [DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V., 450 Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S., 451 and E. Zayas, "DEcorum File System Architectural 452 Overview", Proc. USENIX Summer Conf. Anaheim, Calif., 453 June 1990. 455 [Gudmundsson] 456 Gudmundsson, O. and A. Hoenes, "Creation of a Registry for 457 DNS SRV Record Service Prefixes", October 2009, . 461 [NB0510] Noveck, D. and R. Burnett, "Next Steps for NFSv4 462 Migration/Replication", October 2005, . 465 [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. 466 Mockapetris, "New DNS RR Definitions", RFC 1183, 467 October 1990. 469 Authors' Addresses 471 Craig Everhart 472 NetApp 473 800 Cranberry Woods Drive, Ste. 300 474 Cranberry Township, PA 16066 475 US 477 Phone: +1 724 741 5101 478 Email: everhart@netapp.com 480 Andy Adamson 481 NetApp 482 495 East Java Drive 483 Sunnyvale, CA 94089 484 US 486 Phone: +1 734 665 1204 487 Email: andros@netapp.com 489 Jiaying Zhang 490 Google 491 604 Arizona Avenue 492 Santa Monica, CA 90401 493 US 495 Phone: +1 310 309 6884 496 Email: jiayingz@google.com