Re: [RFC PATCH 0/1] Create a DNS SRV record of the ID mapping domain

[Steve Dickson <SteveD@redhat.com>]

Hello,

On 05/23/2016 01:22 PM, Chuck Lever wrote:
> 
>> On May 23, 2016, at 12:18 PM, Steve Dickson <SteveD@redhat.com> wrote:
>>
>> I have a customer that requested the domain used
>> to do the ID mapping be available via DNS SVR 
>> record. I didn't think was that bad of an idea.
> 
> Solaris NFS peers look for a TXT record. This
> facility has been around for a decade or more.
> 
> ;; NFSv4 domain (for idmapping).  See Sun doc 819-1634 and
> ;;      http://tools.ietf.org/html/draft-mesta-nfsv4-domain-01.html
> _nfsv4idmapdomain               IN TXT          "oracle.com"
I see... Looks reasonable
 
> 
> But there's no standard in this area. mesta-nfsv4-domain
> was a personal I-D that never advanced. I brought it
> up again in Orlando, and the WG decided to table it.
> 
> At the time it was decided that the right course of
> action was for the NFSv4 idmapping domain to be set
> based on security realm or other criteria. There was
> no interest in involving DNS at all.
Hmm... it seems pretty convenient to me... although
its just another place for rpc.idmap to get hung. ;-)

> 
> 
>> IPA and FedFS use SRV records which seem to work out
>> pretty well. This patch is heavily based on the 
>> FedFS code. ;-) 
>>
>> My only question is do we want libnfsidmap to be
>> dependent on the resolver library. There has been
>> some talk about moving libnfsidmap into nfs-utils
>> which means nfs-utils would be dependent the
>> resolver library. 
>>
>> Note, this is not complete. If we are going to do
>> this I have to document it somehow, either in 
>> the man page or idmap.conf or both.
>>
>> Just looking for thoughts... good/bad idea??
> 
> If you really do want to go down this path, I
> think Linux should follow the existing de facto
> standard (TXT), not invent its own. Maybe also
> check how SMB does this.
I think I will and I agree using a TXT RR is
the way to go... Why reinvent the wheel?? 8-) 
 
> 
> Involving a published DNS record format should
> require standards action. But I was discouraged
> from pursuing this further.
I think if everybody is doing the same thing
would be good enough...

> 
> I think it's important to ask in what cases
> will the ID mapping domain be different than
> the system's DNS domain name, and is there a
> preferable mechanism for determining the ID
> mapping domain in those cases? Knowing more
> about how your customer plans to use this
> feature would help us discuss this more fully.
This would help me here at Red Hat. I live
on at (eat your own dog food) test network 
that has its own DNS 

So steved@redhat.com maps into a valid id/gid but 
steved@devel.redhat.com  does not so I need to add a 
Domain=redhat.com in /etc/idmapd.conf to get
v4 working. Having the domain in our test DNS 
would work out well.

Also, the person that is asking for this is
probably moving from a Solaris env to Linx
env... That's just a guess. 

> 
> I've also proposed the ability to set the ID
> mapping domain via a command line tool like
> nfsidmap. But I never got past the difficulties
> of parsing and updating the /etc/idmapd.conf
> file. It makes sense to add an API to libnfsidmap
> for setting the system's ID mapping domain name.
Does having the domain in DNS help with this? I'm
thinking not... 

> 
> How would "nfsidmap -d" work if the ID mapping
> domain was set via DNS?
I guess we would have to teach nfs4_get_default_domain()
to check DNS like nfs4_init_name_mapping() would.

> 
> Would the DNS-derived ID domain name be cached
> somewhere?
Currently its stored in the global default_domain
variable in libnfsidmap... I think its a good
place for it to live. 

steved.