On 1 Apr 2014, at 09:52, Marty Lee <ma...@maui-systems.co.uk> wrote:
> > Ok, finally managed to get a test rig set up with wireshark and have > now seen more about what’s going on & can see the pre-requisites going > over the wire. > > Versions: ISC DHCPD 4.2.6, Bind 9.9.5 > > DHCPD sends a dynamic update with a pre-req that the name doesn’t exist > Bind replies with a fail, as the name does exist > > DHCPD then sends a new dynamic update with a pre-req that the TXT record > exists > Bind replies with a success, however: > - within the packet are 2 updates > - 1st is to remove the original ‘A’ record > - 2nd is to add the new ‘A’ record > - Bind calls the dlz ‘dlz_subrdataset’ but not the ‘dlz_addrdataset’ for the > 2nd update record > > End result, is that once the TXT record exists, Bind 9.9.5 just tries to > delete the A > record from the update and doesn’t create the new one. > > So - looks like something is up with the Bind code, so I’m off to have a look > at that; > especially now I can play with all of this on a test network and it’s 100% > repeatable. Bind (update.c) gets the update request and iterates through the records. It processes the request to delete the A record, then processes the ‘add’ record; so far so good - I had thought it might just be doing record 1 and ignoring the rest. The code for the ‘add record’ calls ‘add_rr_prepare_action’, which queries the DNS data to see if the record already exists, and if it does, there is a comment : ‘the update should be silently ignored’. Looking at the DLZ methodology, the process flow is: - newversion - add/subtract records - closeversion (commit flag) which maps nicely to a database transaction; new version starts the transaction and has a user supplied ‘version’ parameter, in which I can pass a structure to identify the db connection in use. Adds/subtracts have the ‘version’ parameter, so get processed with the same db connection that started the transaction, so integrity is fine. When closeversion is called, I can take the ‘version' parameter and then call ‘ROLLBACK’ or ‘COMMIT’ as appropriate. The problem is the following: * transaction gets started * the delete is processed within the scope of the transaction * the ‘add’ is processed but the add_rr_prepare_action function calls a DNS lookup outside of the scope of the transaction, so the database record still exists as the transaction is still open. The ‘add_rr_prepare_action’ function assumes it can silently ignore the add as the record exists. * The commit then happens, and the ‘delete’ is now applied to the database. End result, is that the new ‘A’ record is never added. I would question the fact that the code silently skips adds without even a debug level message - or maybe it’s just because that small piece of very significant debug information would have led me straight to the issue! Anyway, now I understand why Bind is ignoring that ‘add’, I can look at my DLZ and the interfaces supplied, to see if there is anything I can do from the DLZ, or whether I need to track a transaction through some other mechanism than the database, and get add/delete to apply directly to the DB records. My guess, is that the ‘version’ from the transaction should be passed through to dlz_lookup as an optional parameter; if set, then any lookups could then be done in the scope of the transaction, and thus return correct information. I just need to track down how to make that happen, or maybe, if it’s already there and I just haven’t found it yet. Hopefully this explanation of what’s going on gets logged on the Bind mail archive, and the next poor soul that tries to play with DLZ and Dynamic DNS will find it… Cheers marty ----- Marty Lee e: ma...@maui-systems.co.uk Technical Director v: +44 845 869 2661 Maui Systems Ltd f: +44 871 433 8922 Scotland, UK w: http://www.maui-systems.co.uk
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
