idnits 2.17.1 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 466. 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 Copyright Line does not match the current year -- 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 (September 26, 2008) is 5691 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 345, but no explicit reference was found in the text == Unused Reference: 'RFC5178' is defined on line 366, but no explicit reference was found in the text == Unused Reference: 'RFC5179' is defined on line 371, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 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: March 30, 2009 J. Zhang 6 Google 7 September 26, 2008 9 Using DNS SRV to Specify a Global File Name Space with NFS version 4 10 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 30, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 The NFS version 4 protocol provides a natural way for a collection of 44 NFS file servers to collaborate in providing an organization-wide 45 file name space. The DNS SRV RR allows a simple and appropriate way 46 for an organization to publish the root of its name space, even to 47 clients that might not be intimately associated with such an 48 organization. DNS SRV can be used to join these organization-wide 49 file name spaces together to allow construction of a global, uniform 50 NFS version 4 file name space. This document refreshes the draft. 52 Table of Contents 54 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 55 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Proposed Use of SRV Resource Record in DNS . . . . . . . . . . 3 57 3.1. Deployment of the Resource Record . . . . . . . . . . . . 4 58 4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 5 59 4.1. Globally-useful names: conventional mount point . . . . . 5 60 4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 5 61 4.3. File system integration issues . . . . . . . . . . . . . . 6 62 5. Where is this integration carried out? . . . . . . . . . . . . 7 63 6. Relationship to DNS NFS4ID RR . . . . . . . . . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 69 Intellectual Property and Copyright Statements . . . . . . . . . . 11 71 1. Requirements notation 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 2. Background 79 With the advent of fs_locations attributes in the NFS Version 4 80 protocol [RFC3530], NFS servers can cooperate to build a file name 81 space that crosses server boundaries, as detailed in the description 82 of referrals in [NB0510]. With NFS Version 4 referrals, a file 83 server may indicate to its client that the file system name tree 84 beneath a given name in the server is not present on itself, but is 85 represented by a filesystem in some other set of servers. The 86 mechanism is general, allowing servers to describe any filesystem as 87 being reachable by requests to any of a set of servers. Thus, 88 starting with a single NFS Version 4 server, using these referrals, 89 an NFS Version 4 client might be able to see a large name space 90 associated with a collection of interrelated NFS Version 4 file 91 servers. An organization could use this capability to construct a 92 uniform file name space for itself. 94 An organization might wish to publish the starting point for this 95 name space to its clients. In many cases, the organization will want 96 to publish this starting point to a broader set of possible clients. 97 At the same time, it is useful to require clients to know only the 98 smallest amount of information in order to locate the appropriate 99 name space. Simultaneously, that required information should be 100 constant through the life of an organization if the clients are not 101 to require reconfiguration as administrative events change, for 102 instance, a server's name or address. 104 3. Proposed Use of SRV Resource Record in DNS 106 Providing an organization's published file system name space is a 107 service, and it is appropriate to use the DNS [RFC1035] to locate it. 108 As with the AFSDB resource record type [RFC1183], the client need 109 only utter the (relatively) constant domain name for an organization 110 in order to locate its file system name space service. Once a client 111 uses the DNS to locate one or more servers for the root of the 112 organization's name space, it can use the standard NFS Version 4 113 mechanisms to navigate the remainder of the NFS servers for that 114 organization. The use of this proposed mechanism results in a useful 115 cross-organizational name space, just as in AFS [AFS] and DCE/DFS 116 [DFS] before it. A client need know only the name of the 117 organization in order to locate the file system name space published 118 by that organization. 120 We propose the use of the DNS SRV resource record type [RFC2782] to 121 fulfill this function. The format of the DNS SRV record is as 122 follows: 124 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 126 In our case, we use a Service name of "nfs4" and a conventional 127 Protocol of "_tcp". The Target fields give the domain names of the 128 NFS Version 4 servers that export root filesystems. An NFS Version 4 129 client SHOULD interpret any of the exported pseudo-root filesystems 130 as the filesystem published by the organization with the given domain 131 name. 133 Suppose a client wished to locate the root of the file system 134 published by organization example.net. The DNS servers for the 135 domain could publish records like 137 _nfs4._tcp IN SRV 0 0 2049 nfs1tr.example.net 138 _nfs4._tcp IN SRV 1 0 2049 nfs2ex.example.net 140 The result domain names nfs1tr.example.net and nfs2ex.example.net 141 indicate NFS Version 4 file servers that export the root of the 142 published name space for the example.net domain. In accordance with 143 RFC 2782, these records are to be interpreted using the Priority and 144 Weight field values, selecting an appropriate file server with which 145 to begin a network conversation. Subsequent accesses are carried out 146 in accordance with ordinary NFS Version 4 protocol. 148 3.1. Deployment of the Resource Record 150 As with any DNS resource, any server installation needs to concern 151 itself with the likely loads and effects of the presence of the 152 resource record. The answers to requests for RRs might differ 153 depending on what the server can tell about the client. For example, 154 some RRs might be returned only to those clients inside some network 155 perimeter (to provide an intranet service) and requests from other 156 clients might be denied. As the RR directs the clients to ask for 157 service from a given set of servers, the administrator should ensure 158 that the identified servers can handle the expected load. 159 Fortunately, the definition of the DNS SRV resource record offers a 160 mechanism to distribute the load to multiple servers within a 161 priority ordering. 163 4. Integration with Use of NFS Version 4 165 There are at least two remaining questions: whether this DNS SRV 166 record evaluation is done in the NFS server or client, and also how 167 the domain names of the organizations are passed to client or server. 168 A third question is how this might produce a uniform global file name 169 space, and what prefix should be used for such file names. 171 This specification anticipates that these SRV records will most 172 commonly be used to define the second directory level in an inter- 173 organizational file name space. This directory will be populated 174 with domain names pointing to the file systems published for use 175 under those domain names. Thus, the root directory for the file 176 system published by example.net will effectively be mounted 177 underneath the example.net name in a second-level directory. 179 In general, a domain name will appear to a client as a directory name 180 pointing to the root directory of the file system published by the 181 organization responsible for that domain name. 183 4.1. Globally-useful names: conventional mount point 185 For the inter-organizational name space to be a global name space, it 186 is useful for its mount point in local systems to be uniform as well. 187 The name /nfs4/ SHOULD be used so that names on one machine will be 188 directly usable on any machine. Thus, the example.net published file 189 system would be accessible as 191 /nfs4/example.net/ 193 on any client. Using this convention, "/nfs4/" is a mount for a 194 special file system that is populated with the results of SRV record 195 lookups. 197 4.2. Mount options 199 SRV records are necessarily less complete than the information in the 200 existing NFS Version 4 attributes fs_locations and the proposed 201 fs_locations_info. For the rootpath field of fs_location, we assume 202 that the empty string is adequate. Thus, the servers listed as 203 targets for the SRV resource records should export the root of the 204 organization's published file system as the pseudo-root in its 205 exported namespace. 207 As for the other attributes in fs_locations_info, the recommended 208 approach is for a client to make its first possible contact with any 209 of the referred-to servers, obtain the fs_locations_info structure 210 from that server, and use the information from that obtained 211 structure as the basis for its judgment of whether it would be better 212 to use a different server representative from the set of servers for 213 that filesystem. 215 We recommend, though, that the process of mounting an organization's 216 name space should permit the use of what is likely to impose the 217 lowest cost on the server. Thus, we recommend that the client not 218 insist on using a writable copy of the filesystem if read-only copies 219 exist, or a zero-age copy rather than a copy that may be a little 220 older. We presume that the organization's file name space can be 221 navigated to provide access to higher-cost properties such as 222 writability or currency as necessary, but that the default use when 223 navigating to the base information for an organization ought to be as 224 low-overhead as possible. 226 One extension of this rule that we might choose to inherit from AFS, 227 though, is to give a special meaning to the domain name of an 228 organization preceded by a period ("."). It might be reasonable to 229 have names mounting the filesystem for a period-prefixed domain name 230 (e.g., ".example.net") attempt to mount only a read-write instance of 231 that organization's root filesystem, rather than permitting the use 232 of read-only instances of that filesystem. Thus, 234 /nfs4/example.net/users 236 might be a directory in a read-only instance of the root filesystem 237 of the organization "example.net", while 239 /nfs4/.example.net/users 241 would be a writable form of that same directory. A small benefit of 242 following this convention is that names with the period prefix are 243 treated as "hidden" in many operating systems, so that the visible 244 name remains the lowest-overhead name. 246 4.3. File system integration issues 248 The result of the DNS search SHOULD appear as a (pseudo-)directory in 249 the client name space, cached for a time no longer than the RR's TTL. 250 A further refinement is advisable, and SHOULD be deployed: that only 251 fully-qualified domain names appear as directories. That is, in many 252 environments, DNS names may be abbreviated from their fully-qualified 253 form. In such circumstances, multiple names might be given to file 254 system code that all resolve to the same DNS SRV RRs. The 255 abbreviated form SHOULD be represented in the client's name space 256 cache as a symbolic link, pointing to the fully-qualified name, case- 257 canonicalized when appropriate. This will allow pathnames obtained 258 with, say, getcwd() to include the DNS name that is most likely to be 259 usable outside the scope of any particular DNS abbreviation 260 convention. 262 5. Where is this integration carried out? 264 Another consideration is what agent should be responsible for 265 interpreting the SRV records. It could be done just as well by the 266 client or by the server, though we expect that most clients will 267 include this function themselves. Using something like Automounter 268 [AMD] technology, the client would be responsible for interpreting 269 names under a particular directory, discovering the appropriate 270 filesystem to mount, and mounting it in the appropriate place in the 271 client name space before returning control to the application doing a 272 lookup. Alternatively, one could imagine the existence of an NFS 273 version 4 server that awaited similar domain-name lookups, then 274 consulted the DNS SRV records to determine the servers for the 275 indicated published file system, and then returned that information 276 via NFS Version 4 attributes as a referral in the way outlined by 277 Noveck and Burnett [NB0510]. In either case, the result of the DNS 278 lookup should be cached (obeying TTL) so that the result could be 279 returned more quickly the next time. 281 We strongly suggest that this functionality be implemented by NFS 282 clients. While we recognize that it would be possible to configure 283 clients so that they relied on a specially-configured server to do 284 their SRV lookups for them, we feel that such a requirement would 285 impose unusual dependencies and vulnerabilities for the deployers of 286 such clients. 288 6. Relationship to DNS NFS4ID RR 290 This DNS use has no obvious relationship to the NFS4ID RR. The 291 NFS4ID RR is a mechanism to help clients and servers configure 292 themselves with respect to the domain strings used in "who" strings 293 in ACL entries and in owner and group names. The authentication/ 294 authorization domain string of a server need have no direct 295 relationship to the name of the organization that is publishing a 296 file name space of which this server's filesystems form a part. At 297 the same time, it might be seen as straightforward or normal for such 298 a server to refer to the ownership of most of its files using a 299 domain string with an evident relationship to that NFS4ID-given 300 domain name, but this document imposes no such requirement. 302 7. Security Considerations 304 Naive use of the DNS may effectively give clients published server 305 referrals that are intrusive substitutes for the servers intended by 306 domain administrators. 308 It may be possible to build a trust chain by using DNSSEC [RFC4033] 309 to implement this function on the client, or by implementing this 310 function on an NFS Version 4 server that uses DNSSEC and maintaining 311 a trust relationship with that server. This trust chain also breaks 312 if the SRV interpreter accepts responses from insecure DNS zones. 313 Thus, it would likely be prudent also to use domain-based service 314 principal names for the servers for the root filesystems as indicated 315 as the targets of the SRV records. The idea here is that one wants 316 to authenticate {nfs, domainname, host.fqdn}, not simply {nfs, 317 host.fqdn}, when the server is a domain's root file server obtained 318 through an insecure DNS SRV RR lookup. The domain administrator can 319 thus ensure that only domain root NFSv4 servers have credentials for 320 such domain-based service principal names. 322 Domain-based service principal names are defined in RFCs 5178 323 [RFC3530] and 5179 [RFC3530]. To make use of RFC 5178's domain-based 324 names, the syntax for "domain-based-name" MUST be used with a service 325 of "nfs", a domain matching the name of the organization whose root 326 filesystem is being sought, and a hostname given in the target of the 327 DNS SRV resource record. Thus, in the example above, two file 328 servers (nfs1tr.example.net and nfs2ex.example.net) are located as 329 hosting the root filesystem for the organization example.net. To 330 communicate with, for instance, the second of the given file servers, 331 GSS-API should be used with the name-type of 332 GSS_C_NT_DOMAINBASED_SERVICE defined in RFC 5178 and with a symbolic 333 name of 335 nfs@example.net@nfs2ex.example.net 337 in order to verify that the named server (nfs2ex.example.net) is 338 authorized to provide the root filesystem for the example.net 339 organization. 341 8. References 343 8.1. Normative References 345 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 346 RFC 1034, November 1987. 348 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 349 Specification", RFC 1035, November 1987. 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", March 1997. 354 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 355 specifying the location of services (DNS SRV)", RFC 2782, 356 February 2000. 358 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 359 Beame, C., Eisler, M., and D. Noveck, "Network File System 360 (NFS) version 4 Protocol", RFC 3530, April 2003. 362 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 363 Rose, "DNS Security Introduction and Requirements", 364 RFC 4033, March 2005. 366 [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service 367 Application Program Interface (GSS-API) 368 Internationalization and Domain-Based Service Names and 369 Name Type", RFC 5178, May 2008. 371 [RFC5179] Williams, N., "Generic Security Service Application 372 Program Interface (GSS-API) Domain-Based Service Names 373 Mapping for the Kerberos V GSS Mechanism", RFC 5179, 374 May 2008. 376 8.2. Informative References 378 [AFS] Howard, J., "An Overview of the Andrew File System"", 379 Proc. USENIX Winter Tech. Conf. Dallas, February 1988. 381 [AMD] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter 382 Reference Manual", March 1991, 383 . 385 [DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V., 386 Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S., 387 and E. Zayas, "DEcorum File System Architectural 388 Overview", Proc. USENIX Summer Conf. Anaheim, Calif., 389 June 1990. 391 [NB0510] Noveck, D. and R. Burnett, "Next Steps for NFSv4 392 Migration/Replication", October 2005, . 395 [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. 396 Mockapetris, "New DNS RR Definitions", RFC 1183, 397 October 1990. 399 Authors' Addresses 401 Craig Everhart 402 NetApp 403 7301 Kit Creek Road 404 Research Triangle Park, NC 27709 405 US 407 Phone: +1 919 476 5320 408 Email: everhart@netapp.com 410 Andy Adamson 411 NetApp 412 495 East Java Drive 413 Sunnyvale, CA 94089 414 US 416 Phone: +1 734 665 1204 417 Email: andros@netapp.com 419 Jiaying Zhang 420 Google 421 604 Arizona Avenue 422 Santa Monica, CA 90401 423 US 425 Phone: +1 310 309 6884 426 Email: jiayingz@google.com 428 Full Copyright Statement 430 Copyright (C) The IETF Trust (2008). 432 This document is subject to the rights, licenses and restrictions 433 contained in BCP 78, and except as set forth therein, the authors 434 retain all their rights. 436 This document and the information contained herein are provided on an 437 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 438 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 439 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 440 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 441 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 442 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 444 Intellectual Property 446 The IETF takes no position regarding the validity or scope of any 447 Intellectual Property Rights or other rights that might be claimed to 448 pertain to the implementation or use of the technology described in 449 this document or the extent to which any license under such rights 450 might or might not be available; nor does it represent that it has 451 made any independent effort to identify any such rights. Information 452 on the procedures with respect to rights in RFC documents can be 453 found in BCP 78 and BCP 79. 455 Copies of IPR disclosures made to the IETF Secretariat and any 456 assurances of licenses to be made available, or the result of an 457 attempt made to obtain a general license or permission for the use of 458 such proprietary rights by implementers or users of this 459 specification can be obtained from the IETF on-line IPR repository at 460 http://www.ietf.org/ipr. 462 The IETF invites any interested party to bring to its attention any 463 copyrights, patents or patent applications, or other proprietary 464 rights that may cover technology that may be required to implement 465 this standard. Please address the information to the IETF at 466 ietf-ipr@ietf.org. 468 Acknowledgment 470 Funding for the RFC Editor function is provided by the IETF 471 Administrative Support Activity (IASA).