On 04/29/2015 02:27 PM, Petr Spacek wrote:
I would like to discuss behavior change which is need for fixing ticket
"PTR record synchronization for A/AAAA record tuple can fail mysteriously"
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.
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:
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
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!
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code