Learn more about these different git repos.
Other Git URLs
Currently a client can set only its A/AAAA record (enforced by ACLs). But it can't set the PTR record, as it is impossible to properly construct an ACL to allow that for the specific reverse zone.
The plugin should have magic code that does it on behalf of clients, so that A/PTR records pairs are kept in sync (where possible).
But, because clients can be in foreing private networks (and can also lie) they can't be trusted. So PTR modification must be done carefully.
This is the procedure:
1. get A/AAAA change request and perform update if allowed 2. search the corresponding PTR 3. check if the record it points to is still valid (an A/AAAA record exist) 4. if not modify the PTR 5. if it exist throw a warning and do not update the PTR 6. check if the old PTR (corresponding to the previous A/AAAA value for the client) is now orphaned. 7. if it is remove the old PTR value (use an LDAP delete operation specifying the old value to avoid races between 2 clients trying to update the same PTR).
Fixed by
http://git.fedorahosted.org/git/?p=bind-dyndb-ldap.git;a=commit;h=06256bdf4cd769badcc9bc5ff1998e5838b52746 http://git.fedorahosted.org/git/?p=bind-dyndb-ldap.git;a=commit;h=6a69af2d78e56bb75a373d8809dcbc373e995d62
It is necessary to investigate race-safety in current code. Delete operation in step 7 is not atomic as Simo proposed.
Metadata Update from @jkuncar: - Issue assigned to jkuncar - Issue set to the milestone: The Backlog
Login to comment on this ticket.