For the sake of documentation, I'll try to answer my own question here: It's not possible. To quote from https://lists.isc.org/mailman/htdig/dhcp-users/2006-August/001422.html :
DHCP does NOT support updating of arbitrary zones, it takes the ip
address, reverses the octets, and appends the reverse domain name
(deafult in-addr.arpa).
However, there's a neat solution to the problem. One can configures arbitrary domain names for DDNS updates in the dhcpd configuration:
ddns-rev-domainname "dhcp";
zone 32.168.192.dhcp. {
primary 127.0.0.1;
key rndc-key;
}
So the DNS server needs to provide that particular zone. Since it's a bind9 in my case, here's the relevant snippet from /etc/named.conf
zone "32.168.192.dhcp" IN {
type master;
file "/var/named/dynamic/32.168.192.dhcp";
allow-update { key "rndc-key"; };
};
And of course, the corresponding zone file:
$ORIGIN .
$TTL 600 ; 10 minutes
32.168.192.dhcp IN SOA dns-dhcp.company.com. hostmaster.company.com. (
2016100328 ; serial
3600 ; refresh (1 hour)
600 ; retry (10 minutes)
86400 ; expire (1 day)
600 ; minimum (10 minutes)
)
NS dns-dhcp.company.com.
So now the 32.168.192.dhcp zone is dynamically updated with the information of the dhcp server. But how does that help reverse lookups? After all, a client is going to look for x.32.168.192.in-addr.arpa, right? Well, if we add a CNAME resource record to our 32.168.192.in-addr.arpa zone for every host that could be in the 32.168.192.dhcp zone (which is all the IPs the DHCP server could potentially hand out, a.k.a. the subnet range), we should be golden.
So here's the relevant part of the 32.168.192.in-addr.arpa zone file (in my case /var/named/32.168.192.in-addr.arpa):
$GENERATE 17-30 $ CNAME $.32.168.192.dhcp.
Which will result in:
$ dig -x 192.168.32.17
...
;; ANSWER SECTION:
17.32.168.192.in-addr.arpa. 600 IN CNAME 17.32.168.192.dhcp.
17.32.168.192.dhcp. 300 IN PTR debian.company.com.
...