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

[Petr Spacek]

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