DNS hybride Azure : quand utiliser Private Resolver, forwarders on-premises et zones privées

Le DNS hybride Azure devient fragile quand chaque incident est corrigé localement. Un forwarder est ajouté sur un serveur Windows, une zone privée est liée à un spoke, un resolver custom est déployé dans un hub, puis une équipe ajoute un Private Endpoint et découvre que le même nom ne répond pas pareil depuis Azure et depuis l’on-premises.

Azure DNS Private Resolver aide à rendre ce modèle plus propre, mais il ne décide pas à lui seul de l’architecture. Il faut choisir quel côté interroge quel résolveur, où vivent les zones privées, quels suffixes sont forwardés, et comment éviter que chaque spoke devienne une exception.

Définir les directions de résolution

Un design DNS hybride doit d’abord dire qui doit résoudre quoi. Le sens de la requête compte. Les workloads Azure peuvent avoir besoin de résoudre des zones internes on premises. Les serveurs on premises peuvent avoir besoin de résoudre des noms Azure privés, notamment les zones privatelink. Les workloads Azure peuvent aussi devoir résoudre des Private Endpoints sans passer par l’on-premises.

Depuis Azure vers on-premises
vm-app-01 -> dc01.corp.example.local
Function intégrée VNet -> api.mgmt.example.local

Depuis on-premises vers Azure
poste-admin -> myvault.vault.azure.net
serveur-outil -> mystorage.blob.core.windows.net

Depuis Azure vers Azure privé
workload spoke -> privatelink.vaultcore.azure.net
workload spoke -> privatelink.blob.core.windows.net

Sans cette matrice, le design part souvent dans le mauvais sens. On crée un outbound endpoint alors que le problème est une requête venant de l’on-premises. Ou l’on configure un conditional forwarder on premises alors que le problème est un spoke Azure qui n’utilise pas le bon chemin DNS.

Rôle du Private Resolver

Azure DNS Private Resolver fournit deux briques. L’inbound endpoint reçoit des requêtes DNS depuis d’autres réseaux, typiquement depuis l’on-premises, vers Azure. L’outbound endpoint permet au resolver Azure de transférer certaines zones vers des DNS externes via un ruleset.

Inbound endpoint
Reçoit les requêtes venant de l'on-premises
Sert de cible pour les conditional forwarders
Permet de résoudre les zones privées Azure depuis l'extérieur du VNet

Outbound endpoint
Sort vers les DNS on-premises selon des règles
Utilisé par les workloads Azure via ruleset lié aux VNets
Ne fournit pas une adresse IP à cibler directement

La confusion classique consiste à attendre de l’outbound endpoint une adresse que les DNS on premises pourraient cibler. Ce n’est pas son rôle. Pour les requêtes qui entrent dans Azure, il faut regarder l’inbound endpoint. Pour les requêtes Azure qui sortent vers des zones on premises, il faut regarder le ruleset associé à l’outbound endpoint.

Où lier les zones privées

Les zones Private DNS Azure peuvent être liées à un hub, à des spokes ou à plusieurs VNets selon le modèle d’exploitation. Le choix doit rester lisible. Lier toutes les zones à tous les spokes donne vite une configuration difficile à contrôler. À l’inverse, tout centraliser sans vérifier les chemins DNS peut empêcher certains workloads de résoudre correctement les noms privés.

Pattern centralisé
Zones privées dans un groupe réseau central
Liens VNet vers le hub ou les spokes nécessaires
Résolution hybride via inbound endpoint

Pattern distribué contrôlé
Zones liées uniquement aux VNets consommateurs
Moins de portée implicite
Plus de discipline nécessaire sur les créations de Private Endpoint

Pattern à éviter
Liens ajoutés au fil de l'eau sans inventaire
Zones privatelink dupliquées dans plusieurs endroits
Forwarders contradictoires entre hub et on-premises

La bonne réponse dépend de l’organisation, mais le principe ne change pas : il faut pouvoir expliquer pourquoi une zone est liée à un VNet donné. Si personne ne sait répondre, le DNS est déjà en train de dériver.

Conditional forwarders on-premises

Côté on-premises, les serveurs DNS doivent savoir quels suffixes envoyer vers Azure. Pour les services PaaS privatisés, les noms publics comme myvault.vault.azure.net finissent par être résolus via une zone privée privatelink. Il ne faut pas casser la résolution publique globale. Il faut forwarder les suffixes nécessaires vers l’inbound endpoint et garder le comportement standard pour le reste.

Forwarders possibles vers l'inbound endpoint Azure
privatelink.vaultcore.azure.net
privatelink.blob.core.windows.net
privatelink.azurewebsites.net

A documenter
Adresse IP de l'inbound endpoint
Serveurs DNS on-premises configurés
Suffixes exacts
Test depuis un poste et depuis un serveur applicatif

Il faut également vérifier que les pare-feu autorisent UDP et TCP 53 selon les besoins. Les incidents DNS intermittents viennent parfois d’un chemin TCP bloqué, visible seulement avec certaines réponses plus volumineuses.

Rulesets Azure vers on-premises

Pour les workloads Azure qui doivent résoudre des noms internes, un DNS forwarding ruleset permet de définir les suffixes envoyés vers les DNS on-premises. Ce ruleset doit être lié aux VNets consommateurs. Un spoke non lié ne bénéficiera pas du comportement attendu.

Ruleset Azure
corp.example.local -> 10.0.0.10, 10.0.0.11
mgmt.example.local -> 10.0.0.10, 10.0.0.11

Liens VNet
vnet-spoke-app-prod
vnet-spoke-tools-prod

Validation
nslookup dc01.corp.example.local
nslookup api.mgmt.example.local
Comparer depuis chaque VNet consommateur

Le ruleset n’est pas seulement un objet réseau. C’est une dépendance applicative. Un nouveau spoke applicatif doit donc avoir une étape explicite : vérifier les liens DNS nécessaires avant de déclarer l’environnement prêt.

Conclusion

Un DNS hybride Azure fiable repose sur des directions claires. L’inbound endpoint sert les requêtes qui entrent dans Azure. L’outbound endpoint et les rulesets servent les requêtes Azure qui partent vers d’autres DNS. Les zones privées portent les réponses Azure privées. Les forwarders on-premises orientent les suffixes nécessaires sans casser le reste.

La documentation utile tient en peu de choses : une matrice source/suffixe/résolveur, un inventaire des liens de zones privées, les forwarders on-premises, les rulesets Azure et quelques commandes de validation depuis chaque réseau important. C’est moins spectaculaire qu’un grand schéma, mais beaucoup plus efficace le jour où un nom ne résout plus au bon endroit.