idnits 2.17.1 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 7, 2011) is 4583 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: 'RFC6335' is defined on line 460, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) Summary: 2 errors (**), 0 flaws (~~), 2 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 9, 2012 J. Zhang 6 Google 7 October 7, 2011 9 Using DNS SRV to Specify a Global File Name Space with NFS version 4 10 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-09.txt 12 Abstract 14 The NFS version 4 protocol provides a mechanism 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 filesystem name space, 18 even to 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 file name space. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 9, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 70 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Use of SRV Resource Record in DNS . . . . . . . . . . . . . . 4 72 4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 6 73 4.1. Globally-useful names: conventional mount point . . . . . 6 74 4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 6 75 4.3. Filesystem integration issues . . . . . . . . . . . . . . 8 76 4.4. Multicast, mDNS, and DNS-SD . . . . . . . . . . . . . . . 8 77 5. Where is this integration carried out? . . . . . . . . . . . . 8 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Requirements notation 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 2. Background 93 Version 4 of the NFS protocol [RFC3530] introduced the fs_locations 94 attribute. Use of this attribute was elaborated further in the NFS 95 Version 4 Minor Version 1 protocol [RFC5661], which also defined an 96 extended version of the attribute as fs_locations_info. With the 97 advent of these attributes, NFS servers can cooperate to build a file 98 name space that crosses server boundaries. The fs_locations and 99 fs_locations_info attributes are used as referrals, so that a file 100 server may indicate to its client that the file name tree beneath a 101 given name in the server is not present on itself, but is represented 102 by a filesystem in some other set of servers. The mechanism is 103 general, allowing servers to describe any filesystem as being 104 reachable by requests to any of a set of servers. Thus, starting 105 with a single NFS Version 4 server, using these referrals, an NFS 106 Version 4 client could see a large name space associated with a 107 collection of interrelated NFS Version 4 file servers. An 108 organization could use this capability to construct a uniform file 109 name space for itself. 111 An organization might wish to publish the starting point for this 112 name space to its clients. In many cases, the organization will want 113 to publish this starting point to a broader set of possible clients. 114 At the same time, it is useful to require clients to know only the 115 smallest amount of information in order to locate the appropriate 116 name space. Simultaneously, that required information should be 117 constant through the life of an organization if the clients are not 118 to require reconfiguration as administrative events change, for 119 instance, a server's name or address. 121 3. Use of SRV Resource Record in DNS 123 Providing an organization's published filesystem name space is a 124 service, and the DNS [RFC1034][RFC1035] provides methods for 125 discovery of that service. This standard defines a mapping from a 126 domain name to the NFS filesystem(s) associated with that name; such 127 filesystems are called "domain root" filesystems. From such 128 filesystems, like other NFS filesystems, an NFS client can use the 129 standard NFS mechanisms to navigate the rest of the NFS file servers 130 that make up the filesystem name space for the given domain. 132 Such "domain root" filesystems are mounted at a conventional point in 133 the NFS client namespace. The mechanism results in a uniform cross- 134 organizational file name space, similar to that seen in both AFS 135 [AFS][RFC5864] and DCE/DFS [DFS]. An NFS client need know only the 136 domain name for an organization in order to locate the filesystem 137 name space published by that organization. 139 The DNS SRV resource record type [RFC2782] is used to locate "domain 140 root" file servers. The format of the DNS SRV record is as follows: 142 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 144 The Service name is "_nfs._domainroot". The Protocol as of this 145 writing could be either "_tcp" or "_sctp"; version 4 NFS is not 146 defined over UDP. Other transport protocols could be defined in the 147 future, and SRV records that advertise domain root file services with 148 other transport protocols would use the same Service name. The 149 Target fields give the domain names of the NFS servers that export 150 filesystems for the domain's root. An NFS client may then interpret 151 any of the exported root filesystems as the filesystem published by 152 the organization with the given domain name. 154 In order to allow the NFSv4 servers so given to export a variety of 155 filesystems, those file servers MUST export the given domain's root 156 filesystems at "/.domainroot-{Name}" within their pseudo-filesystems, 157 where the "{Name}" is the name of the organization as used in the SRV 158 RR. 160 As an example, suppose a client wished to locate the root of the 161 filesystem published by organization example.net. The DNS servers 162 for the domain would publish records like 164 $ORIGIN example.net. 165 _nfs._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. 166 _nfs._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net. 168 The result domain names nfs1tr.example.net and nfs2ex.example.net 169 indicate NFS Version 4 file servers that export the root of the 170 published name space for the example.net domain. In accordance with 171 RFC 2782 [RFC2782], these records are to be interpreted using the 172 Priority and Weight field values, selecting an appropriate file 173 server with which to begin a network conversation. The two file 174 servers would export filesystems that would be found at 175 "/.domainroot-example.net" in their pseudo-filesystems, which clients 176 would mount. Clients then carry out subsequent accesses in 177 accordance with the ordinary NFS Version 4 protocol. 179 Other filesystem protocols could make use of the same "domain root" 180 abstraction, but this document discusses only the SRV records 181 indicating NFS servers. 183 4. Integration with Use of NFS Version 4 185 NFSv4 clients adhering to this specification implement a special 186 directory, analogous to an Automounter [AMD1][AMD2] directory, the 187 entries in which are domain names that have recently been traversed. 188 When an application attempts to traverse a new name in that special 189 directory, the NFSv4 client consults DNS to obtain the SRV data for 190 the given name, and if successful, it mounts the indicated 191 filesystem(s) in that name in the special directory. The goal is 192 that NFS applications will be able to lookup an organization's domain 193 name in the special directory, and the NFSv4 client will be able to 194 discover the filesystem that that organization publishes. Entries in 195 the special directory will be domain names, and they will each appear 196 to the application as a directory name pointing to the root directory 197 of the filesystem published by the organization responsible for that 198 domain name. 200 This DNS SRV record evaluation could, in principle, be done either in 201 the NFSv4 client or in an NFSv4 server. In either case, the result 202 would appear the same to applications on the NFSv4 client. This is 203 discussed further in section 5 of this document. 205 4.1. Globally-useful names: conventional mount point 207 In order that the inter-organizational name space function as a 208 global name space, the client-side mount point for that name space 209 must be the same on different clients. Conventionally, on POSIX 210 machines, the name /nfs4/ is be used so that names on one machine 211 will be directly usable on any machine. Thus, the example.net 212 published filesystem would be accessible as 214 /nfs4/example.net/ 216 on any POSIX client. Using this convention, "/nfs4/" is the name of 217 the special directory that is populated with domain names, leading to 218 file servers and filesystems that capture the results of SRV record 219 lookups. 221 4.2. Mount options 223 SRV records are necessarily less complete than the information in the 224 existing NFS Version 4 attributes fs_locations [RFC3530] or 225 fs_locations_info [RFC5661]. For the rootpath field of fs_location, 226 or the fli_fs_root of fs_locations_info, NFS servers MUST use the 227 "/.domainroot-{Name}" string. Thus, the servers listed as targets 228 for the SRV resource records MUST export the root of the 229 organization's published filesystem as the directory "/.domainroot- 230 {Name}" (for the given organization Name) in their exported NFS 231 namespaces. For example, for organization "example.net", the 232 directory "/.domainroot-example.net" would be used. 234 Chapter 11 of the NFS Version 4.1 document [RFC5661] describes the 235 approach that an NFS client should take to navigating 236 fs_locations_info information. 238 The process of mounting an organization's name space should permit 239 the use of what is likely to impose the lowest cost on the server. 240 Thus, the NFS client SHOULD NOT insist on using a writable copy of 241 the filesystem if read-only copies exist, or a zero-age copy rather 242 than a copy that may be a little older. We presume that the 243 organization's file name space can be navigated to provide access to 244 higher-cost properties such as writability or freshness as necessary, 245 but that the default use when navigating to the base information for 246 an organization ought to be as low-overhead as possible. 248 Because of the possible distinction between read-only and read-write 249 versions of a filesystem, organizations MAY also publish the location 250 of a writable instance of their domain root filesystems, and that 251 NFSv4 clients would conventionally mount that filesystem under the 252 organizational domain name preceded by a period ("."). Therefore, 253 when names beginning with a period are looked up under the NFSv4 254 client's special directory, the SRV RR looked up in DNS uses a 255 Service name of "_nfs._write._domainroot", and any indicated server 256 (or servers) MUST export the writable instance at "/.domainroot- 257 write-{Name}" for a domain name Name. 259 Extending the opening example, suppose a client wished to locate the 260 read-only and read-write roots of the filesystem published by 261 organization example.net. Suppose a read-write instance were hosted 262 on server nfs1tr.example.net, and read-only instances were on that 263 server and also on server nfs2ex.example.net. The DNS servers for 264 the domain would publish records like 266 $ORIGIN example.net. 267 _nfs._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. 268 _nfs._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net. 269 _nfs._write._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. 271 The nfs1tr.example.net server would export filesystems at both 272 "/.domainroot-example.net" (the read-only instance) and 273 "/.domainroot-write-example.net" (the read-write instance). The 274 nfs2ex.example.net server need export only the "/.domainroot- 275 example.net" name for its read-only instance. 277 The read-write version of the filesystem would be mounted (upon use) 278 under ".example.net" in the special directory, and a read-only 279 version would be mounted under "example.net". Thus, 281 /nfs4/example.net/users 283 might be a directory in a read-only instance of the root filesystem 284 of the organization "example.net", while 286 /nfs4/.example.net/users 288 would be a writable form of that same directory. 290 4.3. Filesystem integration issues 292 The result of the DNS search SHOULD appear as a (pseudo-)directory in 293 the client name space. A further refinement is RECOMMENDED: that 294 only fully-qualified domain names appear as directories. That is, in 295 many environments, DNS names may be abbreviated from their fully- 296 qualified form. In such circumstances, multiple names might be given 297 to NFS clients that all resolve to the same DNS SRV RRs. The 298 abbreviated form SHOULD be represented in the client's name space 299 cache as a symbolic link, pointing to the fully-qualified name, case- 300 folded if the client filesystem is case-sensitive. This will allow 301 pathnames obtained with, say, getcwd() to include the DNS name that 302 is most likely to be usable outside the scope of any particular DNS 303 abbreviation convention. 305 4.4. Multicast, mDNS, and DNS-SD 307 Location of the NFS domain root does not involve IP-layer broadcast, 308 multicast, or anycast communication. 310 It is not expected that this DNS SRV record format will be used in 311 conjunction with Multicast DNS (mDNS) or DNS Service Discovery 312 (DNS-SD). While mDNS could be used to locate a local domain root via 313 these SRV records, no other domain's root could be discovered. This 314 means that mDNS with DNS-SD has too little value to use in locating 315 NFSv4 domain roots. 317 5. Where is this integration carried out? 319 The NFS client is responsible for interpreting SRV records. Using 320 something like Automounter [AMD1] [AMD2] technology, the client 321 interprets names under a particular directory, discovering the 322 appropriate filesystem to mount, and mounting it in the specified 323 place in the client name space before returning control to the 324 application doing a lookup. The result of the DNS lookup should be 325 cached (obeying TTL) so that the result could be returned more 326 quickly the next time. 328 6. Security Considerations 330 This functionality introduces a new reliance of NFSv4 on the 331 integrity of DNS. Forged SRV records in DNS could cause the NFSv4 332 client to connect to the file servers of an attacker, not the file 333 servers of an organization. This is similar to attacks that can be 334 made on the base NFSv4 protocol, if server names are given in 335 fs_location attributes: the client can be made to connect to the file 336 servers of an attacker, not the file servers intended to be the 337 target for the fs_location attributes. 339 If DNSSEC [RFC4033] is available, it SHOULD be used to avoid both 340 such attacks. Domain-based service principal names are an additional 341 mechanism that also apply in this case, and it would be prudent to 342 use them. They provide a mapping from the domain name that the user 343 specified to names of security principals used on the NFSv4 servers 344 that are indicated as the targets in the SRV records (as providing 345 file service for the root filesystems). 347 With domain-based service principal names, the idea is that one wants 348 to authenticate {nfs, domainname, host.fqdn}, not simply {nfs, 349 host.fqdn}, when the server is a domain's root file server obtained 350 through a DNS SRV RR lookup that may or may not have been secure. 351 The domain administrator can thus ensure that only domain root NFSv4 352 servers have credentials for such domain-based service principal 353 names. 355 Domain-based service principal names are defined in RFCs 5178 356 [RFC5178] and 5179 [RFC5179]. To make use of RFC 5178's domain-based 357 names, the syntax for "domain-based-name" MUST be used with a service 358 of "nfs", a domain matching the name of the organization whose root 359 filesystem is being sought, and a hostname given in the target of the 360 DNS SRV resource record. Thus, in the example above, two file 361 servers (nfs1tr.example.net and nfs2ex.example.net) are located as 362 hosting the root filesystem for the organization example.net. To 363 communicate with, for instance, the second of the given file servers, 364 GSS-API is used with the name-type of GSS_C_NT_DOMAINBASED_SERVICE 365 defined in RFC 5178 and with a symbolic name of 367 nfs@example.net@nfs2ex.example.net 369 in order to verify that the named server (nfs2ex.example.net) is 370 authorized to provide the root filesystem for the example.net 371 organization. 373 NFSv4 itself contains a facility for the negotiation of security 374 mechanisms to be used between NFS clients and NFS servers. Section 375 3.3 of RFC 3530 [RFC3530] and Section 2.6 of RFC 5661 [RFC5661] both 376 describe how security mechanisms are to be negotiated. As such, 377 there is no need for this document to describe how that negotiation 378 is to be carried out when the NFS client contacts the NFS server for 379 the specified domain root filesystem(s). 381 Using SRV records to advertise the locations of NFS servers may 382 expose those NFS servers to attacks. Organizations should carefully 383 consider whether they wish their DNS servers to respond 384 differentially to different DNS clients, perhaps exposing their SRV 385 records to only those DNS requests that originate within a given 386 perimeter, in order to reduce this exposure. 388 7. IANA Considerations 389 This document requests the assignment of two new Service names 390 without associated port numbers, each for both TCP and SCTP. For 391 both Services, the Reference is this document. 393 Service name: _nfs._domainroot 394 Transport Protocol(s) TCP, SCTP 395 Assignee (REQUIRED) IESG (iesg@ietf.org) 396 Contact (REQUIRED) IETF Chair (chair@ietf.org) 397 Description (REQUIRED) NFS file service for the domain root, the root 398 of the organization's published file name space 399 Reference (REQUIRED) This document 400 Port Number (OPTIONAL) 401 Service Code (REQUIRED for DCCP only) 402 Known Unauthorized Uses (OPTIONAL) 403 Assignment Notes (OPTIONAL) 405 Service name: _nfs._write._domainroot 406 Transport Protocol(s) TCP, SCTP 407 Assignee (REQUIRED) IESG (iesg@ietf.org) 408 Contact (REQUIRED) IETF Chair (chair@ietf.org) 409 Description (REQUIRED) Writable file server for the NFS file service 410 for the domain root, the root of the organization's 411 published file name space 412 Reference (REQUIRED) This document 413 Port Number (OPTIONAL) 414 Service Code (REQUIRED for DCCP only) 415 Known Unauthorized Uses (OPTIONAL) 416 Assignment Notes (OPTIONAL) 418 8. References 420 8.1. Normative References 422 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 423 RFC 1034, November 1987. 425 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 426 Specification", RFC 1035, November 1987. 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", March 1997. 431 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 432 specifying the location of services (DNS SRV)", RFC 2782, 433 February 2000. 435 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 436 Beame, C., Eisler, M., and D. Noveck, "Network File System 437 (NFS) version 4 Protocol", RFC 3530, April 2003. 439 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 440 Rose, "DNS Security Introduction and Requirements", 441 RFC 4033, March 2005. 443 [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service 444 Application Program Interface (GSS-API) 445 Internationalization and Domain-Based Service Names and 446 Name Type", RFC 5178, May 2008. 448 [RFC5179] Williams, N., "Generic Security Service Application 449 Program Interface (GSS-API) Domain-Based Service Names 450 Mapping for the Kerberos V GSS Mechanism", RFC 5179, 451 May 2008. 453 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, Editors, "Network 454 File System (NFS) Version 4 Minor Version 1 Protocol", 455 RFC 5661, January 2010. 457 [RFC5864] Allbery, R., "DNS SRV Resource Records for AFS", RFC 5864, 458 April 2010. 460 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 461 Cheshire, "Internet Assigned Numbers Authority (IANA) 462 Procedures for the Management of the Service Name and 463 Transport Protocol Port Number Registry", RFC 6335, 464 August 2011. 466 8.2. Informative References 468 [AFS] Howard, J., "An Overview of the Andrew File System"", 469 Proc. USENIX Winter Tech. Conf. Dallas, February 1988. 471 [AMD1] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter 472 Reference Manual", March 1991, 473 . 475 [AMD2] Crosby, M., "AMD--AutoMount Daemon", Linux Journal 1997, 476 35es Article 4, March 1997. 478 [DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V., 479 Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S., 480 and E. Zayas, "DEcorum File System Architectural 481 Overview", Proc. USENIX Summer Conf. Anaheim, Calif., 482 June 1990. 484 Authors' Addresses 486 Craig Everhart 487 NetApp 488 800 Cranberry Woods Drive, Ste. 300 489 Cranberry Township, PA 16066 490 US 492 Phone: +1 724 741 5101 493 Email: everhart@netapp.com 495 W.A. (Andy) Adamson 496 NetApp 497 495 East Java Drive 498 Sunnyvale, CA 94089 499 US 501 Phone: +1 734 665 1204 502 Email: andros@netapp.com 504 Jiaying Zhang 505 Google 506 604 Arizona Avenue 507 Santa Monica, CA 90401 508 US 510 Phone: +1 310 309 6884 511 Email: jiayingz@google.com