X-Mailer: MIME-tools 5.508 (Entity 5.508)
Content-Transfer-Encoding: binary
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Subject: Use of dns_client_startupdate() in DHCP-4.4.1 [ISC-support #13028]
Content-Disposition: inline
To: dhcp-public@isc.org
Message-ID: <rt-4.4.1-73941-1528722024-509.0-0-0@isc.org>
X-RT-Interface: Web
From: cathya@isc.org
Date: Mon, 11 Jun 2018 13:00:24 +0000
X-RT-Original-Encoding: utf-8
Content-Length: 1432

As reported to ISC Support:

In the following code of dhcp3/common/dns.c:ddns_modify_fwd()

	/* send the message, cleanup and return the result */
	result = ddns_update(dhcp_gbl_ctx.dnsclient,
			     dns_rdataclass_in, zname,
			     &prereqlist, &updatelist,
			     zlist, tsec_key,
			     DNS_CLIENTRESOPT_ALLOWRUN,
			     dhcp_gbl_ctx.task,
			     ddns_interlude,
			     (void *)ddns_cb,
			     &ddns_cb->transaction);

I suspect 'DNS_CLIENTRESOPT_ALLOWRUN' should actually be 0.
ddns_update() is essentially a wrapper for dns_client_startupdate(),
and according to its documentation contained in the tar ball of
BIND-9.11.2-P1, the options should be named 'DNS_CLIENTUPDOPT_xxx'.
Besides, ALLOWRUN flags seem to only matter for the 'synchronous' mode
(e.g. dns_client_update()) so it shouldn't make much sense anyway.

Previously, such as in DHCP-4.3.3, it didn't have any real effect
since it used older versions of BIND 9 libdns that doesn't recognized
any options in dns_client_startupdate().  But it now uses BIND 9.11.2,
which has a couple of options for dns_client_startupdate(), and the
value of DNS_CLIENTRESOPT_ALLOWRUN is actually the same as
DNS_CLIENTUPDOPT_TCP.  So it would now change the behavior.

Note: this is just an observation from code inspection I happen to
notice when I tried to run an older ISC-DHCP with newer BIND 9
library.  But it looks like the self-contained DHCP-4.3.3 has the same
issue.