= Virtual WAN with Private DNS Zones for PaaS services - DNS servers =

What would be the correct way to configure vWAN containing Azure Private DNS Zones for PaaS services so later on spoke VNETs (and on-premise networks) can resolve everything what is necessary?
As we know, one VNET can be linked with only one Private DNS Zone of specific name (eg. I cannot have 2 distinct privatelink.azurewebsites.net linked to the same VNET)

In the standard, manually managed hub & spoke architecture I would link all Private DNS Zones to my Hub

In the vWAN, Hub is managed by Microsoft so I cannot link anything to Hub VNET. I think I should create separate "spoke" connected to Hub which will contain all Private DNS Zones and VNET with links to zones. Then, privatelinks can be resolved from this VNET

Should I just create Azure Private DNS Resolver (or DNS servers on VM, doesn't matter here) in this VNET and then each spoke VNET should be configured with these DNS servers addresses? How would ensure each spoke VNET has correct DNS servers setup? Using Azure Policy? Or maybe it should be deployed as a part of landing zone?
For the standard hub & spoke this is documented here - httpsdocs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/private-link-and-dns-integration-at-scale#private-link-and-dns-integration-in-hub-and-spoke-network-architectures, however I'm wondering what's the best way for vWAN

Policy to set all VNETs to use that DNS Server is a good idea, or have it templated in your deployment (Terraform, BiCep, PowerShell etc.)

I've not done this, but I would spoke it off of the hub, Ihaving VM's in the hub as it makes routing so complicated. And if you can't attach the zone to the hub VNET, I believe spoking it off is the only option for the PaaS or IaaS solution

You’re more than likely going to want some sort of “shared services” VNET if you go with a vWAN

If you use an Azure Firewall in the vWAN, you can also have that serve as a DNS proxy. That would proxy to your IAAS DNS service (which would forward/conditionally forward to the magic Azure IP) or Private DNS Resolver


I have serious mixed feelings about vWAN. It’s improved significantly since it’s introduction, but still has a ton of oversights compared to build-your-own hub. Observability and network debugging is rough, you don’t “own” the public IP in your subscription, no DDOS protection, etc. I don’t want to discourage your design choice, but just be sure you understand the limitations before pursuing this route

Thanks, I'm just considering multiple different options

How do you manage UDRs for spokes in your own hub and spoke arhcitecture?
I have heard with multiple spokes needing to communicate with each other (like all the spokes have to communicate with another spoke with custom DNS servers) it's getting really hard to manage all of these UDRs manually.