[Freeipa-devel] behavior change in DNS dynamic updates: #155

[Martin Basti]

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

> 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
>


-- 
Martin Basti