idnits 2.17.1 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-01.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 -- 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 (May 15, 2009) is 5453 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 349, but no explicit reference was found in the text == Unused Reference: 'RFC5178' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'RFC5179' 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 (~~), 4 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: November 16, 2009 J. Zhang 6 Google 7 May 15, 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-01.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 November 16, 2009. 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 3.1. Deployment of the Resource Record . . . . . . . . . . . . 4 63 4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 5 64 4.1. Globally-useful names: conventional mount point . . . . . 5 65 4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 5 66 4.3. File system integration issues . . . . . . . . . . . . . . 6 67 5. Where is this integration carried out? . . . . . . . . . . . . 7 68 6. Relationship to DNS NFS4ID RR . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Requirements notation 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 2. Background 83 With the advent of fs_locations attributes in the NFS Version 4 84 protocol [RFC3530], NFS servers can cooperate to build a file name 85 space that crosses server boundaries, as detailed in the description 86 of referrals in [NB0510]. With NFS Version 4 referrals, a file 87 server may indicate to its client that the file system name tree 88 beneath a given name in the server is not present on itself, but is 89 represented by a filesystem in some other set of servers. The 90 mechanism is general, allowing servers to describe any filesystem as 91 being reachable by requests to any of a set of servers. Thus, 92 starting with a single NFS Version 4 server, using these referrals, 93 an NFS Version 4 client might be able to see a large name space 94 associated with a collection of interrelated NFS Version 4 file 95 servers. An organization could use this capability to construct a 96 uniform file name space for itself. 98 An organization might wish to publish the starting point for this 99 name space to its clients. In many cases, the organization will want 100 to publish this starting point to a broader set of possible clients. 101 At the same time, it is useful to require clients to know only the 102 smallest amount of information in order to locate the appropriate 103 name space. Simultaneously, that required information should be 104 constant through the life of an organization if the clients are not 105 to require reconfiguration as administrative events change, for 106 instance, a server's name or address. 108 3. Proposed Use of SRV Resource Record in DNS 110 Providing an organization's published file system name space is a 111 service, and it is appropriate to use the DNS [RFC1035] to locate it. 112 As with the AFSDB resource record type [RFC1183], the client need 113 only utter the (relatively) constant domain name for an organization 114 in order to locate its file system name space service. Once a client 115 uses the DNS to locate one or more servers for the root of the 116 organization's name space, it can use the standard NFS Version 4 117 mechanisms to navigate the remainder of the NFS servers for that 118 organization. The use of this proposed mechanism results in a useful 119 cross-organizational name space, just as in AFS [AFS] and DCE/DFS 120 [DFS] before it. A client need know only the name of the 121 organization in order to locate the file system name space published 122 by that organization. 124 We propose the use of the DNS SRV resource record type [RFC2782] to 125 fulfill this function. The format of the DNS SRV record is as 126 follows: 128 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 130 In our case, we use a Service name of "nfs4" and a conventional 131 Protocol of "_tcp". The Target fields give the domain names of the 132 NFS Version 4 servers that export root filesystems. An NFS Version 4 133 client SHOULD interpret any of the exported pseudo-root filesystems 134 as the filesystem published by the organization with the given domain 135 name. 137 Suppose a client wished to locate the root of the file system 138 published by organization example.net. The DNS servers for the 139 domain could publish records like 141 _nfs4._tcp IN SRV 0 0 2049 nfs1tr.example.net 142 _nfs4._tcp IN SRV 1 0 2049 nfs2ex.example.net 144 The result domain names nfs1tr.example.net and nfs2ex.example.net 145 indicate NFS Version 4 file servers that export the root of the 146 published name space for the example.net domain. In accordance with 147 RFC 2782, these records are to be interpreted using the Priority and 148 Weight field values, selecting an appropriate file server with which 149 to begin a network conversation. Subsequent accesses are carried out 150 in accordance with ordinary NFS Version 4 protocol. 152 3.1. Deployment of the Resource Record 154 As with any DNS resource, any server installation needs to concern 155 itself with the likely loads and effects of the presence of the 156 resource record. The answers to requests for RRs might differ 157 depending on what the server can tell about the client. For example, 158 some RRs might be returned only to those clients inside some network 159 perimeter (to provide an intranet service) and requests from other 160 clients might be denied. As the RR directs the clients to ask for 161 service from a given set of servers, the administrator should ensure 162 that the identified servers can handle the expected load. 163 Fortunately, the definition of the DNS SRV resource record offers a 164 mechanism to distribute the load to multiple servers within a 165 priority ordering. 167 4. Integration with Use of NFS Version 4 169 There are at least two remaining questions: whether this DNS SRV 170 record evaluation is done in the NFS server or client, and also how 171 the domain names of the organizations are passed to client or server. 172 A third question is how this might produce a uniform global file name 173 space, and what prefix should be used for such file names. 175 This specification anticipates that these SRV records will most 176 commonly be used to define the second directory level in an inter- 177 organizational file name space. This directory will be populated 178 with domain names pointing to the file systems published for use 179 under those domain names. Thus, the root directory for the file 180 system published by example.net will effectively be mounted 181 underneath the example.net name in a second-level directory. 183 In general, a domain name will appear to a client as a directory name 184 pointing to the root directory of the file system published by the 185 organization responsible for that domain name. 187 4.1. Globally-useful names: conventional mount point 189 For the inter-organizational name space to be a global name space, it 190 is useful for its mount point in local systems to be uniform as well. 191 The name /nfs4/ SHOULD be used so that names on one machine will be 192 directly usable on any machine. Thus, the example.net published file 193 system would be accessible as 195 /nfs4/example.net/ 197 on any client. Using this convention, "/nfs4/" is a mount for a 198 special file system that is populated with the results of SRV record 199 lookups. 201 4.2. Mount options 203 SRV records are necessarily less complete than the information in the 204 existing NFS Version 4 attributes fs_locations and the proposed 205 fs_locations_info. For the rootpath field of fs_location, we assume 206 that the empty string is adequate. Thus, the servers listed as 207 targets for the SRV resource records should export the root of the 208 organization's published file system as the pseudo-root in its 209 exported namespace. 211 As for the other attributes in fs_locations_info, the recommended 212 approach is for a client to make its first possible contact with any 213 of the referred-to servers, obtain the fs_locations_info structure 214 from that server, and use the information from that obtained 215 structure as the basis for its judgment of whether it would be better 216 to use a different server representative from the set of servers for 217 that filesystem. 219 We recommend, though, that the process of mounting an organization's 220 name space should permit the use of what is likely to impose the 221 lowest cost on the server. Thus, we recommend that the client not 222 insist on using a writable copy of the filesystem if read-only copies 223 exist, or a zero-age copy rather than a copy that may be a little 224 older. We presume that the organization's file name space can be 225 navigated to provide access to higher-cost properties such as 226 writability or currency as necessary, but that the default use when 227 navigating to the base information for an organization ought to be as 228 low-overhead as possible. 230 One extension of this rule that we might choose to inherit from AFS, 231 though, is to give a special meaning to the domain name of an 232 organization preceded by a period ("."). It might be reasonable to 233 have names mounting the filesystem for a period-prefixed domain name 234 (e.g., ".example.net") attempt to mount only a read-write instance of 235 that organization's root filesystem, rather than permitting the use 236 of read-only instances of that filesystem. Thus, 238 /nfs4/example.net/users 240 might be a directory in a read-only instance of the root filesystem 241 of the organization "example.net", while 243 /nfs4/.example.net/users 245 would be a writable form of that same directory. A small benefit of 246 following this convention is that names with the period prefix are 247 treated as "hidden" in many operating systems, so that the visible 248 name remains the lowest-overhead name. 250 4.3. File system integration issues 252 The result of the DNS search SHOULD appear as a (pseudo-)directory in 253 the client name space, cached for a time no longer than the RR's TTL. 254 A further refinement is advisable, and SHOULD be deployed: that only 255 fully-qualified domain names appear as directories. That is, in many 256 environments, DNS names may be abbreviated from their fully-qualified 257 form. In such circumstances, multiple names might be given to file 258 system code that all resolve to the same DNS SRV RRs. The 259 abbreviated form SHOULD be represented in the client's name space 260 cache as a symbolic link, pointing to the fully-qualified name, case- 261 canonicalized when appropriate. This will allow pathnames obtained 262 with, say, getcwd() to include the DNS name that is most likely to be 263 usable outside the scope of any particular DNS abbreviation 264 convention. 266 5. Where is this integration carried out? 268 Another consideration is what agent should be responsible for 269 interpreting the SRV records. It could be done just as well by the 270 client or by the server, though we expect that most clients will 271 include this function themselves. Using something like Automounter 272 [AMD] technology, the client would be responsible for interpreting 273 names under a particular directory, discovering the appropriate 274 filesystem to mount, and mounting it in the appropriate place in the 275 client name space before returning control to the application doing a 276 lookup. Alternatively, one could imagine the existence of an NFS 277 version 4 server that awaited similar domain-name lookups, then 278 consulted the DNS SRV records to determine the servers for the 279 indicated published file system, and then returned that information 280 via NFS Version 4 attributes as a referral in the way outlined by 281 Noveck and Burnett [NB0510]. In either case, the result of the DNS 282 lookup should be cached (obeying TTL) so that the result could be 283 returned more quickly the next time. 285 We strongly suggest that this functionality be implemented by NFS 286 clients. While we recognize that it would be possible to configure 287 clients so that they relied on a specially-configured server to do 288 their SRV lookups for them, we feel that such a requirement would 289 impose unusual dependencies and vulnerabilities for the deployers of 290 such clients. 292 6. Relationship to DNS NFS4ID RR 294 This DNS use has no obvious relationship to the NFS4ID RR. The 295 NFS4ID RR is a mechanism to help clients and servers configure 296 themselves with respect to the domain strings used in "who" strings 297 in ACL entries and in owner and group names. The authentication/ 298 authorization domain string of a server need have no direct 299 relationship to the name of the organization that is publishing a 300 file name space of which this server's filesystems form a part. At 301 the same time, it might be seen as straightforward or normal for such 302 a server to refer to the ownership of most of its files using a 303 domain string with an evident relationship to that NFS4ID-given 304 domain name, but this document imposes no such requirement. 306 7. Security Considerations 308 Naive use of the DNS may effectively give clients published server 309 referrals that are intrusive substitutes for the servers intended by 310 domain administrators. 312 It may be possible to build a trust chain by using DNSSEC [RFC4033] 313 to implement this function on the client, or by implementing this 314 function on an NFS Version 4 server that uses DNSSEC and maintaining 315 a trust relationship with that server. This trust chain also breaks 316 if the SRV interpreter accepts responses from insecure DNS zones. 317 Thus, it would likely be prudent also to use domain-based service 318 principal names for the servers for the root filesystems as indicated 319 as the targets of the SRV records. The idea here is that one wants 320 to authenticate {nfs, domainname, host.fqdn}, not simply {nfs, 321 host.fqdn}, when the server is a domain's root file server obtained 322 through an insecure DNS SRV RR lookup. The domain administrator can 323 thus ensure that only domain root NFSv4 servers have credentials for 324 such domain-based service principal names. 326 Domain-based service principal names are defined in RFCs 5178 327 [RFC3530] and 5179 [RFC3530]. To make use of RFC 5178's domain-based 328 names, the syntax for "domain-based-name" MUST be used with a service 329 of "nfs", a domain matching the name of the organization whose root 330 filesystem is being sought, and a hostname given in the target of the 331 DNS SRV resource record. Thus, in the example above, two file 332 servers (nfs1tr.example.net and nfs2ex.example.net) are located as 333 hosting the root filesystem for the organization example.net. To 334 communicate with, for instance, the second of the given file servers, 335 GSS-API should be used with the name-type of 336 GSS_C_NT_DOMAINBASED_SERVICE defined in RFC 5178 and with a symbolic 337 name of 339 nfs@example.net@nfs2ex.example.net 341 in order to verify that the named server (nfs2ex.example.net) is 342 authorized to provide the root filesystem for the example.net 343 organization. 345 8. References 347 8.1. Normative References 349 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 350 RFC 1034, November 1987. 352 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 353 Specification", RFC 1035, November 1987. 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", March 1997. 358 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 359 specifying the location of services (DNS SRV)", RFC 2782, 360 February 2000. 362 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 363 Beame, C., Eisler, M., and D. Noveck, "Network File System 364 (NFS) version 4 Protocol", RFC 3530, April 2003. 366 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 367 Rose, "DNS Security Introduction and Requirements", 368 RFC 4033, March 2005. 370 [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service 371 Application Program Interface (GSS-API) 372 Internationalization and Domain-Based Service Names and 373 Name Type", RFC 5178, May 2008. 375 [RFC5179] Williams, N., "Generic Security Service Application 376 Program Interface (GSS-API) Domain-Based Service Names 377 Mapping for the Kerberos V GSS Mechanism", RFC 5179, 378 May 2008. 380 8.2. Informative References 382 [AFS] Howard, J., "An Overview of the Andrew File System"", 383 Proc. USENIX Winter Tech. Conf. Dallas, February 1988. 385 [AMD] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter 386 Reference Manual", March 1991, 387 . 389 [DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V., 390 Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S., 391 and E. Zayas, "DEcorum File System Architectural 392 Overview", Proc. USENIX Summer Conf. Anaheim, Calif., 393 June 1990. 395 [NB0510] Noveck, D. and R. Burnett, "Next Steps for NFSv4 396 Migration/Replication", October 2005, . 399 [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. 400 Mockapetris, "New DNS RR Definitions", RFC 1183, 401 October 1990. 403 Authors' Addresses 405 Craig Everhart 406 NetApp 407 800 Cranberry Woods Drive, Ste. 300 408 Cranberry Township, PA 16066 409 US 411 Phone: +1 724 741 5101 412 Email: everhart@netapp.com 414 Andy Adamson 415 NetApp 416 495 East Java Drive 417 Sunnyvale, CA 94089 418 US 420 Phone: +1 734 665 1204 421 Email: andros@netapp.com 423 Jiaying Zhang 424 Google 425 604 Arizona Avenue 426 Santa Monica, CA 90401 427 US 429 Phone: +1 310 309 6884 430 Email: jiayingz@google.com