Bug in the resolution of SOA records for DDNS updates?

[Uwe Meyer-Gruhl]

There seems to be a bug in the resolution of SOA records for DDNS 
updates, or I am missing something essential here?

I use this setup for doing reverse DDNS updates only:

ddns-updates on;
ddns-update-style interim;
allow client-updates;
update-static-leases on;
update-optimization off;
do-forward-updates off;

The bug concerns the zone declarations. A full zone declaration can 
include something like a primary DNS server and a TSIG key reference:

zone 3.2.10.in-addr.arpa. {
     primary 10.2.3.13;
     key XYZ;
}

Since I do not use TSIG keys for authorization, thus the key is 
unneeded. Also, the comments in common/dns.c say that the primary server 
for a zone is found by looking up its SOA records, so that no zone 
declaration should be needed at all. However, if you leave it out or 
make an empty zone declaration, you get this kind of error:

Jul 30 19:22:17 blob dhcpd: DHCPDISCOVER from 00:26:2d:ff:2b:55 via br0
Jul 30 19:22:17 blob arpwatch: 0-source 0.0.0.0 0:26:2d:ff:2b:55
Jul 30 19:22:18 blob dhcpd: DHCPOFFER on 10.2.3.249 to 00:26:2d:ff:2b:55 
(t410s) via br0
Jul 30 19:22:18 blob dhcpd: DHCPREQUEST for 10.2.3.249 (192.168.10.3) 
from 00:26:2d:ff:2b:55 (t410s) via br0
Jul 30 19:22:18 blob dhcpd: DHCPACK on 10.2.3.249 to 00:26:2d:ff:2b:55 
(t410s) via br0
Jul 30 19:22:18 blob dhcpd: Unable to add reverse map from 
249.3.2.10.in-addr.arpa. to t410s.testdomain: not found

During the DHCP address assignment, there are no DNS activities by DHCPD 
whatsoever. The daemon does not even try to find the SOA for the 
3.2.10.in-addr.arpa domain. In order to make the DDNS update work, you 
have to specify the primary server via a zone declaration. This has the 
obvious disadvantage of having to mirror the DNS structure in DHCP, 
since it is also impossible to just create a top-level zone like this:

zone 10.in-addr.arpa. {
     primary 10.2.3.13;
}

In the latter case, all DDNS updates are done as PTR entries like 
"249.3.2" in the zone "10.in-addr.arpa", which does not function if the 
Class C subzones are delegated and no updateable parent zone 
"10.in-addr.arpa" exists.

I have noticed similar behavior when trying to update forward zones.