On Mon, 2024-02-05 at 15:13 +0000, Chuck Lever III wrote: > > > A DNS label is just a hostname (fully-qualified or not). It > never includes a port number. > > According to RFC 8881, fs_location4's server field can contain: > > - A DNS label (no port number; 2049 is assumed) > > - An IP presentation address (no port number; 2049 is assumed) > > - a universal address > > A universal address is an IP address plus a port number. Therefore > a universal address is the only way an alternate port can be > communicated in an NFSv4 referral. That's not strictly true. RFC8881 has little to say about how you are to go about using the DNS hostname provided by fs_locations4. There is just some non-normative and vague language about using DNS to look up the addresses. The use of DNS service records do allow you to look up the full IP address and port number (i.e. the equivalent of a universal address) given a fully qualified hostname and a service. While we do not use the hostname that way in the Linux NFS client today, I see nothing in the spec that would appear to disallow it at some future time. > The RFC is only about wire protocol. It says nothing about the > server's administrative interfaces; those are always up to the > whim of server developers. > > In NFSD's case, refer= can specify a DNS label (no port), an IPv4 > or IPv6 address (no port), or an IPv4 universal address. This > is because of the punctuation involved with separating the list > of export options, and the punctuation used internally in DNS > labels and IP addresses. > > To add support for other combinations would require code changes. Agreed, and there would also be the major issue of trying to ensure backward compatibility if you were to rely on client behaviour that differs from today. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
