On 29.4.2015 16:06, Martin Basti wrote: > On 29/04/15 16:05, Martin Basti wrote: >> On 29/04/15 15:40, David Kupka wrote: >>> On 04/29/2015 02:27 PM, Petr Spacek wrote: >>>> Hello, >>>> >>>> I would like to discuss behavior change which is need for fixing ticket >>>> https://fedorahosted.org/bind-dyndb-ldap/ticket/155 >>>> "PTR record synchronization for A/AAAA record tuple can fail mysteriously" >>>> >>>> Current behavior >>>> ================ >>>> Currently DNS clients receive SERVFAIL error if A/AAAA record is updated >>>> but >>>> respective reverse zone is not configured on the same IPA server. >>>> See https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/SyncPTR for >>>> details. >>>> >>>> >>>> Change proposal >>>> =============== >>>> It seems to me that #155 is not fixable without following behavior change: >>>> Client will *not* receive an error if reverse zone is not configured. >>>> >>>> Would it be okay to do this change and *do not report an error if >>>> respective >>>> reverse zone is not configured*? >> Just for clarification: >> If any A/AAAA record update failed, server will return SERVFAIL and rollback >> changes >> If all A/AAAA records were successfully added, just SRV record is not >> created by dyndb-ldap, server returns NOERROR > > s/SRV/PTR > sorry
Yes, this is correct. It seems like agreement so I will fix #155 as described above. It turned out that #155 is a prerequisite for #151. I really like spaghetti! ;-) Petr^2 Spacek >> nsupdate contains A/AAAA/PTR record, if PTR record update failed, server >> will return SERVFAIL and rollback changes. >> >> Right? >>> >>> Yes. Client has always chance to check if the reverse records were created >>> or not. Additionally client only tries to add A/AAAA records and doesn't >>> know if there are any reverse zones or not. >> Yes. Client has no information that PTR records should be created too. >> We can just shown warning, the client has no reverse record (we need to >> decide if this is right approach) >>> >>>> >>>> >>>> I think that it could be actually less confusing because it might be an >>>> intentional configuration, too. >>>> >>>> E.g. the IPA DNS server might be responsible only for 2 zones: >>>> - example.com. >>>> - 2.0.192.in-addr.arpa. >>>> but it does not mean that the zone 'example.com.' cannot contain A/AAAA >>>> records belonging to other reverse zones. >>>> >>>> Currently any attempt to update A/AAAA record which does not belong to >>>> reverse >>>> zone '2.0.192.in-addr.arpa.' ends with SERVFAIL message and terminates the >>>> update prematurely. >>>> >>>> >>>> Technical details >>>> ================= >>>> BIND internally splits update message with multiple requests (e.g. request >>>> to >>>> add multiple A/AAAA records) to steps where one step is does 1 change in 1 >>>> resource record at a time. Our plugin can see only separate steps and not >>>> the >>>> whole update message. >>>> >>>> Failure in any step terminates the update completely, rest of the update >>>> message is not processed and error is returned to the client. On the other >>>> hand, we have no information beforehand if the currently processed step is >>>> the >>>> last one or not so it is impossible to reliably implement 'this update is >>>> the >>>> last one, report the error here' logic. >>>> >>>> I do not see a way to change this without changes to BIND internals and >>>> IMHO >>>> it is not worth the effort. >>>> >>>> >>>> Thank you for your time! >>>> >>> >> >> CCing Jakub as this can hit SSSD. >> Martin^2 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code