= WAN virtuel avec zones DNS privées pour les services PaaS - Serveurs DNS =

Quelle serait la bonne façon de configurer vWAN contenant des zones DNS privées Azure pour les services PaaS afin que plus tard, les VNET en étoile (et les réseaux sur site) puissent résoudre tout ce qui est nécessaire ?
Comme nous le savons, un VNET peut être lié à une seule zone DNS privée de nom spécifique (par exemple, je ne peux pas avoir 2 privatelink.azurewebsites.net distincts liés au même VNET)

Dans le hub standard géré manuellement& architecture en étoile Je lierais toutes les zones DNS privées à mon hub

Dans le vWAN, Hub est géré par Microsoft, je ne peux donc rien lier à Hub VNET. Je pense que je devrais créer un "spoke"séparé connecté au Hub qui contiendra toutes les zones DNS privées et VNET avec des liens vers les zones. Ensuite, les liens privés peuvent être résolus à partir de ce VNET

Dois-je simplement créer Azure Private DNS Resolver (ou des serveurs DNS sur VM, peu importe ici) dans ce VNET, puis chaque VNET de rayon doit être configuré avec ces adresses de serveurs DNS ? Comment s'assurer que chaque réseau virtuel en étoile dispose d'une configuration de serveurs DNS correcte ? Vous utilisez Azure Policy ? Ou peut-être devrait-il être déployé dans le cadre d'une zone d'atterrissage ?
Pour le hub standard& parlé cela est documenté ici - 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, cependant je me demande quel est le meilleur moyen pour vWAN

Une stratégie pour configurer tous les réseaux virtuels pour utiliser ce serveur DNS est une bonne idée, ou faites-en un modèle dans votre déploiement (Terraform, BiCep, PowerShell, etc.)

Je ne l'ai pas fait, mais je le dirais hors du hub, j'ai des machines virtuelles dans le hub car cela rend le routage si compliqué. Et si vous ne pouvez pas attacher la zone au hub VNET, je pense que la suppression est la seule option pour la solution PaaS ou IaaS

Vous allez plus que probablement vouloir une sorte de "services partagés"VNET si vous aller avec un vWAN

Si vous utilisez un pare-feu Azure dans le vWAN, vous pouvez également le faire servir de proxy DNS. Cela serait un proxy vers votre service DNS IAAS (qui transmettrait/transmettrait conditionnellement à l'adresse IP Azure magique) ou un résolveur DNS privé
J'ai de sérieux sentiments mitigés à propos de vWAN. Il s'est considérablement amélioré depuis son introduction, mais il y a encore une tonne d'oublis par rapport au hub à construire soi-même. L'observabilité et le débogage du réseau sont approximatifs, vous ne possédez pas l'adresse IP publique de votre abonnement, pas de protection DDOS, etc. Je ne veux pas décourager votre choix de conception, mais assurez-vous simplement de comprendre les limites avant de poursuivre dans cette voie

Merci, j'envisage juste plusieurs options différentes

Comment gérez-vous les UDR pour les rayons dans votre propre architecture hub and spoke ?
J'ai entendu dire que plusieurs rayons devaient communiquer entre eux (comme tous les rayons doivent communiquer avec un autre rayon avec des serveurs DNS personnalisés), il devient très difficile de gérer manuellement tous ces UDR.