The problem I was trying to resolve is the following : a laptop can connect wirelessly on one C-class network, or wiredly on another C-class network. A same DHCP server distributes leases on clients of both networks, with fixed IP addresses based on the network card hardware address. A DNS server provides two distincts names for each IP address (laptop.localnet. and laptop.wlan.localnet. for example).
This situation is cumbersome for at least two reasons:
So I decided to configure a dynamic DNS, feeded by the DHCP server, upon sollicitation from DHCP clients. The recommended DDNS style is interim, and in this scheme, two behaviours are possible : the reverse maps (IP address to hostname) are updated by the DHCP server to the DNS server in all cases, but the forward map can be updated upon request either by the DHCP client itself, or by the DHCP server.
On the security point of view, a DDNS update is possible if the DNS server and the update requester share a common static secret key (a TSIG key). If clients are allowed to update their forward map, then the TSIG key has to be spread on each client (in /etc/dhclient.conf), else only the DHCP server need to know the key (in /etc/dhcpd.conf).
The moment when forward and reverse DNS maps are updated is another important point of interest. The DNS records are not removed from the DNS server, when a machine disconnects from the network. When a machine connects to the network, both forward and reverse maps need to be updated. It is considered safe to update the reverse map without further verification, because the DHCP is in charge to ensure that the allocated IP address is not used by another machine, so updating the reverse map cannot steal someone else's identify. Updating the forward map is more delicate, because the hostname given by the DHCP client may already be in use by another machine. The DDNS protocol resolves this incertainty by inserting a supplementary TXT record in the forward map, a hash value called DHCID, based on information provided by the client, that identify it in a unique way. The DHCP server will refuse to update the forward map if the preexisting TXT record doesn't match with the newly computed one.
The problem with the default way to compute the DHCID is that it's based on the network card hardware address, so the wireless card and the wired card will generate two different DHCID, and the DHCP server will logically refuse to update the forward map, when switching from wireless to wired network, because it'll consider that two different clients try to register the same hostname. The solution to this problem is to define a unique dhcp-client-identifier string in /etc/dhclient.conf.
Another DHCP obscure behaviour tweak that caused me some trouble, due to its lack of documentation, is that the DHCP server silently discards DDNS updates concerning statically allocated IP address, except if explicity required (option update-static-lease in /etc/dhcpd.conf). The rationale of this option is that static leases should already be in the DNS, but there is a reason to distribute fixed IP addresses, even with DHCP, and even if the DDNS makes the hostname follow the updated IP address. A ssh client will warn loudly and repeatedly (man in the middle possible attack) if the association between an IP address and an hostkey changes.
With these two or three configuration tips, I have now a single DNS zone for my home network, that covers distinct physical networks, and an unified and dynamic host naming accross these networks.