Enable split DNS for providing both public and internal name resolution to VMs in the VNET.
Amazon Route 53 supports split-view DNS, so you can configure public and "PRIVATE" hosted zones to return different external and internal IP addresses for the same domain names.
i think a similar capability can be very useful also in Azure
Azure DNS private zones provides this capability. Please see https://docs.microsoft.com/azure/dns/private-dns-scenarios#scenario-split-horizon-functionality
this documentation explains the use of private zone and public zone to achieve this.
however the limitation on names uniqueness in the same RG is silly.
If my service has a public endpoint on api.service.io I want to hit it internally on the private zone (on a internal lb, for example) and externally on the public zone. But I also want to keep all this together, in the same RG because each instance of my service (for each customer) will need it.
I don't see any good reason for not allowing me to do this, except the internal implementation limitation that reuses the resource name as the domain name, which is obviously a design mistake.
AWS has had this for a while....
is there a timeline for getting this feature ? We just ran into the DNS problem with Azure linked back to our Corp. Network and seem to be forced to run an extra DNS server on Azure.
Bjarne Muri commented
Since the DNS zones in Azure is multi tennant, and authorative, anyone could create a zone. If somebody creates microsoft.com and gives it IP to a private server with certificate for microsoft.com, then every user of ns-***.azure-dns would be routed to the private address. Or am I wrong on this?
Ouer underlying problem is to have private IP's on vNet for servers on-prem.. we need to use FQN due to certificates and it seems overkill to create a cluster for hosting DNS.
Harald Solstad Fianbakken commented
Availability to use DNS Zones in private / hybrid infrastructure; e.g. on-prem network connected to Azure (over express route).
As of now there's no security on DNS Zones; so if you're exposing internal IP's to the public name servers on Azure it's bad in a security perspective.
There should be a way of setting DNS Zones in a private mode - exposing the zone on a specific VNet / subnet instead of public name servers.
This could be particular useful when having two different teams managing DNS and e.g. on-prem DNS delegating to the Azure hosted DNS Zones (but only for internal usage).