On Wed, 2014-07-09 at 23:06 +0200, Jakub Hrozek wrote:
Hi,
one of our users ran into an interesting problem -- her AD infrastructure was different from the DNS server. Because by default, we perform update against the server we're connected to, the DNS update didn't work.
Per Simo's suggestion, I've implemented a new option that allows the administrator to override the DNS server used for DNS updates.
I am not sure I like the premises here.
The problem is that we are trying to set a DNS server at all in the normal case. The normal case should be that nsupdate is not passed any server name and it discovers the correct server via normal DNS lookup queries.
If someone is using a messed up DNS setup then, yeah I would offer a setting for specifying exactly what DNS server to contact, but I am not sure it makes sense to fallback to a random Domain Controller by default.
IIRC the cldap ping reply does return you information on whether the domain controller is also a DNS server, I think we need to extract that info and keep it around, and fallback to directly contact the domain controller only if the cldap ping indicated DNS support.
Comments on code follow:
I think I would change the following: + <para> + Setting this option makes sense for environments + where the DNS server is different from the identity + server. + </para>
I think you should say something like this: "Set this option if your DNS environment is broken and the correct server cannot be discovered via regular DNS lookups."
On the code side I think you are missing to remove the code in ad_dyndns.c:ad_dyndns_update_send() that unconditionally sets stat->servername, by default no server name should be set.
Exactly the same issue is present in ipa_dyndns.c:ipa_dyndns_update_send(), once again the current freeipa server name is taken as a DNS server. And once again not all IPA servers are DNS servers. Here too we need to remove all the code that sets the server name and let nsupdate find the server through the normal dns lookup queries or use the dyndns_server fallback if set.
Using unconditioanlly a domain controller you are randomly bound to is normally more wrong than right and we should stop doing that completely.
So NACK, for now.
Simo.