Subject: [nfsv4] NFSv4 Global namespace: joining NFSv4 domains with a new DNS nfsv4 SRV.

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Thu, 19 Jan 2006 14:25:24 -0500

fs_locations referals enables an implementation of an NFSv4 administrative 
domain wide namespace.  the administrators of an NFSv4 domain have the role to 
decide on namespace topology and it's clear that they are an authority that 
can provide appropriate fs_locations values for domain wide namespace 
construction.

the use of fs_locations to join NFSv4 administrative domains is problematic in 
that it requires long term agreement and cooperation between domains. a server 
in NFSv4 domain 'A' that provides a namespace junction to NFSv4 domain 'B' 
will need to get B's fs_location info from domain B adminstrators. what are 
the rules? who checks for circular referals? if domain B is only accessable 
from domain A what happens when domain A servers are unavailable? etc.

CITI proposes the use of a new DNS nfsv4 SRV record used to construct an 
AFS-like namespace for NFSv4, where the first level of the namespace consists 
of NFSv4 domain names (akin to AFS Realm names) resolved by the new DNS nfsv4 
SRV record.

here is an example path name;

/nfs4/NFSv4-domain/foo/bar/....

- "/nfs4" is the (local) root of the global namespace. (just like /afs)

- "NFSv4-domain" is flat - one entry per NFSv4-domain participating in the 
naemspace.  traversing from "/nfs4" into "NFSv4-domain" kicks of a DNS query 
for the domains DNS nfsv4 SRV record. the record will contain the nfsv4 server 
name(s) exporting the root of the NFSv4 domain namespace.

- "foo" and all namespace under it is in "NFSv4-domain" and is resolved via 
fs_locations.

i would like to see the DNS nfsv4 SRV record defined, and added to the NFSv4.1 
minor version as an official way to join NFSv4 administrative domain 
namespaces.

-->Andy

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Jiaying Zhang" <[email-masked]>
Date: Thu, 19 Jan 2006 15:11:15 -0500

Following Andy's introduction, I put the format used in our current 
implementation
here as a reference:

The format of the SRV RR is
    service.proto.name TTL class SRV priority weight port target,
where service is the symbolic name of the desired service;
proto indicates the transport protocol type, typically either TCP or UDP;
name is the DNS domain name this RR refers to;
priority sets the preference for a host specified in the target field;
weight can be used in addition to priority for load balancing when
multiple servers specified in the target field have the same priority;
port is the server port on the target host that provides this service;
and target specifies the DNS domain name of the host that provides
the type of service being requested.

In our current implementation, suppose a user types
    > ls /nfs/umich.edu/lib/file1
on a NFS client. We have the lookup request for entry umich.edu forwarded
to a  special daemon which then performs a DNS query with nfs.umich.edu as
the lookup name and SRV as the lookup type. Suppose the DNS server in the
University of Michigan contains the following entry:

        nfs IN SRV 0 0 2049 nfs1.umich.edu
            IN SRV 1 0 2049 nfs2.umich.edu

The queried results nfs1.umich.edu and nfs2.umich.edu indicate the server
locations of the NFS file system provided by the University of Michigan.
Upon receiving the queried results, client selects the server with the 
lowest priority
number, i.e., nfs1.umich.edu:/ in this example, and mounts it at directory 
/nfs/umich.edu.
The subsequent access under /nfs/umich.edu directory is then the same as 
normal NFS access.

- Jiaying

----- Original Message ----- 
From: "William A.(Andy) Adamson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 19, 2006 2:25 PM
Subject: [nfsv4] NFSv4 Global namespace: joining NFSv4 domains with a newDNS 
nfsv4 SRV.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Jan 2006 14:39:42 -0600

IIRC I've advocated this before.  Use DNS to locate the NFSv4 root of a
domain.  The client can have a /nfsv4 pseudo-filesystem where traversing
a domain name causes the mounting of the domain's NFSv4 root.  Or not;
this is up to the client.  What really matters is being able to find a
domain's root, because from there referrals can handle the rest.

Nico
--

---

From: Carl Burnett <[email-masked]>
Date: Thu, 19 Jan 2006 16:10:12 -0600

Just a comment that an NFS server could also leverage such a record in DNS 
and then refer the requesting client to the root of the foreign domain. In 
this case, the client just discovers the set of root servers for its home 
domain and then mounts the NFS pseudo root of one of the root servers.

Regardless of how and where its accessed from, the notion of a standards 
based NFSv4 domain root record would add great value to NFSv4 for 
federating collections of NFSv4 domains.

Carl

Carl Burnett
AIX Kernel Architecture - Network File System
(512) 838-8498, TL 678-8498
(please reply to [email-masked])

"Jiaying Zhang" <[email-masked]> 
Sent by: [email-masked]
01/19/2006 02:11 PM

To
<[email-masked]>, "William A.\(Andy\) Adamson" <[email-masked]>
cc
[email-masked]
Subject
Re: [nfsv4] NFSv4 Global namespace: joining NFSv4 domains with a newDNS 
nfsv4 SRV.

/nfs/umich.edu.

- Jiaying

----- Original Message ----- 
From: "William A.(Andy) Adamson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 19, 2006 2:25 PM
Subject: [nfsv4] NFSv4 Global namespace: joining NFSv4 domains with a 
newDNS 
nfsv4 SRV.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Jan 2006 17:00:35 -0600

Also, recall that there is a security consideration here: that the use
of RPCSEC_GSS and GSS_C_NT_HOSTBASED_SERVICE type names for servers
named in SRV records does nothing to make up for the lack of DNSSEC,
when one does not use DNSSEC.

That is, if the client is not using DNSSEC or if it accepts responses
from insecure zones, then the client may be redirected from such a
domain's root servers to any other NFSv4 server.

Solutions to this include:

 - use DNSSEC
 - use domain-based service principal names for domain root NFSv4 servers

Nico
--

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 25 Jan 2006 22:11:23 -0600

> minor version as an official way to join NFSv4 administrative domain 

Great to see the interest (personally, I am interested as well).

So the above statement is the key.  Someone with the time needs to put
together an I-D as the starting point for further discussion and movement
towards and RFC.  Since the current proposal is a DNS SRV record, it would
not strictly be part of the NFS4.1 specification but certainly could
run in parallel to ensure that if language needs to be present in the
4.1 specification that it is place appropriately and in a timely fashion.

Any volunteers?  If not, the great idea doesn't move forward.

Spencer

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 26 Jan 2006 11:38:57 -0500

I think it would have to progress in the DNSEXT WG. I suppose I could be 
the stuckee.

-- 
Eric Brunner-Williams
Software Engineer, Performance, Panasas Inc
Accelerating Time to Results(tm) with Clustered Storage

www.panasas.com
[email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 26 Jan 2006 10:51:14 -0600

> I think it would have to progress in the DNSEXT WG. I suppose I could be 

Why?  Kerberos V (RFC4120) makes use of DNS RRs and didn't have to go
through the DNS WG.

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 26 Jan 2006 12:28:46 -0600

The NFSv4 WG will shepard the draft through the process and will certainly
look for input/review from the DNSEXT wg but as Nico mentions, they don't
have to own the document...