Microsoft AZ-700: Azure DNS et résolution de noms — Guide d'étude

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Network Engineer AZ-700 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Azure DNS : zones publiques, zones privées et compromis

Azure fournit à la fois un hébergement DNS public et une résolution DNS privée étroitement intégrés au plan de réseau virtuel, et le choix entre les deux est une question de portée, de contrôle, de coût et de surcharge opérationnelle. Les zones Azure DNS publiques (hébergées dans Azure DNS) sont appropriées pour les noms accessibles depuis Internet et bénéficient de points de terminaison anycast mondiaux, d’une gestion prévisible via API et d’une mise à l’échelle par requête. Les zones DNS privées vous permettent de créer des noms de zone qui se résolvent uniquement en adresses IP privées à l’intérieur des VNets liés ; elles éliminent le besoin d’exécuter et de maintenir des machines virtuelles DNS pour la résolution de noms intra-Azure et prennent en charge la gestion automatique des enregistrements lorsqu’elles sont intégrées à certains points de terminaison privés PaaS. Le principal compromis est le contrôle : les serveurs DNS personnalisés (Windows DNS, BIND) offrent une flexibilité absolue — redirection conditionnelle, stratégies avancées et comportement SRV/CNAME intégré à AD — au prix d’une surcharge de gestion des machines virtuelles et de la responsabilité de la résilience. Les choix de performance se résument à la latence par rapport au coût : les services Azure DNS gérés réduisent la maintenance et fournissent une vitesse de résolution globale pour les requêtes publiques, tandis que les redirecteurs DNS ou les appliances de résolution résidant dans un hub peuvent améliorer les performances hybrides et appliquer des stratégies, mais ajoutent des coûts de calcul et de disponibilité. Les pièges courants incluent l’oubli de lier une zone DNS privée à chaque VNet qui a besoin de la résolution, l’échec de la migration des délégations lors du déplacement de noms depuis un environnement sur site (on-prem) vers Azure, et s’attendre à un comportement split-horizon public-privé automatique sans enregistrements DNS ou redirection explicites.

Azure DNS (Public) : anycast mondial, API gérée, facturation par zone/requête.
Zones DNS privées (Private DNS zones) : résolution limitée au VNet, création automatique d’enregistrements privés pour les services PaaS pris en charge.
App Gateway WAF_v2 : recommandé pour les fonctionnalités WAF modernes et le modèle de mise à l’échelle v2.
Azure Firewall (Standard/Policy) : option de proxy DNS central ; ajoute un coût mais centralise la stratégie.
DNS personnalisé (basé sur des VM) : contrôle maximal, coûts d’exploitation et de disponibilité plus élevés.

Zones DNS privées, enregistrements de points de terminaison privés et stratégies de nommage

Lorsque vous convertissez des services hébergés publiquement en points de terminaison privés ou que vous migrez des serveurs vers Azure, le DNS devient le point de coordination. Les points de terminaison privés enregistrent des enregistrements A au niveau de la carte réseau (NIC) dans des zones DNS privées qui doivent correspondre au FQDN public que vous souhaitez que les clients utilisent ; le bon modèle consiste à créer des zones privées qui reflètent l’espace de noms public (par exemple, contoso.com) ou à utiliser des zones privatelink spécifiques au service (pour les services de plateforme), puis soit à activer l’enregistrement automatique, soit à créer manuellement des enregistrements A/CNAME mappant le FQDN à l’adresse IP privée du point de terminaison. La portée est importante : lier une zone privée à un seul VNet limite la résolution à ce VNet ; les conceptions en étoile (hub-and-spoke) nécessitent de lier la zone à tous les spokes ou d’utiliser la redirection DNS des spokes vers un résolveur de hub. Un piège de migration typique consiste à laisser le DNS public pointer vers l’ancienne IP sur site (on-prem) pendant que les clients Azure résolvent vers une IP privée ; pour éviter la confusion du type “split-brain”, planifiez des étapes de basculement claires — mettez à jour les enregistrements publics uniquement après la validation du DNS privé et de la redirection, ou utilisez un nommage split-horizon avec une zone privée explicite pour le même nom. Les certificats et les en-têtes d’hôte (host headers) doivent correspondre : si vous vous attendez à ce que Application Gateway effectue un chiffrement TLS de bout en bout vers un backend privé, assurez-vous que le CN/SAN du certificat du backend correspond au nom d’hôte que la passerelle envoie comme en-tête Host ; sinon, le TLS du backend échouera.

Azure Private Resolver et modèles de résolution de noms hybride

Azure Private Resolver permet une redirection DNS gérée et évolutive entre les VNets Azure et les réseaux sur site (on-premises) sans avoir à posséder de machines virtuelles DNS. Les modèles de conception placent généralement les points de terminaison du résolveur dans un VNet hub : les points de terminaison entrants reçoivent les requêtes provenant de l’environnement sur site (via VPN/ExpressRoute) pour les zones privées Azure, tandis que les points de terminaison sortants redirigent les requêtes Azure vers les serveurs DNS sur site pour les noms internes uniquement. Les ensembles de règles du résolveur (resolver rule sets) définissent la redirection conditionnelle pour des espaces de noms spécifiques (par exemple, contoso.internal → adresses IP des DNS sur site) et peuvent être associés à des VNets ; pour les déploiements d’entreprise mondiaux, vous centralisez la gestion des règles dans le hub et effectuez un peering ou un routage du trafic des spokes vers le résolveur du hub. Les compromis entre performance et coût incluent le provisionnement de plusieurs points de terminaison entrants dans différentes régions pour la résilience et la latence (ce qui ajoute un coût) ou l’acceptation de points de terminaison de résolveur dans une seule région avec du peering mais une latence inter-régions plus élevée. Les pièges courants : ne pas mettre à jour les redirecteurs conditionnels sur site pour qu’ils pointent vers les adresses IP entrantes du résolveur, mal configurer les règles de groupe de sécurité réseau (NSG) qui bloquent le trafic DNS TCP/UDP sur le port 53 vers les points de terminaison du résolveur, et supposer que le DNS fourni par Azure (168.63.129.16) redirigera vers l’environnement sur site — une configuration explicite du résolveur est requise pour la redirection conditionnelle.

Ports DNS : les ports 53 UDP et 53 TCP doivent être autorisés pour la résolution standard et les transferts de zone.
Points de terminaison du résolveur (Resolver endpoints) : à déployer dans les VNets hub ; s’assurer que les NSG et les pare-feu autorisent le DNS entrant.

Serveurs DNS personnalisés, proxy DNS et pièges opérationnels

Les serveurs DNS personnalisés (contrôleurs de domaine DNS Windows ou BIND Linux) restent pertinents lorsque l’intégration avec Active Directory, des redirections conditionnelles complexes ou des stratégies DNS avancées sont nécessaires ; cependant, ils introduisent des responsabilités opérationnelles — application de correctifs, clustering HA, sauvegardes et mise à l’échelle. Les alternatives qui réduisent les opérations sont les zones Azure Private DNS pour la résolution intra-Azure et Azure Private Resolver ou le proxy DNS d’Azure Firewall pour centraliser les stratégies de redirection. Les proxys DNS (la fonctionnalité de proxy DNS d’Azure Firewall ou des NVA tiers) peuvent intercepter et rediriger les requêtes DNS vers des résolveurs sélectionnés, ce qui simplifie la gestion des stratégies et la journalisation, mais peut ajouter des points de défaillance uniques et une latence supplémentaire. Les décisions de conception clés incluent le choix entre l’utilisation de redirecteurs basés sur des VM dans un hub (coût inférieur, maintenance plus élevée) et Azure Private Resolver (géré, meilleure mise à l’échelle), le nombre de points de terminaison de résolveur à déployer entre les régions pour la latence/résilience, et l’activation ou non de l’enregistrement DNS automatique des points de terminaison privés. Les erreurs fréquentes des ingénieurs consistent à se fier uniquement au peering de VNet pour la résolution DNS (le peering ne partage pas automatiquement les zones Azure Private DNS), à oublier d’accorder au Private Endpoint la permission d’enregistrer automatiquement les enregistrements DNS, et à négliger la validation des chaînes de certificats lors de la mise en œuvre du TLS de bout en bout via une passerelle — toutes ces erreurs interrompent la résolution de noms ou les connexions sécurisées en production.

Problème pratique : Scénario d’utilisation

Scénario : Fabrikam Inc. exploite un réseau Azure hub-and-spoke multi-régions. Le hub dans la région East US contient un Azure Firewall (Standard) et un profil Traffic Manager achemine les utilisateurs Internet vers des instances Application Gateway WAF_v2 dans deux régions. Deux instances App Service hébergent www.fabrikam.com, chacune ayant été migrée depuis l’environnement on-prem avec des points de terminaison privés dans leurs spokes régionaux.

Défi : Les clients on-prem et les spokes Azure doivent résoudre www.fabrikam.com vers les points de terminaison privés de l’App Service après la migration, Application Gateway doit préserver les en-têtes d’hôte pour permettre le TLS de bout en bout, et la résolution DNS doit être résiliente entre les régions.

Approche recommandée :

Déployez une zone Azure Private DNS nommée fabrikam.com dans le hub et liez-la aux VNet des deux spokes régionaux ainsi qu’au VNet du hub ; ajoutez des enregistrements A pour www.fabrikam.com pointant vers les adresses IP des points de terminaison privés (ou activez l’enregistrement automatique pour les points de terminaison privés de l’App Service).
Déployez des points de terminaison entrants Azure Private Resolver dans le hub (un par région pour la résilience si nécessaire) et configurez des redirecteurs conditionnels on-prem pour rediriger les requêtes fabrikam.com vers les adresses IP entrantes du résolveur.
Configurez les paramètres HTTP de l’Application Gateway WAF_v2 pour utiliser HTTPS sur le port 443, définissez l’en-tête d’hôte du backend sur www.fabrikam.com, et assurez-vous que les sondes d’intégrité du backend utilisent HTTPS avec un en-tête d’hôte correspondant au CN/SAN du certificat.
Validez en exécutant des requêtes DNS depuis l’environnement on-prem et depuis les spokes pour vous assurer qu’elles retournent des adresses IP privées, et vérifiez le TLS de bout en bout de l’Application Gateway en contrôlant le CN/SAN du certificat et le succès des sondes.

Justification : La centralisation des fonctionnalités de DNS privé et de résolveur dans le hub fournit une source de vérité unique et simplifie la redirection conditionnelle hybride ; lier la zone privée à tous les VNet et s’assurer que la passerelle utilise le bon en-tête d’hôte préserve la validation du certificat pour le TLS de bout en bout, équilibrant ainsi la facilité de gestion opérationnelle, la performance et la résilience.

← Réseau hybride · Tous les domaines · Sécurité du réseau →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →