RFC 6641

Using DNS SRV to Specify a Global File Namespace with NFS Version 4

📅 published June 2012, from ietf

RFC 6641: Using DNS SRV to Specify a Global File Namespace with NFS Version 4 🎀

  • Who wrote it: C. Everhart and W. Adamson from NetApp, plus J. Zhang from Google 🦋
  • Category: Standards Track, and it comes from the IETF stream 💖
  • Date: June 2012 🌸
  • ISSN: 2070-1721 ✨
  • Obsoletes or updates: Its header doesn't list anything it obsoletes or updates 🫶

Abstract 🌈

okay so NFS version 4 (NFSv4) gives a bunch of NFS file servers a way to work together and build one organization-wide file namespace 🗂️ ngl that's so cool. The DNS SRV Resource Record (RR) lets an organization publish the root of its file system namespace in a simple way, even to clients that aren't closely tied to that organization 💅. You can also use DNS SRV RRs to join these organization-wide namespaces together, which gets you a global, uniform NFS file namespace 🌍✨.

Status of This Memo 💜

This is an Internet Standards Track document 🔥.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more on Internet Standards, check out Section 2 of RFC 5741 🧚.

You can find the current status of this document, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc6641 🍓.

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 💖.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🫶.

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have granted the IETF Trust the right to allow changes to it outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exception is formatting it for publication as an RFC, or translating it into languages other than English 💅.

Table of Contents 🌸

1. Background ......................................................3
2. Requirements Notation ...........................................3
3. Use of the SRV Resource Record in DNS ...........................3
4. Integration with Use of NFS Version 4 ...........................5
   4.1. Globally Useful Names: Conventional Mount Point ............5
   4.2. Mount Options ..............................................6
   4.3. File System Integration Issues .............................6
   4.4. Multicast DNS ..............................................7
5. Where Is This Integration Carried Out? ..........................7
6. Security Considerations .........................................7
7. IANA Considerations .............................................9
8. References ......................................................9
   8.1. Normative References .......................................9
   8.2. Informative References ....................................10

1. Background 👑

okay so Version 4 of the NFS protocol [RFC3530] introduced the fs_locations attribute 🧚. NFSv4 minor version 1 [RFC5661] then elaborated on how that attribute gets used, and it also defined an extended version called fs_locations_info 💖.

With these attributes around, NFS servers can team up to build a file namespace that crosses server boundaries 🌈. The fs_locations and fs_locations_info attributes work as referrals. That means a file server can tell its client that the file name tree under a given name isn't on that server, and that it's actually served by a file system on some other set of servers 🦋. The mechanism is general, so servers can describe any file system as reachable through requests to any server in a set. So even if you start from one NFSv4 server, the referrals let an NFSv4 client see a huge namespace spread across a whole group of connected NFSv4 file servers 🔥. An organization can use this to build one uniform file namespace for itself ✨.

An organization might want to publish the starting point of that namespace to its clients 🎀. A lot of the time, it'll want to publish it to a much wider group of possible clients 🌍. At the same time, clients should only need the smallest amount of information to find the right namespace 💅. That required information also needs to stay constant for the whole life of the organization, so clients don't have to be reconfigured every time administrative changes happen. An example would be a server's name or address changing 🫶.

2. Requirements Notation 🍓

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📜.

3. Use of the SRV Resource Record in DNS 💖

Publishing an organization's file system namespace is a service, and DNS [RFC1034][RFC1035] gives us ways to discover that service 🔍. This standard defines a mapping from a DNS name to the NFS file system(s) that provide the root of the file system namespace tied to that DNS name. Those file systems are called "domain root" file systems 🌸. From a domain root file system, an NFS client can use the standard NFS mechanisms, just like with any other NFS file system, to get around the rest of the NFS file servers that make up the file system namespace for that domain 🦋.

Domain root file systems get mounted at a conventional point in the NFS client namespace 🎀. The result is a uniform cross-organizational file namespace, kind of like the one you see in AFS [AFS][RFC5864] and in Distributed Computing Environment / Distributed File System (DCE/DFS) [DFS] 🌈. An NFS client only needs to know an organization's domain name to find the file namespace that organization publishes 💅✨.

The DNS SRV RR type [RFC2782] is how we locate domain root file servers 🧚. The format of the DNS SRV record looks like this:

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

The Service name is _nfs-domainroot, which follows RFC 6335 [RFC6335] 🫶. The Protocol name is _tcp, for NFS service over TCP 🔥. Future NFS services that use other protocols MUST use another protocol name 🚫. The _udp label MUST NOT be used to imply NFSv4 over UDP, because neither RFC 3530 [RFC3530] nor RFC 5661 [RFC5661] defines NFSv4 over UDP 💀. The Target fields give the domain names of the NFS servers that export file systems for the domain's root. An NFS client can then treat any of those exported root file systems as the root of the file system that the organization with that domain name publishes 👑.

The domain root service isn't useful for NFS versions before version 4, since the fs_locations attribute only showed up in NFSv4 (as described in Section 1) 🙈.

Here's the important bit: so the NFSv4 servers can export a variety of file systems, those file servers MUST export the given domain's root file systems at /.domainroot/{Name} inside their pseudo-file systems. {Name} is the name of the organization, as used in the SRV RR 🎀💜.

Let's look at an example. Say a client wants to find the root of the file system that the organization example.net publishes. The DNS servers for that domain would publish records like this:

$ORIGIN example.net.
_nfs-domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
_nfs-domainroot._tcp IN SRV 1 0 18204 nfs2ex.example.net.

The domain names nfs1tr.example.net and nfs2ex.example.net point to NFSv4 file servers that export the root of the published namespace for the example.net domain 🌸. Following RFC 2782 [RFC2782], these records get interpreted using their Priority and Weight field values, so the client picks an appropriate file server to start a network conversation with 🦋. Both file servers export file systems that show up at /.domainroot/example.net in their pseudo-file systems, and that's what clients mount 🧚. After that, clients carry on with normal NFSv4 protocol accesses 💖. The first record uses port 2049, which is the port assigned to NFS, and the second record specifies a different port. The NFS servers provide NFS service on their indicated port numbers, and NFS clients connect through the matching port numbers on those servers 🔥✨.

Other file system protocols could use this same domain root idea too, but they need different Service names, which this document doesn't specify 🌈.

4. Integration with Use of NFS Version 4 ✨

NFSv4 clients that follow this specification implement a special directory, kind of like an Automounter [AMD1][AMD2] directory 🗂️. The entries in that directory are domain names that have been traversed recently 💅. When an application tries to traverse a new name in that special directory, the NFSv4 client asks DNS for the SRV data for that name. If that works, it mounts the indicated file system(s) under that name in the special directory 🦋. The goal is that NFSv4 applications can look up an organization's domain name in the special directory, and the NFSv4 client can find the file system that organization publishes 👑. Each entry in the special directory is a domain name, and to the application, each one looks like a directory name pointing at the root directory of the file system published by the organization responsible for that domain name 🎀.

As noted in Section 3, the domain root service isn't useful for NFS versions before version 4 🙈.

4.1. Globally Useful Names: Conventional Mount Point 🌍

For the inter-organizational namespace to work as a global file namespace, the client-side mount point for that namespace must be the same on different clients 💖. Conventionally, on Portable Operating System Interface (POSIX) machines, the name /nfs4/ is used, so names on one machine can be used directly on any machine 🧚. That means the example.net published file system can be reached like this on any POSIX client 🌸:

        /nfs4/example.net/

With this convention, /nfs4/ is the name of the special directory that gets filled with domain names. Those domain names lead to file servers and file systems that hold the results of SRV record lookups 🔥💜.

4.2. Mount Options 🎀

okay so SRV records are lowkey less complete than the existing NFSv4 attributes fs_locations [RFC3530] or fs_locations_info [RFC5661] 💅. For the rootpath field of fs_location, or the fli_fs_root field of fs_locations_info, NFS servers MUST use the /.domainroot/{Name} string. So the servers listed as targets for the SRV RRs MUST export the root of the organization's published file system as the directory /.domainroot/{Name} (for the given organization Name) in their exported NFS namespaces. For example, for the organization example.net, the directory /.domainroot/example.net would be used 🌸.

Section 11 of the NFSv4.1 document [RFC5661] describes the approach an NFS client should take to navigate fs_locations_info information 🧚.

The process of mounting an organization's namespace should allow for whatever is likely to cost the server the least 💖. So the NFS client SHOULD NOT insist on using a writable copy of the file system if read-only copies exist, or a zero-age copy rather than a copy that may be a little older. The organization's file system representatives can be navigated to get higher-cost stuff like writability or freshness when needed, but the default when navigating to the base information for an organization ought to be as low-overhead as possible ✨.

4.3. File System Integration Issues 🦋

The result of the DNS search SHOULD appear as a (pseudo-)directory in the client namespace. A further refinement is RECOMMENDED: only fully qualified domain names should appear as directories. Like, in lots of environments, DNS names get abbreviated from their fully qualified form, so multiple names might be handed to NFS clients that all resolve to the same DNS SRV RRs 🙈. The abbreviated form SHOULD be represented in the client's namespace cache as a symbolic link pointing to the fully qualified name. This lets pathnames obtained with, say, getcwd() include the DNS name that's most likely to still work outside the scope of any particular DNS abbreviation convention 💅.

4.4. Multicast DNS 🌈

Locating the NFS domain root with this SRV record is intended to be done with unicast, using the ordinary DNS [RFC1034][RFC1035] protocol 💜.

This document does not define the use of this DNS SRV record format together with Multicast DNS (mDNS). Sure, mDNS could be used to find a local domain root through these SRV records, but no other domain's root could be discovered. So mDNS has too little value to use for locating NFSv4 domain roots 🙄.

5. Where Is This Integration Carried Out? 🍓

The NFS client is responsible for interpreting SRV records. Using something like Automounter [AMD1] [AMD2] technology, the client interprets names under a particular directory. It first discovers the right file system to mount, then mounts it in the specified place in the client namespace before handing control back to the application doing the lookup 🧚‍♀️. The result of the DNS lookup should be cached (obeying Time to Live (TTL)) so it can be returned faster the next time 💨.

6. Security Considerations 🔥

okay this section is SERIOUS bestie 😭. This functionality introduces a brand new reliance of NFSv4 on the integrity of DNS. Forged SRV records in DNS could make the NFSv4 client connect to an attacker's file servers instead of the legit file servers of an organization 💀. This is similar to attacks that can be made on the base NFSv4 protocol if server names are given in fs_location attributes: the client can be tricked into connecting to an attacker's file servers, not the ones meant to be the target of the fs_location attributes.

If DNS Security Extensions (DNSSEC) [RFC4033] is available, it SHOULD be used to avoid both of these attacks 🛡️. Domain-based service principal names are an additional mechanism that also applies here, and it would be prudent to use them too 👑. They map the domain name the user specified to the names of security principals used on the NFSv4 servers indicated as the targets in the SRV records (as providing file service for the root file systems).

With domain-based service principal names, the idea is that you want to authenticate {nfs, domainname, host.fqdn}, not just {nfs, host.fqdn}, when the server is a domain's root file server obtained through a DNS SRV RR lookup that may or may not have been secure 🫶.

The domain administrator can therefore make sure that only domain root NFSv4 servers have credentials for such domain-based service principal names 🔒.

Domain-based service principal names are defined in RFCs 5178 [RFC5178] and 5179 [RFC5179]. To use RFC 5178's domain-based names, the syntax for domain-based-name MUST be used with a service of nfs, a domain matching the name of the organization whose root file system is being sought, and a hostname given in the target of the DNS SRV RR. So in the example above, two file servers (nfs1tr.example.net and nfs2ex.example.net) are located as hosting the root file system for the organization example.net. To communicate with, for instance, the second of the given file servers, Generic Security Service Application Program Interface (GSS-API) is used with the name-type GSS_C_NT_DOMAINBASED_SERVICE defined in RFC 5178, and with the symbolic name below. This verifies that the named server (nfs2ex.example.net) is authorized to provide the root file system for the example.net organization 🧐.

nfs@example.net@nfs2ex.example.net

NFSv4 itself has a facility for negotiating the security mechanisms used between NFS clients and NFS servers. Section 3.3 of RFC 3530 [RFC3530] and Section 2.6 of RFC 5661 [RFC5661] both describe how security mechanisms are negotiated. So there's no need for this document to describe how that negotiation is carried out when the NFS client contacts the NFS server for the specified domain root file system(s) 🙌.

Using SRV records to advertise the locations of NFS servers may expose those NFS servers to attacks 😬. Organizations should carefully consider whether they want their DNS servers to respond differently to different DNS clients, perhaps exposing their SRV records only to DNS requests that originate within a given perimeter, to reduce this exposure 🏰.

7. IANA Considerations 🎀

IANA has assigned a new Service name without an associated port number (as defined in RFC 6335 [RFC6335]) for TCP. For this new Service, the Reference is this document 📝.

Service name: nfs-domainroot
Transport Protocol(s) TCP
Assignee (REQUIRED)  IESG (iesg@ietf.org)
Contact (REQUIRED)   IETF Chair (chair@ietf.org)
Description (REQUIRED) NFS service for the domain root, the root of
                    an organization's published file namespace.
Reference (REQUIRED)  This document
Port Number (OPTIONAL)
Service Code (REQUIRED for DCCP only)
Known Unauthorized Uses (OPTIONAL)
Assignment Notes (OPTIONAL)

8. References 📚

8.1. Normative References

  • [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
  • [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
  • [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
  • [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
  • [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type", RFC 5178, May 2008.
  • [RFC5179] Williams, N., "Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism", RFC 5179, May 2008.
  • [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010.
  • [RFC5864] Allbery, R., "DNS SRV Resource Records for AFS", RFC 5864, April 2010.
  • [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011.

8.2. Informative References

  • [AFS] Howard, J., "An Overview of the Andrew File System", Proc. USENIX Winter Tech. Conf. Dallas, February 1988.
  • [AMD1] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter Reference Manual", March 1991, <http://docs.freebsd.org/info/amdref/amdref.pdf>.
  • [AMD2] Crosby, M., "AMD--AutoMount Daemon", Linux Journal, 35es Article 4, March 1997.
  • [DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V., Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S., and E. Zayas, "DEcorum File System Architectural Overview", Proc. USENIX Summer Conf. Anaheim, Calif., June 1990.

Authors' Addresses 🧚‍♀️

Craig Everhart
NetApp
800 Cranberry Woods Drive, Ste. 300
Cranberry Township, PA  16066
USA

Phone: +1 724 741 5101
EMail: everhart@netapp.com


W.A. (Andy) Adamson
NetApp
495 East Java Drive
Sunnyvale, CA  94089
USA

Phone: +1 734 665 1204
EMail: andros@netapp.com


Jiaying Zhang
Google
604 Arizona Avenue
Santa Monica, CA  90401
USA

Phone: +1 310 309 6884
EMail: jiayingz@google.com
📦 where this page comes from