Using DNS SRV to Specify a Global File Namespace with NFS Version 4
Extracted elements (20)
DNS SRV was chosen as the publication mechanism because it allows an organization to advertise its file namespace root to clients that may have no prior knowledge of the organization's server infrastructure, requiring clients to know only the domain name.
Multicast DNS (mDNS) is explicitly not used for domain root discovery. While mDNS could locate a local domain root, it cannot discover any other organization's root, making its value insufficient to justify specifying its use.
The approach mirrors prior global file namespace systems (AFS and DCE/DFS), providing a uniform cross-organizational namespace. NFSv4's fs_locations referral mechanism enables the cross-server namespace while DNS SRV provides the well-known entry point.
The NFS client (using Automounter-like technology) is solely responsible for interpreting SRV records and mounting the indicated file systems. DNS lookup results must be cached obeying the TTL to improve subsequent lookup performance.
The domain root service defined here is not useful for NFS versions prior to version 4, because the fs_locations attribute (required for cross-server referrals) was introduced only in NFSv4.
Abbreviated DNS names that resolve to the same SRV RRs as their fully qualified counterparts SHOULD be represented in the client's namespace cache as symbolic links pointing to the fully qualified name, so that getcwd()-style paths remain universally usable.
For the rootpath field of fs_location or the fli_fs_root field of fs_locations_info, NFS servers MUST use the string "/.domainroot/{Name}".
Future NFS services using protocols other than TCP MUST use a protocol name other than "_tcp" in their SRV records.
NFS servers listed as SRV targets MUST export the organization's domain root file system at the path "/.domainroot/{Name}" (where {Name} is the organization's DNS domain name) within their pseudo-file systems.
The NFS client SHOULD NOT insist on using a writable copy of the domain root file system if read-only copies exist, nor a zero-age copy over one that is slightly older, in order to minimize server overhead.
The result of the DNS SRV lookup SHOULD appear as a pseudo-directory in the client namespace, and it is RECOMMENDED that only fully qualified domain names appear as directory entries.
The "_udp" label MUST NOT be used to imply use of UDP with NFSv4, as neither RFC 3530 nor RFC 5661 defines NFSv4 over UDP.
Domain root file systems are mounted at the conventional POSIX path "/nfs4/" on NFS clients. An organization's published namespace is thus accessible as "/nfs4/{domain}/" on any conforming POSIX client.
The DNS SRV RR service name for NFSv4 domain root is "_nfs-domainroot" and the protocol name is "_tcp". The record format follows RFC 2782: `_nfs-domainroot._tcp.{domain} SRV Priority Weight Port Target`.
When using domain-based service principal names, GSS-API is invoked with name-type GSS_C_NT_DOMAINBASED_SERVICE and a symbolic name of the form "nfs@{domain}@{target-hostname}", e.g., "[email protected]@nfs2ex.example.net".
IANA assigned the new service name "nfs-domainroot" for TCP without an associated port number, per RFC 6335. It designates the NFS service for the domain root — the root of an organization's published file namespace.
Domain-based service principal names (RFC 5178, RFC 5179) SHOULD be used so that authentication verifies {nfs, domainname, host.fqdn} rather than merely {nfs, host.fqdn}, binding the server's identity to the organization's domain name obtained from the SRV lookup.
Forged SRV records in DNS could cause an NFSv4 client to connect to attacker-controlled file servers instead of legitimate ones. This is analogous to attacks via forged fs_location attributes in the base NFSv4 protocol.
If DNSSEC (RFC 4033) is available, it SHOULD be used to prevent DNS record forgery attacks against SRV-based domain root discovery.
Publishing NFS server locations via DNS SRV exposes those servers to targeted attacks. Organizations should consider whether to restrict SRV record visibility to DNS queries originating within a defined network perimeter.