idnits 2.17.1 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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, 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 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5294 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) == Unused Reference: 'RFC1034' is defined on line 375, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 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: April 29, 2010 J. Zhang 6 Google 7 October 26, 2009 9 Using DNS SRV to Specify a Global File Name Space with NFS version 4 10 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 29, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 The NFS version 4 protocol provides a natural way for a collection of 49 NFS file servers to collaborate in providing an organization-wide 50 file name space. The DNS SRV RR allows a simple and appropriate way 51 for an organization to publish the root of its name space, even to 52 clients that might not be intimately associated with such an 53 organization. The DNS SRV RR can be used to join these organization- 54 wide file name spaces together to allow construction of a global, 55 uniform NFS version 4 file name space. 57 Table of Contents 59 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 60 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Proposed Use of SRV Resource Record in DNS . . . . . . . . . . 3 62 4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 4 63 4.1. Globally-useful names: conventional mount point . . . . . 5 64 4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 5 65 4.3. Filesystem integration issues . . . . . . . . . . . . . . 7 66 5. Where is this integration carried out? . . . . . . . . . . . . 7 67 6. Relationship to DNS NFS4ID RR . . . . . . . . . . . . . . . . 8 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Requirements notation 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 2. Background 82 With the advent of fs_locations attributes in the NFS Version 4 83 protocol [RFC3530], NFS servers can cooperate to build a file name 84 space that crosses server boundaries, as detailed in the description 85 of referrals in [NB0510]. With NFS Version 4 referrals, a file 86 server may indicate to its client that the file name tree beneath a 87 given name in the server is not present on itself, but is represented 88 by a filesystem in some other set of servers. The mechanism is 89 general, allowing servers to describe any filesystem as being 90 reachable by requests to any of a set of servers. Thus, starting 91 with a single NFS Version 4 server, using these referrals, an NFS 92 Version 4 client might be able to see a large name space associated 93 with a collection of interrelated NFS Version 4 file servers. An 94 organization could use this capability to construct a uniform file 95 name space for itself. 97 An organization might wish to publish the starting point for this 98 name space to its clients. In many cases, the organization will want 99 to publish this starting point to a broader set of possible clients. 100 At the same time, it is useful to require clients to know only the 101 smallest amount of information in order to locate the appropriate 102 name space. Simultaneously, that required information should be 103 constant through the life of an organization if the clients are not 104 to require reconfiguration as administrative events change, for 105 instance, a server's name or address. 107 3. Proposed Use of SRV Resource Record in DNS 109 Providing an organization's published filesystem name space is a 110 service, and it is appropriate to use the DNS [RFC1035] to locate it. 111 As with the AFSDB resource record type [RFC1183], the client need 112 only utter the (relatively) constant domain name for an organization 113 in order to locate its filesystem name space service. Once a client 114 uses the DNS to locate one or more servers for the root of the 115 organization's name space, it can use the standard NFS Version 4 116 mechanisms to navigate the remainder of the NFS servers for that 117 organization. The use of this proposed mechanism results in a useful 118 cross-organizational name space, just as in AFS [AFS] and DCE/DFS 119 [DFS] before it. A client need know only the name of the 120 organization in order to locate the filesystem name space published 121 by that organization. 123 We propose the use of the DNS SRV resource record type [RFC2782] to 124 fulfill this function. The format of the DNS SRV record is as 125 follows: 127 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 129 In our case, we use a Service name of "_nfs4._domainroot" and a 130 conventional Protocol of "_tcp". (In accordance with RFC 2782 131 [RFC2782], we use "_" prefix characters on the Service and Protocol 132 names, but we recognize that there is work in progress [Gudmundsson] 133 to create a registry of these names and to no longer use the "_" 134 prefix for some names.) The Target fields give the domain names of 135 the NFS Version 4 servers that export filesystems for the domain's 136 root. An NFS Version 4 client SHOULD interpret any of the exported 137 root filesystems as the filesystem published by the organization with 138 the given domain name. 140 In order to allow the NFSv4 servers so given to export a variety of 141 filesystems, those file servers SHOULD export the given domain's root 142 filesystems at "/.domain-root-{Name}" within their pseudo- 143 filesystems, where the "{Name}" is the name of the organization as 144 used in the SRV RR. 146 As an example, suppose a client wished to locate the root of the 147 filesystem published by organization example.net. The DNS servers 148 for the domain could publish records like 150 _nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net 151 _nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net 153 The result domain names nfs1tr.example.net and nfs2ex.example.net 154 indicate NFS Version 4 file servers that export the root of the 155 published name space for the example.net domain. In accordance with 156 RFC 2782 [RFC2782], these records are to be interpreted using the 157 Priority and Weight field values, selecting an appropriate file 158 server with which to begin a network conversation. The two file 159 servers would export filesystems that would be found at "/.domain- 160 root-example.net" in their pseudo-filesystems, which clients would 161 mount. Clients then carry out subsequent accesses in accordance with 162 the ordinary NFS Version 4 protocol. 164 4. Integration with Use of NFS Version 4 166 We expect that NFSv4 clients will implement a special directory, 167 analogous to an Automounter [AMD] directory, the entries in which are 168 domain names that have recently been traversed. When an application 169 attempts to traverse a new name in that special directory, the NFSv4 170 client consults DNS to obtain the SRV data for the given name, and if 171 successful, it mounts the indicated filesystem(s) in that name in the 172 special directory. The goal is that NFSv4 applications will be able 173 to lookup an organization's domain name in the special directory, and 174 the NFSv4 client will be able to discover the filesystem that that 175 organization publishes. Entries in the special directory will be 176 domain names, and they will each appear to the application as a 177 directory name pointing to the root directory of the filesystem 178 published by the organization responsible for that domain name. 180 This functionality does not require or use any list of organizations 181 that are known to provide file service, as AFS did with its 182 "root.afs" functionality. 184 This DNS SRV record evaluation could, in principle, be done either in 185 the NFSv4 client or in an NFSv4 server. In either case, the result 186 would appear the same to applications on the NFSv4 client. 188 4.1. Globally-useful names: conventional mount point 190 For the inter-organizational name space to be a global name space, it 191 is useful for its mount point in local systems to be uniform as well. 192 On POSIX machines, the name /nfs4/ SHOULD be used so that names on 193 one machine will be directly usable on any machine. Thus, the 194 example.net published filesystem would be accessible as 196 /nfs4/example.net/ 198 on any POSIX client. Using this convention, "/nfs4/" is the name of 199 the special directory that is populated with domain names, leading to 200 file servers and filesystems that capture the results of SRV record 201 lookups. 203 4.2. Mount options 205 SRV records are necessarily less complete than the information in the 206 existing NFS Version 4 attributes fs_locations and the proposed 207 fs_locations_info. For the rootpath field of fs_location, as 208 mentioned, we use the "/.domain-root-{Name}" string. Thus, the 209 servers listed as targets for the SRV resource records should export 210 the root of the organization's published filesystem as the directory 211 "/.domain-root-{Name}" (for the given organization Name) in its 212 exported namespace. For example, for organization "example.net", the 213 directory "/.domain-root-example.net" should be used. 215 As for the other attributes in fs_locations_info, the recommended 216 approach is for a client to make its first possible contact with any 217 of the referred-to servers, obtain the fs_locations_info structure 218 from that server, and use the information from that obtained 219 structure as the basis for its judgment of whether it would be better 220 to use a different server representative from the set of servers for 221 that filesystem. 223 The process of mounting an organization's name space should permit 224 the use of what is likely to impose the lowest cost on the server. 225 Thus, the NFS client SHOULD not insist on using a writable copy of 226 the filesystem if read-only copies exist, or a zero-age copy rather 227 than a copy that may be a little older. We presume that the 228 organization's file name space can be navigated to provide access to 229 higher-cost properties such as writability or currency as necessary, 230 but that the default use when navigating to the base information for 231 an organization ought to be as low-overhead as possible. 233 Because of the possible distinction between read-only and read-write 234 versions of a filesystem, organizations SHOULD also publish the 235 location of a writable instance of their root filesystems, and that 236 NFSv4 clients SHOULD mount that filesystem under the organizational 237 domain name preceded by a period ("."). Therefore, when names 238 beginning with a period are looked up under the NFSv4 client's 239 special directory, the SRV RR looked up in DNS uses a Service name of 240 "_nfs4._write._domainroot", and the indicated server (or servers) 241 SHOULD export the writable instance at "/.domain-root-write-{Name}" 242 for a domain name Name. 244 Extending the opening example, suppose a client wished to locate the 245 read-only and read-write roots of the filesystem published by 246 organization example.net. Suppose a read-write instance were hosted 247 on server nfs1tr.example.net, and read-only instances were on that 248 server and also on server nfs2ex.example.net. The DNS servers for 249 the domain would publish records like 251 _nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net 252 _nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net 253 _nfs4._write._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net 255 The nfs1tr.example.net server would export filesystems at both 256 "/.domain-root-example.net" (the read-only instance) and "/.domain- 257 root-write-example.net" (the read-write instance). The 258 nfs2ex.example.net server need export only the "/.domain-root- 259 example.net" name for its read-only instance. 261 The read-write version of the filesystem would be mounted (upon use) 262 under ".example.net" in the special directory, and a read-only 263 version would be mounted under "example.net". Thus, 265 /nfs4/example.net/users 267 might be a directory in a read-only instance of the root filesystem 268 of the organization "example.net", while 270 /nfs4/.example.net/users 272 would be a writable form of that same directory. A small benefit of 273 following this convention is that names with the period prefix are 274 treated as "hidden" in many operating systems, so that the visible 275 name remains the lowest-overhead name. 277 4.3. Filesystem integration issues 279 The result of the DNS search SHOULD appear as a (pseudo-)directory in 280 the client name space. A further refinement is advisable, and SHOULD 281 be deployed: that only fully-qualified domain names appear as 282 directories. That is, in many environments, DNS names may be 283 abbreviated from their fully-qualified form. In such circumstances, 284 multiple names might be given to filesystem code that all resolve to 285 the same DNS SRV RRs. The abbreviated form SHOULD be represented in 286 the client's name space cache as a symbolic link, pointing to the 287 fully-qualified name, case-canonicalized when appropriate. This will 288 allow pathnames obtained with, say, getcwd() to include the DNS name 289 that is most likely to be usable outside the scope of any particular 290 DNS abbreviation convention. 292 5. Where is this integration carried out? 294 Another consideration is what agent should be responsible for 295 interpreting the SRV records. It could be done just as well by the 296 client or by the server, though we expect that most clients will 297 include this function themselves. Using something like Automounter 298 [AMD] technology, the client would be responsible for interpreting 299 names under a particular directory, discovering the appropriate 300 filesystem to mount, and mounting it in the appropriate place in the 301 client name space before returning control to the application doing a 302 lookup. Alternatively, one could imagine the existence of an NFS 303 version 4 server that awaited similar domain-name lookups, then 304 consulted the DNS SRV records to determine the servers for the 305 indicated published filesystem, and then returned that information 306 via NFS Version 4 attributes as a referral in the way outlined by 307 Noveck and Burnett [NB0510]. In either case, the result of the DNS 308 lookup should be cached (obeying TTL) so that the result could be 309 returned more quickly the next time. 311 We strongly suggest that this functionality be implemented by NFS 312 clients. While we recognize that it would be possible to configure 313 clients so that they relied on a specially-configured server to do 314 their SRV lookups for them, we feel that such a requirement would 315 impose unusual dependencies and vulnerabilities for the deployers of 316 such clients. 318 6. Relationship to DNS NFS4ID RR 320 This DNS use has no obvious relationship to the NFS4ID RR. The 321 NFS4ID RR is a mechanism to help clients and servers configure 322 themselves with respect to the domain strings used in "who" strings 323 in ACL entries and in owner and group names. The authentication/ 324 authorization domain string of a server need have no direct 325 relationship to the name of the organization that is publishing a 326 file name space of which this server's filesystems form a part. At 327 the same time, it might be seen as straightforward or normal for such 328 a server to refer to the ownership of most of its files using a 329 domain string with an evident relationship to that NFS4ID-given 330 domain name, but this document imposes no such requirement. 332 7. Security Considerations 334 Naive use of the DNS may effectively give clients published server 335 referrals that are intrusive substitutes for the servers intended by 336 domain administrators. 338 It may be possible to build a trust chain by using DNSSEC [RFC4033] 339 to implement this function on the client, or by implementing this 340 function on an NFS Version 4 server that uses DNSSEC and maintaining 341 a trust relationship with that server. This trust chain also breaks 342 if the SRV interpreter accepts responses from insecure DNS zones. 343 Thus, it would likely be prudent also to use domain-based service 344 principal names for the servers for the root filesystems as indicated 345 as the targets of the SRV records. The idea here is that one wants 346 to authenticate {nfs, domainname, host.fqdn}, not simply {nfs, 347 host.fqdn}, when the server is a domain's root file server obtained 348 through an insecure DNS SRV RR lookup. The domain administrator can 349 thus ensure that only domain root NFSv4 servers have credentials for 350 such domain-based service principal names. 352 Domain-based service principal names are defined in RFCs 5178 353 [RFC5178] and 5179 [RFC5179]. To make use of RFC 5178's domain-based 354 names, the syntax for "domain-based-name" MUST be used with a service 355 of "nfs", a domain matching the name of the organization whose root 356 filesystem is being sought, and a hostname given in the target of the 357 DNS SRV resource record. Thus, in the example above, two file 358 servers (nfs1tr.example.net and nfs2ex.example.net) are located as 359 hosting the root filesystem for the organization example.net. To 360 communicate with, for instance, the second of the given file servers, 361 GSS-API should be used with the name-type of 362 GSS_C_NT_DOMAINBASED_SERVICE defined in RFC 5178 and with a symbolic 363 name of 365 nfs@example.net@nfs2ex.example.net 367 in order to verify that the named server (nfs2ex.example.net) is 368 authorized to provide the root filesystem for the example.net 369 organization. 371 8. References 373 8.1. Normative References 375 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 376 RFC 1034, November 1987. 378 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 379 Specification", RFC 1035, November 1987. 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", March 1997. 384 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 385 specifying the location of services (DNS SRV)", RFC 2782, 386 February 2000. 388 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 389 Beame, C., Eisler, M., and D. Noveck, "Network File System 390 (NFS) version 4 Protocol", RFC 3530, April 2003. 392 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 393 Rose, "DNS Security Introduction and Requirements", 394 RFC 4033, March 2005. 396 [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service 397 Application Program Interface (GSS-API) 398 Internationalization and Domain-Based Service Names and 399 Name Type", RFC 5178, May 2008. 401 [RFC5179] Williams, N., "Generic Security Service Application 402 Program Interface (GSS-API) Domain-Based Service Names 403 Mapping for the Kerberos V GSS Mechanism", RFC 5179, 404 May 2008. 406 8.2. Informative References 408 [AFS] Howard, J., "An Overview of the Andrew File System"", 409 Proc. USENIX Winter Tech. Conf. Dallas, February 1988. 411 [AMD] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter 412 Reference Manual", March 1991, 413 . 415 [DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V., 416 Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S., 417 and E. Zayas, "DEcorum File System Architectural 418 Overview", Proc. USENIX Summer Conf. Anaheim, Calif., 419 June 1990. 421 [Gudmundsson] 422 Gudmundsson, O. and A. Hoenes, "Creation of a Registry for 423 DNS SRV Record Service Prefixes", October 2009, . 427 [NB0510] Noveck, D. and R. Burnett, "Next Steps for NFSv4 428 Migration/Replication", October 2005, . 431 [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. 432 Mockapetris, "New DNS RR Definitions", RFC 1183, 433 October 1990. 435 Authors' Addresses 437 Craig Everhart 438 NetApp 439 800 Cranberry Woods Drive, Ste. 300 440 Cranberry Township, PA 16066 441 US 443 Phone: +1 724 741 5101 444 Email: everhart@netapp.com 445 Andy Adamson 446 NetApp 447 495 East Java Drive 448 Sunnyvale, CA 94089 449 US 451 Phone: +1 734 665 1204 452 Email: andros@netapp.com 454 Jiaying Zhang 455 Google 456 604 Arizona Avenue 457 Santa Monica, CA 90401 458 US 460 Phone: +1 310 309 6884 461 Email: jiayingz@google.com