The current mechanism for dhcp-server hostfile-update takes the unchanged hostname sent by any unauthenticated DHCP client and adds it into /etc/hosts pointing to that client's IP. /etc/hosts is also used by 'service dns forwarding' (pdns-recursor) to generate its zone list so these hosts entries are also resolvable over the forwarder.
They are also used to add NTAs (negative trust anchors for DNSSEC) to pdns-recursor as otherwise pdns-recursor will mark these entries as bogus if a DNSSEC trust exists for them at top-level nameservers.

This allows any DHCP client to set its hostname to an already existing domain (e.g. 'google.com') and point it to its own IP.
Since the typical network scenario in such cases is to also have the forwarder be the main DNS server for the whole local network, all network hosts will now see that DHCP client's IP in queries.

An attacker on any L2 segment served by dhcp-server can MITM any domain they choose simply by setting its DHCP client hostname to it.

This issue was already raised by me in other bugs regarding hostfile-update, suggesting strongly discouraging users against using this feature and warning them they should have physical security measures in place on the L2 segment any dhcp-server operates on.

Possible workarounds would be adding a preset top-level domain over all client hostnames. This would prevent spoofing as the client hostname 'google.com' would be converted to e.g. 'google.com.foobar'.