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

[Martin Basti]

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