Windows 11 Azure VMs with Azure DHCP register the A record but never the PTR in AD DNS – DHCP client leaves out PTR registration

While troubleshooting reverse DNS for win11 machine in Azure, we found that Windows clients register their Host (A) record dynamically but never register their reverse (PTR) record.

Environment

• Windows 11 (build 26200) VMs in Azure, domain-joined
• IP assigned by Azure-provided DHCP (168.x.x.x). We have no Windows DHCP server.
• The VNet uses custom DNS: on-premises AD-integrated DNS on domain controllers
• The reverse lookup zone for the subnet exists, is AD-integrated, and allows Secure dynamic updates. Authenticated Users has Create all child objects on the zone.

What we observed

1. On DHCP, only the A record is registered. In a packet capture of ipconfig /registerdns, the client sends an SOA query and a dynamic update for the A record only. It never sends an SOA query or update for the in-addr.arpa (PTR) name.
2. With a static IP, both records are registered. We set the same IP, mask, gateway and DNS servers statically on the same VM. The client then registered both A and PTR immediately, using secure update. So the DNS zone, its permissions, the network path and Kerberos all work.
3. DHCP capture: the DHCP Request contains Option 81 (Client FQDN) with flags 0x00 (S=0: client updates A, server updates PTR). Azure DHCP's ACK contains no Option 81.
4. Client settings we checked or changed, with no effect:
   • "Register this connection's addresses in DNS" = enabled
   • DisableReverseAddressRegistrations / DisableDynamicUpdate not present
   • GPO "Register PTR records" = Enabled (Register), with RegisterReverseLookup = 1 confirmed in the registry, then a reboot
   • Dynamic update policy enabled

Our understanding

Microsoft documentation says that when the DHCP server doesn't confirm Option 81, the Windows client registers both the A and PTR records itself. In our case, the DHCP Client service seems to register with flags that leave out the PTR. The "Register PTR records" policy doesn't change this on DHCP-assigned adapters.

Questions

1. Is this expected behavior for Windows DHCP clients when the DHCP server (here, Azure DHCP) doesn't return Option 81? Or should the client fall back to registering the PTR itself?
2. Is there a supported setting that makes the DHCP Client register its own PTR on a DHCP-assigned adapter?
3. Does Azure DHCP support Option 81 or DNS dynamic updates to custom DNS servers? Is any Azure-side configuration available for this?
4. What does Microsoft recommend for PTR registration of Azure VMs that use custom AD DNS with Azure DHCP? (A static IP inside the guest OS isn't recommended for Azure VMs.)

Any documentation or real-world experience with Azure VMs and reverse DNS registration in AD-integrated zones would be appreciated.