On 1 Apr 2014, at 09:52, Marty Lee 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 Directorv: +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
