= WAN virtual com zonas DNS privadas para serviços PaaS - servidores DNS =

Qual seria a maneira correta de configurar vWAN contendo Zonas DNS Privadas do Azure para serviços PaaS para que, posteriormente, VNETs spoke (e redes locais) possam resolver tudo o que for necessário?
Como sabemos, um VNET pode ser vinculado a apenas uma zona DNS privada de nome específico (por exemplo, não posso ter 2 privatelink.azurewebsites.net distintos vinculados ao mesmo VNET)

No hub padrão gerenciado manualmente& arquitetura do spoke Eu vincularia todas as zonas DNS privadas ao meu hub

Na vWAN, o Hub é gerenciado pela Microsoft, então não posso vincular nada ao Hub VNET. Acho que devo criar "spoke"separado conectado ao hub, que conterá todas as zonas DNS privadas e VNET com links para zonas. Em seguida, os links privados podem ser resolvidos a partir desta VNET

Devo apenas criar o resolvedor de DNS privado do Azure (ou servidores DNS na VM, não importa aqui) neste VNET e, em seguida, cada VNET falado deve ser configurado com esses endereços de servidores DNS? Como garantir que cada VNET falado tenha a configuração correta dos servidores DNS? Usando a Política do Azure? Ou talvez deva ser implantado como parte da zona de pouso?
Para o hub padrão& falado isso está documentado aqui - 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, no entanto, estou me perguntando qual é a melhor maneira para vWAN

Política para definir todos os VNETs para usar esse servidor DNS é uma boa ideia ou tê-lo modelado em sua implantação (Terraform, BiCep, PowerShell etc.)

Eu não fiz isso, mas falaria fora do hub, tendo VMs no hub, pois isso torna o roteamento muito complicado. E se você não pode anexar a zona ao hub VNET, acredito que falar é a única opção para a solução PaaS ou IaaS

Você provavelmente vai querer algum tipo de "serviços compartilhados"VNET se você vá com uma vWAN

Se você usar um Firewall do Azure na vWAN, também poderá fazer com que ele sirva como um proxy DNS. Isso faria proxy para seu serviço DNS IAAS (que encaminharia/encaminharia condicionalmente para o IP mágico do Azure) ou resolvedor de DNS privado
Tenho sentimentos confusos sobre vWAN. Ele melhorou significativamente desde sua introdução, mas ainda tem muitos descuidos em comparação com o hub de construção própria. Observabilidade e depuração de rede é difícil, você não possui o IP público em seu assinatura, sem proteção DDOS, etc. Não quero desencorajar sua escolha de design, mas certifique-se de entender as limitações antes de seguir esse caminho

Obrigado, estou apenas considerando várias opções diferentes

Como você gerencia UDRs para spokes em seu próprio hub e arquitetura spoke?
Ouvi dizer que vários spokes precisam se comunicar entre si (como todos os spokes precisam se comunicar com outro spoke com servidores DNS personalizados), está ficando muito difícil gerenciar todos esses UDRs manualmente.