Bug 1385515

... and of course taking care about updating SRV entries on replication topology changes

In general, SRV records should be present only in single DNS zone. Clients should find name of the "main" IPA zone from _kerberos TXT record, which is automatically created by IPA. This avoids copying which is error-prone (and next to impossible when some zones are managed by IPA and some others don't).

OpenLDAP client libs derive DNS domain name from base DN, so pure LDAP client is covered as well. nss-pam-ldapd has "uri" options which is used to specify domain name so it is covered.

What is your use case?

We determined that standard procedures listed in comment #3 covers all reasonable cases we were able to to come up.

Comment #3 does not fix the problem. The ipa-client-install is not able to find LDAP server.

Logs are needed to evaluate

So far for separate dns zones ipa-client-install requires specifying --domain <main IPA domain>.
As Alexander pointed out over IRC the man page for ipa-client-install covers this use-case:

#############

       --domain=DOMAIN
              The primary DNS domain of an existing IPA deployment, e.g. example.com. This DNS domain should contain the SRV records generated by the IPA server installer. Usually the name is a lower-cased
              name of an IPA Kerberos realm name.

              When no --server option is specified, this domain will be used by the installer to discover all available servers via DNS SRV record autodiscovery (see DNS Autodiscovery section for details).

              The default value used by the installer is the domain part of the hostname. This option needs to be specified if the primary IPA DNS domain is different from the default value.

#############

It looks like what should be done there is for ipa-client-install to determine the domain from the _kerberos TXT record as explained in comment#3 when --domain is not specified.
Nothing needs to be done server-side.

Luc, does the above sound good enough to you?

(In reply to François Cami from comment #15)
> Luc, does the above sound good enough to you?

Hi François,

I only see one problem with that: For the hjost server123.subdomain.example.com it will create a DNS entry like server123.subdomain in the example.com domain which is not something that is nice, its getting difficult to migrate that pseudo-subdomain to another DNS server if needed. 

What will be the behaviour when the domain subdomain.exmple.com exists in IPA? I did not tried that yet.

Thanks,

Luc

Hi Luc,

This should not happen.

If the subzone $subzone.$IPAdomain is created beforehand, the client will try to create a DNS entry in the subzone.

To create a subzone with dynamic updates enabled:
#################
$ ipa dnszone-add $subzone.$IPAdomain.
$ ipa dnszone-mod $subzone.$IPAdomain. --dynamic-update=True
#################

The nsupdate commands sent by the client will be:
#################
update delete <short_hostname>.$subzone.$IPAdomain IN A
show
send

update delete <short_hostname>.$subzone.$IPAdomain IN AAAA
show
send

update add <short_hostname>.$subzone.$IPAdomain 1200 IN A <IP>
show
send
#################
(search for 'nsupdate' in ipaclient-install.log).

I've just verified, the resulting entry is created in the subzone in this case.

Thanks for confirming!
François

(In reply to François Cami from comment #17)
> Hi Luc,
> 
> This should not happen.
> 
> If the subzone $subzone.$IPAdomain is created beforehand, the client will
> try to create a DNS entry in the subzone.
> 
> To create a subzone with dynamic updates enabled:
> #################
> $ ipa dnszone-add $subzone.$IPAdomain.
> $ ipa dnszone-mod $subzone.$IPAdomain. --dynamic-update=True
> #################
> 
> The nsupdate commands sent by the client will be:
> #################
> update delete <short_hostname>.$subzone.$IPAdomain IN A
> show
> send
> 
> update delete <short_hostname>.$subzone.$IPAdomain IN AAAA
> show
> send
> 
> update add <short_hostname>.$subzone.$IPAdomain 1200 IN A <IP>
> show
> send
> #################
> (search for 'nsupdate' in ipaclient-install.log).
> 
> I've just verified, the resulting entry is created in the subzone in this
> case.
> 
> Thanks for confirming!
> François

Hi François,

It would be nice to document this that the subdomain must exist before the first host in that particular domain is enrolled. 
Also, IMHO, the ipa-client-installer (DNS part) should fail with an error message hinting to that issue.

Thanks,

Luc

> It would be nice to document this that the subdomain must exist before the first host in that particular domain is enrolled. 

Well $shortname.$subzone is a valid zone entry in BIND (I've just tested) though it's arguably awkward.
IDM is not doing anything different than BIND itself so it's not a MUST item.

Granted RFC952 ( https://tools.ietf.org/rfc/rfc952.txt ) defines a hostname this way: 
 <hname> ::= <name>*["."<name>]
 <name> ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
but I could find no hard requirement on zone entries not having any dot in them if not ending with a dot.

> Also, IMHO, the ipa-client-installer (DNS part) should fail with an error message hinting to that issue.

Possibly.
With that said, ipa-client-install does not fail nor display any warning when nsupdate fails entirely: since the zone might prohibit updates or even not be under IDM direct control we cannot consider nsupdate failures as critical. 

Also, the nsupdate built by ipa-client-install is "update add <short_hostname>.$subzone.$IPAdomain 1200 IN A <IP>".
To display that warning we would have to detect the subzone does not exist first and act on that.
Let me think about it and get back to you.

Setting NEEDINFO on myself.