DDNS handling of "dumb" DHCP clients

[Uwe Meyer-Gruhl]

I have a question regarding handling of DDNS updates for "dumb" 
non-Windows DHCP clients (e.g. printers):

As far as I understand the documentation, the sole supported DDNS update 
style is "interim", so I only tried that:

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

host printer {
     ...
     ddns-hostname printer;
     ddns-domainname print.mydomain.net;
}

Forward and reverse DDNS zones are configured, too.

With interim DDNS mode, the client sends DHCPDISCOVER or DHCPREQUEST. 
This packet MAY include an FQDN option (DHCP option 81) which can ask 
for the client wanting to update the forward map by itself by setting a 
bit. If the FQDN bit is unset or option 81 is missing at all, this is a 
sure sign that the client cannot handle the forward DDNS update by itself.

With "ignore client-updates", the DHCP server can even instruct capable 
clients not to do the update by themselves.

In all of the cases where the client does/can/should not handle the 
forward update itself, I would expect the DHCP server to do it, 
especially if "do-forward-updates" is "on". However, I find that if 
"ignore client-updates" is configured, the DHCP server does not do 
forward DDNS updates (which in turn prevents reverse updates, too).

But, even if "allow client-updates" ist configured, the presence of an 
FQDN option is needed in order to initiate a forward update. I had 
expected that the configuration of "ddns-hostname" and "ddns-domainname" 
would suffice instead of an FQDN coming from the client. My host entries 
are generated from a database, because it knows better than the clients 
what their DNS names are (or should be). Being able to override the 
client-provided DNS names is a crucial feature, IMHO, but the dhcpd.conf 
man page describes that mechanism only for the deprecated ad-hoc style:

       "For the ad-hoc DNS update method, the client's FQDN is derived  in  two
        parts.    First, the hostname is determined.   Then, the domain name is
        determined, and appended to the hostname.

        The DHCP server determines the client's hostname by first looking for a
        ddns-hostname   configuration  option,  and using that if it is present.
        If no such option is present, the server looks for a valid hostname  in
        the  FQDN option sent by the client.  If one is found, it is used; oth-
        erwise, if the client sent a host-name option, that  is  used.   Other-
        wise,  if  there  is a host declaration that applies to the client, the
        name from that declaration will be used.  If none of these applies, the
        server will not have a hostname for the client, and will not be able to
        do a DNS update.

        The domain name is determined based strictly on the  server  configura-
        tion, not on what the client sends.   First, if there is addns-domain-
        name  configuration option, it is used.   Second, if there is adomain-
        name   option  configured, that is used.  Otherwise, the server will not
        do the DNS update."


Essentially, I have not managed to make a "dumb" DHCP client work with 
letting the DHCP server do all the DDNS updates for it. There always has 
to be an FQDN option that must come from the client. There are plenty of 
configuration options that seem to handle everything I need, but I have 
not figured out how to do it.

Is this possible at all?