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

[David Kupka]

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

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.

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

-- 
David Kupka