How can we allow application workloads to manage their own DNS entries when their VMs also need to be joined to an AADDS domain (without violating the principal of least privilege)?
Background
We have the following network configuration:
- A Hub VNET containing an Azure AD Domain Services (AADDS) managed domain called
mydomain.co.uk. This VNET will also host a VNET Gateway, a Bastion instance and a couple of management VMs. - Multiple "environment" VNETs, all peered to the Hub, to run application workloads. These workloads all currently running on on domain-joined VMs & VMSSs that are behind both an Standard Load Balancer (for internal traffic), and an Application Gateway (for public traffic). The IP addresses of those load balancers and App Gateways need to be resolvable via DNS.
Requirements
We would like all applications to be resolvable using the same TLD domain - both internally and externally (e.g. myapp.env1.mydomain.co.uk should work internally and externally).
The Hub is created by a single pipeline running a terraform configuration that is maintained by the Platform team. The platform Team should not need to be involved when provisioning environments.
Each environment is created by its own pipeline, running terraform configurations that are maintained by the various Product Teams. The Product Teams should be able to spin up & destroy environments without any input from the Platform Team.
Problem
Public DNS resolution was easy to setup. We simply granted each environmental pipeline permission to register records in an Azure public DNS zone. The problem arose when we tried to solve internal DNS Resolution.
We tried creating a Private DNS zone for `mydomain.co.uk and linking it to the environmental VNETs. Unfortunately, the VMs in those VNETs then fail to join to the domain due to the lack of domain SRV records (these are created by default in AADDS). So it seems that AADDS requires that any VNETs containing VMs that want to join to the domain use its IP addresses for DNS resolution. This means any apps running on those VMs must send their DNS query to AADDS, not to an Azure Private DNS Zone.
We thought about giving the environment pipelines permission to create records in the AADDS DNS zone. Unfortunately, the Microsoft docs say that only users that are members of the "AAD DC Administrators" group can add/remove DNS records. This is far too much power to give to the environmental pipelines (it would allow them to delete other workloads' VMs from the domain for example).
We then tried linking the Private DNS zone to the Hub VNET, in the hope that we could configure AADDS to forward any DNS requests that it can't resolve to Azure DNS. Unfortunately, AADDS does not forward any DNS requests for mydomain.co.uk onto Azure DNS - presumably because it believes it is authoritative for that zone.
Is there another mechanism that we haven't thought of yet?

