On Wed, Jul 22, 2015 at 02:09:18PM +0200, 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
The page matches what we discussed yesterday in a private conversation. Thank you for bringing it to the list! _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
