Azure DNS Private Resolver et forwarders hybrides sans résolution fragile

Le DNS commence souvent à dériver bien avant que quelqu’un parle d’un problème d’architecture. Un environnement hybride continue à résoudre des noms, quelques tests passent encore, et un premier Private Endpoint semble correct dans le portail. Puis une deuxième zone arrive, les conditional forwarders deviennent incohérents, une équipe ajoute des règles DNS custom dans un spoke, et la chaîne entre l’on-premises, les virtual networks Azure et les zones privées commence à répondre différemment selon l’origine de la requête.

Azure DNS Private Resolver est utile précisément parce qu’il retire une catégorie de serveurs DNS déployés en machines virtuelles uniquement pour relayer, récursiver et forwarder des requêtes entre plusieurs environnements. Cela ne rend pas le design automatique. Le vrai travail consiste à décider quel côté doit interroger quel résolveur, où placer les règles, comment lier les private zones, et comment valider la résolution après des changements de routage, de peering ou de Private Endpoint.

Cet article se concentre sur le pattern le plus utile en environnement mixte. Les workloads Azure doivent résoudre certaines zones on premises, les workloads on premises doivent résoudre des zones privées Azure, et l’ensemble doit rester prévisible après l’ajout de services comme Storage, SQL, Key Vault ou des noms applicatifs internes.

Ce que change réellement Azure DNS Private Resolver

Azure DNS Private Resolver est un service de résolution managé déployé dans un virtual network. Il apporte deux briques principales.

Un endpoint inbound expose une adresse IP dans Azure vers laquelle d’autres serveurs DNS peuvent envoyer des requêtes. C’est généralement l’élément utilisé par les forwarders DNS on premises lorsqu’ils doivent résoudre des Azure private DNS zones. Microsoft décrit les inbound endpoints comme la destination des requêtes DNS envoyées vers le resolver depuis d’autres réseaux.

Un endpoint outbound est utilisé lorsque le resolver doit forwarder des requêtes vers l’extérieur d’Azure selon un DNS forwarding ruleset. C’est cette brique qui permet à des workloads Azure de résoudre certaines zones on premises sans déployer de VM jouant le rôle de résolveur custom. Les outbound endpoints n’ont pas d’adresse IP exposée comme les inbound endpoints et doivent vivre dans un subnet dédié.

Un DNS forwarding ruleset contient la logique de forwarding. On y définit les suffixes à transférer et les serveurs DNS de destination qui recevront ces requêtes. Les rulesets sont ensuite liés à des virtual networks pour que les workloads de ces VNets utilisent ce comportement sur les namespaces concernés.

Le service est intéressant parce qu’il remplace des patterns historiques basés sur des VMs qui demandaient du patching, de la supervision, un design de disponibilité et des exceptions réseau ajoutées au fil du temps. Microsoft le positionne précisément comme l’option managée pour la résolution hybride entre Azure et l’on-premises.

Le pattern de référence à privilégier au départ

Dans la plupart des environnements, le point de départ le plus propre consiste à placer dans un hub virtual network les éléments suivants.

Un DNS Private Resolver.

Un subnet dédié pour l’endpoint inbound.

Un subnet dédié pour l’endpoint outbound.

Des Private DNS Zones correctement liées là où c’est nécessaire, ou centralisées dans le hub selon le modèle d’exploitation retenu.

Un ruleset côté outbound pour les zones on premises comme corp.example.local ou mgmt.example.local.

Des serveurs DNS on premises configurés avec des conditional forwarders pour les zones privées Azure et les zones liées aux Private Endpoints vers l’adresse IP de l’endpoint inbound.

Ce pattern suit bien la guidance Microsoft sur les architectures centralisées en hub and spoke, où le resolver peut vivre dans le hub et servir plusieurs VNets via les rulesets et le design des private zones.

Définir l’objectif de nommage avant de déployer quoi que ce soit

Avant toute création, il faut définir quelles zones doivent être résolues depuis quel côté.

Une matrice minimale ressemble souvent à ceci.

Si cette matrice n’est pas explicitée, le design DNS glisse rapidement vers des hypothèses implicites. Il devient alors facile de construire un ruleset qui ne couvre qu’un seul sens de résolution, tout en laissant le chemin inverse fragile ou mal compris.

Pré requis réseau à rendre explicites

Le resolver n’est pas compliqué à déployer, mais il est facile à déployer dans une mauvaise forme.

Il faut un virtual network avec des subnets dédiés aux endpoints inbound et outbound. Microsoft impose que ces subnets soient délégués à Microsoft.Network/dnsResolvers, et aucune autre ressource ne doit y être placée. Les outbound endpoints n’exposent pas d’IP mais nécessitent malgré tout leur propre subnet.

Un plan d’adressage simple peut ressembler à ceci.

hub-vnet:                 10.40.0.0/16
snet-dnspr-inbound:      10.40.10.0/28
snet-dnspr-outbound:     10.40.10.16/28

Si le resolver doit servir du trafic hybride, le hub doit aussi disposer d’un chemin réseau vers les serveurs DNS on premises via VPN ou ExpressRoute.

Déployer les subnets avec Azure CLI

Le déploiement peut être fait en ARM, Bicep, Terraform ou portail. Pour un article de type runbook, Azure CLI reste une bonne base car il rend les objets très visibles.

RG="rg-net-dns-prod"
LOCATION="westeurope"
VNET="vnet-hub-net-prod"
INBOUND_SUBNET="snet-dnspr-inbound"
OUTBOUND_SUBNET="snet-dnspr-outbound"

az group create -n $RG -l $LOCATION

az network vnet create -g $RG -n $VNET -l $LOCATION --address-prefixes 10.40.0.0/16 --subnet-name $INBOUND_SUBNET --subnet-prefixes 10.40.10.0/28

az network vnet subnet create -g $RG --vnet-name $VNET -n $OUTBOUND_SUBNET --address-prefixes 10.40.10.16/28

Puis déléguer les subnets.

az network vnet subnet update -g $RG --vnet-name $VNET -n $INBOUND_SUBNET --delegations Microsoft.Network.dnsResolvers

az network vnet subnet update -g $RG --vnet-name $VNET -n $OUTBOUND_SUBNET --delegations Microsoft.Network.dnsResolvers

Cette exigence de subnet dédié n’est pas un détail. Si quelqu’un veut ensuite placer une VM, une appliance ou un autre composant réseau dans le même subnet, le design a déjà commencé à dériver.

Créer le resolver et ses endpoints

Créer d’abord le resolver, puis les endpoints inbound et outbound.

RESOLVER="dnspr-hub-prod"
INBOUND_EP="inbound-hub-prod"
OUTBOUND_EP="outbound-hub-prod"

az network dns-resolver create -g $RG -n $RESOLVER -l $LOCATION --virtual-network /subscriptions/<subscription-id>/resourceGroups/$RG/providers/Microsoft.Network/virtualNetworks/$VNET

az network dns-resolver inbound-endpoint create -g $RG --dns-resolver-name $RESOLVER -n $INBOUND_EP -l $LOCATION --ip-configurations '[{"privateIpAllocationMethod":"Dynamic","subnet":{"id":"/subscriptions/<subscription-id>/resourceGroups/'$RG'/providers/Microsoft.Network/virtualNetworks/'$VNET'/subnets/'$INBOUND_SUBNET'"}}]'

az network dns-resolver outbound-endpoint create -g $RG --dns-resolver-name $RESOLVER -n $OUTBOUND_EP -l $LOCATION --subnet /subscriptions/<subscription-id>/resourceGroups/$RG/providers/Microsoft.Network/virtualNetworks/$VNET/subnets/$OUTBOUND_SUBNET

Vérifier l’adresse IP de l’endpoint inbound après le déploiement.

az network dns-resolver inbound-endpoint show -g $RG --dns-resolver-name $RESOLVER -n $INBOUND_EP --query 'ipConfigurations[0].privateIpAddress' -o tsv

C’est cette adresse IP qui sera utilisée comme cible par les conditional forwarders on premises.

Les private zones restent indispensables

Le resolver ne remplace pas les private DNS zones. Il aide les requêtes à atteindre le bon endroit, mais les zones doivent toujours exister et être liées correctement.

Pour un Key Vault, un compte Storage ou un serveur SQL exposé via Private Endpoint, il faut toujours le bon design de zone privatelink et les bons enregistrements. La documentation Microsoft sur le DNS des Private Endpoints reste donc centrale, parce que le resolver ne fait que transporter le flux de requête. La justesse de la zone et des enregistrements continue à déterminer la réponse finale.

Exemple simple pour Storage.

ZONE="privatelink.blob.core.windows.net"
LINK_NAME="link-hub-vnet-blob"

az network private-dns zone create -g $RG -n $ZONE

az network private-dns link vnet create -g $RG -z $ZONE -n $LINK_NAME -v /subscriptions/<subscription-id>/resourceGroups/$RG/providers/Microsoft.Network/virtualNetworks/$VNET --registration-enabled false

Si tu centralises le DNS, décide tôt si les private zones vivent uniquement dans le modèle hub ou si certaines zones restent sous responsabilité applicative. Un modèle mixte peut fonctionner, mais seulement si la gouvernance est claire.

Forwarder Azure vers l’on-premises avec les rulesets

Configurer maintenant le forwarding côté Azure pour les zones on premises.

Supposons que des workloads Azure doivent résoudre corp.example.local et mgmt.example.local via des serveurs DNS on premises 192.168.10.10 et 192.168.10.11.

Créer le ruleset.

RULESET="dnsfw-hub-prod"

az network dns-resolver forwarding-ruleset create -g $RG -n $RULESET -l $LOCATION --outbound-endpoints /subscriptions/<subscription-id>/resourceGroups/$RG/providers/Microsoft.Network/dnsResolvers/$RESOLVER/outboundEndpoints/$OUTBOUND_EP

Créer les règles de forwarding.

az network dns-resolver forwarding-rule create -g $RG --ruleset-name $RULESET -n corp-example-local --domain-name 'corp.example.local.' --target-dns-servers '[{"ipAddress":"192.168.10.10","port":53},{"ipAddress":"192.168.10.11","port":53}]'

az network dns-resolver forwarding-rule create -g $RG --ruleset-name $RULESET -n mgmt-example-local --domain-name 'mgmt.example.local.' --target-dns-servers '[{"ipAddress":"192.168.10.10","port":53},{"ipAddress":"192.168.10.11","port":53}]'

Puis lier le ruleset aux VNets dont les workloads doivent consommer ces forwarders.

SPOKE_VNET_ID="/subscriptions/<subscription-id>/resourceGroups/rg-app-prod/providers/Microsoft.Network/virtualNetworks/vnet-app-prod"

az network dns-resolver forwarding-ruleset vnet-link create -g $RG --ruleset-name $RULESET -n link-vnet-app-prod --virtual-network $SPOKE_VNET_ID

C’est un point souvent oublié. Créer le ruleset dans le hub ne suffit pas. Les VNets consommateurs doivent encore être liés au ruleset pour que leurs workloads utilisent ces règles. Microsoft documente bien les rulesets et les VNet links comme des objets distincts pour cette raison.

Forwarder l’on-premises vers les zones privées Azure

Le sens inverse fonctionne différemment.

Les serveurs DNS on premises n’utilisent pas directement les rulesets Azure. Ils envoient les requêtes vers l’adresse IP de l’endpoint inbound du resolver via un conditional forwarder classique.

Exemple sur Windows DNS.

Add-DnsServerConditionalForwarderZone -Name 'privatelink.blob.core.windows.net' -MasterServers 10.40.10.4 -ReplicationScope 'Forest'

Add-DnsServerConditionalForwarderZone -Name 'privatelink.vaultcore.azure.net' -MasterServers 10.40.10.4 -ReplicationScope 'Forest'

L’adresse IP ci-dessus est celle de l’endpoint inbound. Il faut la remplacer par celle réellement renvoyée par Azure.

C’est ce mécanisme qui permet à des clients on premises de résoudre des noms présents dans des private zones Azure sans déployer de couche intermédiaire basée sur des VMs. La guidance Microsoft sur le DNS hybride illustre explicitement ce modèle pour la résolution des Azure private DNS zones depuis l’on-premises.

Validation depuis des workloads Azure

Un design n’existe pas tant que le chemin de requête n’est pas vérifié.

Depuis une VM d’un VNet lié au ruleset, tester des noms on premises.

nslookup dc01.corp.example.local
nslookup repo01.mgmt.example.local

dig dc01.corp.example.local

dig @168.63.129.16 dc01.corp.example.local

Si le ruleset est appliqué correctement, le workload Azure doit obtenir une réponse via le chemin du resolver Azure, sans avoir à cibler directement les DNS on premises.

Il faut aussi vérifier le vrai chemin applicatif, pas uniquement celui d’une VM de test. Une erreur classique consiste à valider depuis une machine de diagnostic alors que l’App Service, le cluster AKS ou le workload privé utilise une chaîne DNS différente.

Validation depuis l’on-premises

Depuis l’on-premises, vérifier que les noms privés Azure se résolvent via l’endpoint inbound.

Resolve-DnsName mystorageaccount.blob.core.windows.net
Resolve-DnsName myvault.vault.azure.net
Resolve-DnsName myinternalapp.priv.contoso.internal

Pour blob.core.windows.net, regarder attentivement la chaîne CNAME et l’adresse privée renvoyée. Le modèle DNS des Private Endpoints repose sur le fait que les noms publics finissent par passer par le bon chemin privatelink lorsque la configuration privée est correcte.

L’erreur de design la plus fréquente

L’erreur la plus courante consiste à penser que tous les noms liés aux Private Endpoints doivent être forwardés de la même manière, sans prendre en compte la zone exacte et le comportement du service.

Storage illustre très bien ce piège. Blob, file, queue et table utilisent des zones privatelink distinctes. Un design qui ne forwarde qu’une seule zone peut sembler correct jusqu’au moment où une autre sous-ressource apparaît. Microsoft publie précisément les valeurs de private DNS zone par service parce que ces mappings ne sont pas interchangeables.

Une autre erreur récurrente consiste à conserver des serveurs DNS custom dans Azure tout en oubliant que certains workloads utilisent encore le resolver Azure natif alors que d’autres dépendent de la chaîne custom. Ce dédoublement peut survivre longtemps avant qu’une équipe découvre qu’un même nom ne se résout pas de la même manière selon le subnet ou le type de service.

Centraliser ou distribuer le resolver

Un resolver déployé dans un hub est généralement le meilleur point de départ, mais tous les environnements ne doivent pas tout centraliser.

Un resolver centralisé a du sens lorsque la gouvernance DNS est elle-même centralisée, que la connectivité hybride passe déjà par un hub, et que plusieurs VNets applicatifs ont besoin du même comportement de forwarding vers l’on-premises.

Une approche plus distribuée peut être cohérente lorsque des entités distinctes exploitent leurs propres environnements, que le peering est contraint, ou que le rayon d’impact des changements DNS doit rester plus petit.

Microsoft fournit une guidance d’architecture pour les modèles centralisés comme distribués, ce qui rappelle utilement que le service n’impose pas une seule topologie. La topologie doit rester alignée sur le modèle d’exploitation.

Vérifications à conserver dans un runbook

Ces vérifications détectent très tôt la plupart des dérives.

az network dns-resolver show -g $RG -n $RESOLVER -o table
az network dns-resolver inbound-endpoint list -g $RG --dns-resolver-name $RESOLVER -o table
az network dns-resolver outbound-endpoint list -g $RG --dns-resolver-name $RESOLVER -o table
az network dns-resolver forwarding-ruleset list -g $RG -o table
az network dns-resolver forwarding-rule list -g $RG --ruleset-name $RULESET -o table

Et depuis des hôtes de validation.

nslookup mystorageaccount.blob.core.windows.net
nslookup myvault.vault.azure.net
nslookup dc01.corp.example.local

resolvectl status || true

Il faut garder la source de réponse attendue documentée pour chaque nom important. La vraie question n’est pas seulement de savoir si un nom se résout, mais s’il se résout depuis la bonne source et par le bon chemin.

Les erreurs qui ressemblent à des problèmes réseau mais qui sont surtout des problèmes de design DNS

Un Private Endpoint existe, mais l’on-premises continue à obtenir l’IP publique parce que la bonne zone privatelink n’a jamais été forwardée.

Les workloads Azure résolvent une zone on premises mais pas une autre parce qu’un seul suffixe a été ajouté au ruleset.

Le resolver existe dans un hub, mais le spoke consommateur n’a jamais été lié au ruleset.

L’endpoint inbound a bien été déployé, mais les DNS on premises pointent vers la mauvaise adresse ou le retour réseau vers Azure n’a jamais été validé.

Une équipe pense que le resolver crée automatiquement des enregistrements privés pour n’importe quelle zone interne. Ce n’est pas son rôle. Il forwarde des requêtes. La propriété des zones et le cycle de vie des enregistrements doivent toujours être conçus.

Là où ce service est pertinent, et là où il ne l’est pas

Azure DNS Private Resolver est très pertinent quand l’objectif est d’obtenir une résolution hybride managée sans maintenir de VMs de forwarding, et quand le besoin principal consiste à contrôler le forwarding entre des namespaces on premises et des private DNS zones Azure.

Ce n’est pas un substitut à une vraie gouvernance DNS. Il ne corrigera pas à lui seul un patrimoine de zones privées fragmentées, des conventions de nommage incohérentes ou des applications construites sur de mauvaises hypothèses. Il retire une charge d’infrastructure. Il ne retire pas l’ambiguïté d’architecture.

Références

• Microsoft Learn, Azure DNS Private Resolver overview
• Microsoft Learn, Resolve Azure and on premises domains
• Microsoft Learn, Azure DNS Private Resolver endpoints and rulesets
• Microsoft Learn, Azure DNS Private Resolver architecture guidance
• Microsoft Learn, Azure Private Endpoint DNS integration scenarios
• Microsoft Learn, Azure Private Endpoint private DNS zone values