On 22.7.2015 14:09, Pavel Reichl wrote: > > > On 07/10/2014 10:30 AM, Simo Sorce wrote: >> 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. >> > Hello, > > I've discussed this ticket and Simo's comments off list with Jakub and Petr > Spacek. Please see linked design page which is result of the conversation. > Please comment here or directly edit the page. > > Thanks! > > https://fedorahosted.org/sssd/wiki/DesignDocs/DDNSMessagesUpdate > > ///////////////////////////////////////////////////////// > ///////////////////////////////////////////////////////// > ///////////////////////////////////////////////////////// > = DDNS - update quality of input for nsupdate = > > Related ticket(s): > * https://fedorahosted.org/sssd/ticket/2495 > > === Problem statement === > SSSD provides input to nsupdate that's redundant and might actually impair > proper resolution using DNS. Further, format of messages pasted to nsupdate is > grouped by command type - deleting and adding addresses are two separate > batches which is not optimal as update of one of address families might be > prohibited to be changed on server. > > === Use cases === > If DNS system is broken using dyndns_server option might be an workaround > > === Overview of the solution === > * Allow SSSD to add a new option that would specify which server to update DNS > with ('dyndns_server') > * In first attempt to perform DDNS '''do not specify zone/server/realm''' > commands in input for nsupdate (nsupdate will then utilize DNS) > * As fallback (if first attempt fails) specify realm command and if > 'dyndns_server' option is specified then also add server command with value of > 'dyndns_server' > * Bulk deleting and adding addresses from the same address family into one > batch rather then grouping by command type > > === Implementation details === > * Remove servername and dns_zone parameters from sdap_dyndns_update_send() as > they are no longer used. Remove code from AD and IPA provider which was > passing this data to sdap_dyndns_update_send(). > * Remove dns_zone field from struct sdap_dyndns_update_state and remove all > code relating to it. > * In sdap_dyndns_update_done() make setting command realm conditional same way > as command server is. > * Update nsupdate_msg_add_fwd() to group commands by address family processed > IP belongs to. > > === Configuration changes === > New option dyndns_server > > === How To Test === > Check that IP addresses get changed in IPA and on AD. Break DNS resolving to > force first attempt of DDNS to fail. Check that messages generated as input > for nsupdate in domain logs are matching the expectation. > > ==== Example of expected format of messages ==== > '''First attempt''' > {{{ > update delete husker.human.bs. in A > update add husker.human.bs. 1200 in A 192.168.122.180 > send > update delete husker.human.bs. in AAAA > update add husker.human.bs. 1200 in AAAA 2001:cdba::666 > send > }}} > '''Fallback attempt''' > {{{ > ;sever is present only if option dyndns_server is set in sssd.conf > server 192.168.122.20 > ;realm is used always in fallback message > realm IPA.WORK > update delete husker.human.bs. in A > update add husker.human.bs. 1200 in A 192.168.122.180 > send > update delete husker.human.bs. in AAAA > update add husker.human.bs. 1200 in AAAA 2001:cdba::666 > send > }}} > === Authors === > prei...@redhat.com
LGTM -- Petr^2 Spacek _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
