Private DNS Zones en hub and spoke

Les Private DNS Zones Azure deviennent rapidement une couche structurante dans une architecture hub and spoke. Au départ, elles peuvent donner l’impression d’un simple composant annexe. Une zone contient des enregistrements privés. Elle est liée à un ou plusieurs virtual networks. Les ressources présentes dans ces VNets résolvent les noms de cette zone. Pour un premier Private Endpoint, un compte de stockage ou quelques machines virtuelles, cette mécanique reste lisible.

Le sujet change dès que l’architecture grandit. Une landing zone Azure peut contenir un hub réseau, plusieurs spokes applicatifs, plusieurs subscriptions, des environnements séparés, des connexions hybrides, des DNS internes et des équipes qui ne travaillent pas toutes au même rythme. Dans ce contexte, la question n’est plus seulement de créer une zone privée. Il faut décider où elle vit, qui la possède, quels VNets y sont liés, comment les enregistrements sont alimentés, quels resolvers sont utilisés, et comment éviter que chaque projet construise sa propre variante du DNS privé.

Une zone privée mal organisée ne casse pas toujours immédiatement une application. C’est même ce qui rend le problème dangereux. Les premiers tests peuvent fonctionner, puis une migration réseau, une bascule vers un DNS personnalisé, un nouveau Private Endpoint ou un spoke supplémentaire révèle que la résolution repose sur une hypothèse fragile. Le portail montre que la zone existe. Le lien VNet semble présent. Le Private Endpoint a bien une adresse privée. Pourtant le workload continue à résoudre un nom public, obtient une mauvaise adresse, ou ne résout plus rien depuis un environnement hybride.

Traiter les zones privées comme un composant de plateforme

Le modèle le plus sain consiste à traiter les Private DNS Zones comme un composant de plateforme, pas comme une ressource applicative créée au fil de l’eau. Cela ne signifie pas que toutes les zones doivent forcément vivre dans le même resource group ou dans la même subscription. Cela signifie surtout qu’elles suivent une convention commune, qu’elles sont visibles dans le modèle d’architecture, et qu’elles ne sont pas laissées à la décision isolée de chaque workload.

Les zones liées aux Private Endpoints doivent utiliser les noms attendus par Azure. Un compte de stockage, un Key Vault, un Container Registry ou un autre service exposé en Private Link ne se résout pas proprement avec une zone inventée localement. Le nom privé doit remplacer la résolution publique au bon endroit, sans casser les autres usages du service. Les zones internes d’entreprise doivent aussi rester distinctes des zones privatelink, car elles ne répondent pas au même besoin. Une zone privée utilisée pour les ressources internes d’une entreprise n’a pas la même gouvernance qu’une zone Azure alimentée par des Private Endpoints.

Dans une architecture hub and spoke, le hub porte généralement les services transverses. Il concentre la connectivité, les firewalls, les resolvers, les routes, parfois les bastions et les outils d’administration. Les zones DNS privées peuvent suivre cette logique. Elles deviennent alors un élément de la plateforme réseau, avec une équipe responsable, une convention de nommage, des règles de liaison et une stratégie de diagnostic.

Le danger consiste à laisser chaque spoke créer ses propres zones privées. Cette approche semble rapide pour une équipe projet, car elle règle localement la résolution de son Private Endpoint. Mais elle multiplie les doublons et les comportements incohérents. Deux zones portant le même nom peuvent exister dans deux subscriptions différentes. Un spoke peut résoudre correctement un service tandis qu’un autre utilise un chemin différent. Les équipes finissent par diagnostiquer des incidents DNS comme s’il s’agissait de problèmes applicatifs.

Comprendre le rôle réel des liens VNet

Un lien entre une Private DNS Zone et un VNet donne accès aux enregistrements de la zone depuis ce VNet, à condition que le chemin de résolution utilise réellement le mécanisme Azure attendu. C’est un point souvent sous-estimé. Le lien n’est pas un tunnel DNS universel. Il ne force pas tous les clients du VNet à interroger la zone. Il rend la zone disponible dans le modèle de résolution associé au VNet.

Lorsque le VNet utilise le DNS Azure par défaut, la résolution est généralement directe. Les zones privées liées au VNet sont prises en compte, puis la résolution continue vers le DNS fourni par Azure si nécessaire. Dans un environnement simple, ce comportement explique pourquoi un Private Endpoint fonctionne rapidement après la création du bon lien DNS.

Le raisonnement devient différent dès que le VNet utilise un DNS personnalisé. Dans beaucoup d’environnements d’entreprise, c’est le cas normal. Les machines pointent vers des contrôleurs de domaine, des appliances DNS, des forwarders de sécurité ou des serveurs DNS centralisés. À partir de ce moment, la machine n’interroge plus directement le chemin Azure par défaut. Elle envoie ses requêtes au DNS configuré. Si ce DNS ne sait pas transférer les domaines privés Azure vers le bon resolver, la zone peut être parfaitement configurée et pourtant invisible pour le workload.

C’est une cause fréquente d’incident. Une équipe vérifie le Private Endpoint. Il existe. Elle vérifie la zone privée. Elle existe. Elle vérifie le lien VNet. Il existe. Mais la VM ou le conteneur interroge un DNS interne qui ne possède aucune règle pour privatelink.blob.core.windows.net, privatelink.vaultcore.azure.net ou un autre suffixe privé. Le problème n’est pas la zone. Le problème est le chemin de résolution.

Workload dans un spoke
Requête DNS vers le resolver configuré sur le VNet
  Si DNS Azure par défaut
    Les Private DNS Zones liées au VNet sont interrogées
  Si DNS personnalisé
    Le DNS personnalisé doit transférer le suffixe privé vers le bon resolver

Private DNS Zone
Contient les enregistrements privés
Ne devient utile que si le chemin DNS arrive jusqu'à elle

Cette distinction doit apparaître dans le design. Une architecture DNS privée ne se résume pas à une liste de zones et de liens. Elle doit décrire le chemin exact d’une requête depuis le workload jusqu’à l’enregistrement final. Sans cette lecture, le DNS reste difficile à exploiter et les incidents se répètent.

Hub centralisé ou liens distribués

Deux modèles reviennent souvent dans les architectures Azure. Le premier consiste à lier directement les zones privées aux spokes qui consomment les services. Le second consiste à centraliser la résolution dans un hub, avec Azure DNS Private Resolver ou des forwarders DNS, puis à faire transiter les requêtes vers ce point central.

Le lien direct est simple à comprendre. Un spoke qui consomme un service reçoit un lien vers la zone correspondante. Si le spoke utilise le DNS Azure par défaut, la résolution fonctionne sans beaucoup de composants supplémentaires. Ce modèle est acceptable pour des environnements limités, ou pour des workloads isolés sans DNS personnalisé.

Mais il devient moins confortable quand le nombre de spokes augmente. Chaque zone doit être liée à plusieurs VNets. Les droits de modification deviennent sensibles. Les équipes peuvent ajouter des liens pour régler un incident ponctuel, puis les oublier. Une zone finit par être liée à des VNets qui n’en ont pas besoin. La résolution privée devient trop large, ce qui réduit la lisibilité et complique la segmentation.

Le modèle centralisé est plus exigeant, mais plus robuste pour une plateforme. Les zones privées vivent dans la zone de responsabilité réseau ou plateforme. Le hub héberge un resolver. Les DNS internes ou les spokes envoient les suffixes concernés vers le hub. Les règles de forwarding deviennent le point de contrôle. On ne cherche plus à relier toutes les zones à tous les VNets. On décide quels suffixes sont résolus par quel chemin.

Azure DNS Private Resolver est adapté à ce modèle. L’inbound endpoint reçoit les requêtes venant d’autres réseaux, par exemple depuis un environnement on premises ou depuis un DNS interne. L’outbound endpoint permet au resolver d’utiliser des règles de forwarding vers d’autres DNS pour des suffixes spécifiques. Les rulesets définissent les suffixes transférés et peuvent être liés aux VNets qui doivent les utiliser. Le hub devient alors le point d’articulation de la résolution privée.

Hub connectivity
Private DNS Zones de plateforme
Azure DNS Private Resolver
Inbound endpoint pour les requêtes entrantes
Outbound endpoint pour les règles de forwarding
Rulesets associés aux suffixes privés et hybrides

Spokes applicatifs
Consomment les suffixes nécessaires
Ne créent pas de zones privées locales sans convention
Utilisent le chemin DNS défini par la plateforme

Environnement hybride
Transfère les suffixes Azure privés vers l'inbound endpoint
Reçoit éventuellement certains suffixes internes depuis Azure
Documente les responsabilités entre DNS interne et DNS Azure

Le choix entre ces modèles dépend de la taille de l’environnement, du niveau de centralisation attendu et de la présence d’un DNS personnalisé. Pour Naxaya, le point important est moins de défendre un modèle unique que de rendre le modèle explicable. Un schéma DNS privé doit permettre de répondre rapidement à une question simple : si une machine dans ce spoke interroge ce FQDN, quel serveur DNS reçoit la requête, quelle règle s’applique, et quelle zone fournit l’enregistrement ?

Éviter le réflexe de tout lier partout

Quand un incident DNS survient, la tentation consiste souvent à ajouter un lien VNet ou à élargir une règle. Cette méthode peut rétablir un service rapidement, mais elle laisse une dette d’exploitation. Si toutes les zones sont liées à tous les VNets, la résolution fonctionne parfois par excès de permissivité plutôt que par conception.

Ce modèle rend les environnements difficiles à auditer. Un spoke applicatif peut résoudre des noms privés qui n’ont rien à voir avec son périmètre. Une équipe peut croire qu’un service est isolé alors que son nom privé est résoluble depuis d’autres segments. Le DNS n’est pas un contrôle d’accès au sens strict, mais il participe à la compréhension de la surface privée. Une résolution trop large brouille cette compréhension.

Une approche plus propre consiste à définir des profils de consommation. Un spoke applicatif standard a besoin d’un nombre limité de zones. Un spoke d’administration peut avoir un profil plus large. Un spoke de données peut consommer des zones liées au stockage, aux bases de données et aux services de secrets. Un environnement isolé peut recevoir uniquement les zones strictement nécessaires. Cette logique oblige à documenter les besoins au lieu d’ajouter des liens par réflexe.

Elle permet aussi de mieux gérer les droits. Les équipes applicatives n’ont pas toujours besoin de pouvoir modifier les zones privées. Elles doivent pouvoir demander un Private Endpoint, vérifier le résultat et tester la résolution. La création de la zone, le lien VNet et la convention de nommage peuvent rester côté plateforme. Cela réduit les erreurs de configuration et évite les zones orphelines.

Gérer les enregistrements et le cycle de vie

La question des enregistrements est aussi importante que celle des zones. Pour les Private Endpoints, l’intégration DNS doit autant que possible suivre le cycle de vie du endpoint. Lorsque la ressource est créée, l’enregistrement privé doit apparaître dans la bonne zone. Lorsque le endpoint est supprimé, l’enregistrement ne doit pas rester comme une trace morte.

Les enregistrements manuels doivent rester l’exception. Ils peuvent être utiles pour un cas transitoire, une migration, un test ou une intégration particulière. Mais s’ils deviennent la norme, la zone perd sa fiabilité. Une adresse privée peut changer. Un endpoint peut être recréé. Une ressource peut être déplacée. Une entrée laissée à la main peut continuer à répondre pendant des mois alors que le service réel n’existe plus ou n’est plus au bon endroit.

Le problème apparaît souvent lors des migrations. Une équipe bascule un service vers Private Link, ajoute un enregistrement pour rétablir la résolution, puis ne revient jamais sur cette décision. Quelques mois plus tard, un autre projet crée un endpoint du même type. La zone contient déjà des noms, certains automatiques, d’autres manuels, et plus personne ne sait lesquels sont encore nécessaires.

Une bonne exploitation doit donc prévoir une revue régulière des zones. Il faut pouvoir associer un enregistrement à une ressource, à un Private Endpoint, à une équipe ou à une décision documentée. Quand ce lien n’existe pas, l’enregistrement devient suspect. Le DNS privé doit rester un inventaire vivant, pas une accumulation d’exceptions.

DNS hybride et responsabilité partagée

Le cas hybride est souvent celui qui révèle les limites du design initial. Tant que les workloads sont uniquement dans Azure et utilisent le DNS Azure par défaut, la résolution peut rester relativement simple. Dès qu’un datacenter, un réseau industriel, un domaine Active Directory ou une plateforme externe doit résoudre des noms privés Azure, il faut penser en termes de forwarding.

Le DNS interne doit savoir quels suffixes envoyer vers Azure. Azure doit parfois savoir quels suffixes renvoyer vers le DNS interne. Les règles doivent être précises. Transférer un domaine trop large peut provoquer des effets de bord. Transférer un domaine trop étroit peut laisser certains services hors du chemin attendu. Les suffixes privatelink doivent être traités avec attention, car ils correspondent à des services Azure précis et leur usage doit suivre les recommandations de nommage du service concerné.

Le point opérationnel le plus important est la responsabilité. Si une requête part d’un serveur on premises et échoue, qui diagnostique ? L’équipe réseau interne voit une requête qui part vers Azure. L’équipe Azure voit un resolver qui reçoit ou ne reçoit pas la requête. L’équipe applicative voit seulement un timeout. Sans responsabilité claire, le DNS devient un sujet transversal sans propriétaire réel.

Dans une architecture propre, le chemin de résolution hybride doit être documenté avec les adresses des endpoints, les suffixes transférés, les VNets associés, les rulesets utilisés et les tests attendus. Il ne suffit pas de dire que le DNS hybride est configuré. Il faut pouvoir prouver depuis les deux côtés que le bon chemin est utilisé.

Tester le DNS comme une dépendance applicative

Le DNS privé doit être testé comme une dépendance applicative. Une application qui utilise un compte de stockage privé, un Key Vault ou une base de données privée dépend de la résolution de nom autant que de la connectivité réseau. Tester uniquement le port ou la route ne suffit pas si le nom résout vers la mauvaise adresse.

Les tests doivent partir des emplacements réels. Une VM de test dans le hub ne prouve pas que le spoke applicatif fonctionne. Un test depuis un poste d’administration ne prouve pas que le conteneur dans un subnet isolé utilise le bon resolver. Chaque profil de spoke devrait avoir au moins un scénario de vérification simple.

# Depuis une machine située dans le spoke à valider
nslookup myaccount.blob.core.windows.net
nslookup myvault.vault.azure.net

# Vérifier le resolver réellement utilisé
nslookup myaccount.blob.core.windows.net 168.63.129.16

# Comparer avec le DNS configuré sur le système
cat /etc/resolv.conf
systemd-resolve --status 2>/dev/null || resolvectl status

Le résultat attendu n’est pas seulement une réponse DNS. Il faut vérifier que l’adresse retournée est bien une adresse privée cohérente avec le Private Endpoint attendu. Il faut aussi vérifier que le nom canonique et la chaîne de résolution correspondent au service. Un test qui retourne une adresse publique peut passer inaperçu si l’application a encore une sortie Internet. Le risque est alors de croire que le Private Endpoint est utilisé alors que le trafic continue à sortir autrement.

Pour les environnements Windows, le même principe s’applique avec nslookup, Resolve-DnsName et la vérification du serveur DNS configuré sur l’interface. L’important est de tester depuis la bonne zone réseau, avec le même chemin que le workload.

Resolve-DnsName myaccount.blob.core.windows.net
Resolve-DnsName myvault.vault.azure.net
Get-DnsClientServerAddress

# Test explicite contre un resolver donné
Resolve-DnsName myaccount.blob.core.windows.net -Server 168.63.129.16

Ces tests doivent entrer dans le déploiement. Une pipeline Terraform, Bicep ou Ansible qui crée un Private Endpoint devrait idéalement produire aussi une vérification de résolution. Sans cela, le déploiement peut être techniquement réussi mais inutilisable pour le workload.

Les erreurs fréquentes

La première erreur consiste à créer une zone privée avec un nom approximatif. Pour les services Azure exposés via Private Endpoint, le nom de zone attendu dépend du service. Une zone mal nommée peut contenir des enregistrements, mais ne pas intercepter la résolution attendue par le client.

La deuxième erreur consiste à oublier le DNS personnalisé. Beaucoup d’incidents viennent de là. Le lien VNet existe, mais le client interroge un DNS interne qui ne sait pas transférer le suffixe privé. Le diagnostic part alors dans la mauvaise direction, car tout semble correct côté Azure.

La troisième erreur consiste à créer des zones en double dans plusieurs subscriptions. À court terme, chaque équipe pense gagner du temps. À moyen terme, l’environnement devient incohérent. Deux zones avec le même nom peuvent contenir des enregistrements différents. Le résultat dépend du VNet, du resolver ou de la règle utilisée.

La quatrième erreur consiste à mélanger les responsabilités. Une équipe applicative crée le Private Endpoint, une équipe réseau crée le lien DNS, une équipe identité gère le DNS interne, et personne ne possède le chemin de bout en bout. Ce modèle fonctionne tant qu’il n’y a pas d’incident. Lorsqu’un problème apparaît, chaque équipe valide son morceau sans voir la chaîne complète.

La cinquième erreur consiste à utiliser le DNS comme une correction rapide. Ajouter une entrée manuelle peut débloquer une situation, mais il faut ensuite revenir à un modèle automatisé ou documenté. Sinon, la zone devient progressivement un stock d’exceptions.

Un modèle d’exploitation plus simple

Pour garder une architecture lisible, il faut réduire le nombre de décisions implicites. Les zones privées de plateforme doivent avoir un emplacement connu. Les liens VNet doivent correspondre à des profils de consommation. Les suffixes transférés doivent être documentés. Les enregistrements manuels doivent être exceptionnels. Les tests de résolution doivent être exécutés depuis les réseaux réellement concernés.

Une convention simple peut suffire. Elle doit répondre à quelques questions : où vit la zone, qui peut la modifier, quels VNets peuvent la consommer, quel resolver est utilisé, comment un nouveau Private Endpoint est ajouté, comment un enregistrement est supprimé, et comment une équipe prouve que la résolution fonctionne.

Décision de plateforme
Les zones privatelink sont centralisées ou créées selon une convention documentée
Les liens VNet suivent des profils de consommation
Les DNS personnalisés doivent transférer les suffixes privés vers le resolver prévu

Décision applicative
Le besoin de résolution privée est déclaré avec le Private Endpoint
Les tests sont exécutés depuis le spoke consommateur
Les exceptions DNS manuelles sont limitées et documentées

Décision d'exploitation
Les zones sont revues régulièrement
Les enregistrements orphelins sont nettoyés
Le chemin DNS est connu avant l'incident

Cette approche évite de transformer les Private DNS Zones en sujet invisible. Le DNS privé devient une partie explicite de l’architecture réseau. Il n’est plus seulement créé pour satisfaire un assistant de configuration Azure, mais exploité comme une dépendance centrale des workloads privés.

Conclusion

Les Private DNS Zones en hub and spoke ne sont pas un détail d’implémentation. Elles forment une couche d’architecture qui conditionne l’usage réel des Private Endpoints et la cohérence d’une plateforme privée. Un modèle correct ne se limite pas à créer les zones attendues. Il décrit le chemin de résolution, la place du DNS personnalisé, les liens nécessaires, les règles de forwarding et les responsabilités d’exploitation.

Dans une architecture Azure existante, la bonne question reste très concrète : lorsqu’un workload interroge le nom d’un service privé, quel resolver reçoit la requête, quelle règle s’applique, quelle zone répond, et quelle adresse est retournée ? Si cette chaîne peut être expliquée et testée simplement, le modèle DNS est exploitable. Si elle dépend de liens ajoutés au hasard, d’enregistrements manuels ou de forwarders non documentés, le DNS privé devient une source récurrente d’incidents.