Et si aujourd’hui, nous parlions, Azure “Private DNS Zone”. Les petites zones DNS qui sont presque créées de manière transparente lorsque l’on crée un “Private EndPoint” et permettent la résolution de nos ressources Azure PaaS (ex. : compte de stockage) via leurs adresses IP privées.
Prenons par exemple un compte de stockage de type “blob” qui a pour nom :
- monstockage.privatelink.blob.core.windows.net
Il sera par défaut résolu via son adresse IP publique. Cependant lorsque j’utilise un “Private EndPoint”, je souhaite que ce même compte de stockage soit résolu par l’adresse IP privée du “Private EndPoint”. Cette résolution est possible grâce aux “Private DNS Zone”.
Rien de techniquement très complexe tant que l’on reste dans le monde Azure. Étant donné que le service DNS Azure fait très bien son travail et que tout est configuré par défaut. Cependant, je m’aperçois que le service DNS Azure devient pour beaucoup plus obscur lors de l’utilisation de “Custom DNS” et de l’intégration de celui-ci dans le monde On-Premise. Nous allons essayer d’éclaircir tout ça dans cet article.
Sommaire
Azure only
Pour commencer, nous allons prendre un cas simple. Accéder depuis une VM Azure (ici CLT02) à un compte de stockage de type blob au travers d’un “Private EndPoint”.
L’infrastructure Azure est composée de :
- 1 vNet “cloud_vnet” (10.2.0.0/16) lui-même composé des subnets suivants :
- default (10.2.0.0/24) –> réseau où seront connectés les VM.
- PrivateEndpoint (10.2.1.0/24) –> réseau où seront connectés les Pirvate EndPoint.
- GatewaySubnet (10.2.3.0/24) –> réseau pour une future interconnexion avec le monde On-Premise.
- AzureBastionSubnet (10.2.2.0/24) –> réseau d’Azure Bastion pour l’administration des VM.
- 1 Private DNS zone “privatelink.blob.core.windows.net” –> cette zone n’est liée à aucun vNet pour le moment.
- 1 VM « Clt02 ».
- 1 Storage Account “filesharestk001” connecté via un “Private Endpoint » au Subnet « PrivateEndpoint ».
Depuis la VM “CLT02”, si j’essaie de résoudre le service endpoint de mon compte de stockage (blob) :
- filesharestk001.blob.core.windows.net
Dans les fais le “Private EndPoint” du service blob de ce compte de stockage possède l’adresse IP “10.2.1.4”, cependant comme expliqué plus haut, la zone DNS privée n’est liée à aucun vNet. Par conséquant, la résolution DNS renvoie l’adresse IP publique du compte de stockage (ici : 20.60.222.107).
Maintenant, si je lie la “Private DNS Zone” où le “Private EndPoint” est enregistré au vNet sur lequel la VM CLT02 est connectée, la résolution privée fonctionne.
Notons qu’aucune modification de la configuration du client DNS n’a eu lieu.
Du côté de la "Private DNS Zone"
Du côté de la “Private DNS Zone”, nous pouvons vérifier le contenu de la zone :
Nous constatons qu’un enregistrement de type A correspondant à notre “Private EndPoint” est présent. Cependant, d’autres enregistrements sont eux aussi présents, correspondant à la VM “CLT02”, la VNG /LNG provisionné pour une future interconnexion et à un Azure Bastion pour la prise de contrôle sur les machines.
La capacité de créer automatiquement les enregistrements DNS dans la zone est possible grâce à l’option “Auto-Registration” positionnée sur la liaison entre la zone DNS et le vNet.
Du côté du client DNS
Si l’on regarde la configuration du client DNS de notre VM “CLT02”, le serveur DNS renseigné est “168.63.129.16”.
Notons qu’il n’y a pas eu de modification de la configuration DNS sur le vNet ou la NIC de la VM.
Le serveurs DNS “168.63.129.16” est le service DNS d’Azure. La configuration de ce service est managé par Microsoft. Toute le documentation est disponible dans le lien ci-dessous :
Dans les grandes lignes, ce service est le DNS par défaut de l’environnement Azure. Il offre la résolution publique à nos ressources et surtout il a la capacité à surcharger les enregistrements appartenant au monde Microsoft public par le contenu des zones “Private DNS Zone” qui lui sont présentées.
Résumé
En résumé, nous pouvons conclure qu’une “Private DNS zone” contient les enregistrements DNS privés de nos ressources Azure.
Le service DNS d’Azure “168.63.129.16” permet à la fois une résolution des ressources publiques et une résolution privée des enregistrements présents dans une “Private DNS Zone” liée au vNet auquel le client DNS (machine cliente) est connecté. Donc le “168.63.129.16” est le DNS magique de Microsoft !!!
L’option “Auto-Registration” permet la création automatique des ressources dans la “Private DNS Zone”.
Pour chaque service Azure ayant la capacité à utiliser les “Private EndPoint”, il est possible de créer un enregistrement DNS privé dans une “Private DNS Zone” correspondant à ce service. Dans l’exemple ci-dessus, nous avons utilisé le cas le plus simple. Celui d’un compte de stockage Azure (blob). A chaque type de service Azure, il correspond une zone DNS particulière qu’il est nécessaire de créer au besoin. La liste est disponible dans le lien ci-dessous :
- https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-dns#azure-services-dns-zone-configuration
Le service “Private DNS Zone” est multi-régions. Ce qui signifie qu’une zone hébergée en “West Europe” peut tout aussi bien être connectée à une vNet hébergé sur “West Europe” que sur “East US”.
Cependant, le niveau de disponibilité du service à lié à la dans laquelle il a été déployé. une région (multi zones). Ce qui signifie que si mon service est déployé dans la région “West Europe”, si la région “West Europe” devait être indisponible, je ne pourrais plus accèder à ce service depuis une autre région (ex. : “East US”).
Selon les architectures que vous allez déployer, il est possible de créer la même zone DNS plusieurs fois. Attention tout de même un vNet ne peut être connecté qu’à une seule et unique “Private DNS Zone” du même nom.
Dans le monde Hybrid
Sur notre maquette, nous allons ajouter une partie On-Premise. Cette partie est simplement composée d’une machine cliente “CLT01” et d’un contrôleur de domaine (domaine : teddy.lab) “DC01”.
L’infrastructure On-Premise est interconnectée au monde Azure via une connexion VPN Site-à-Site (d’où la présence d’une VNG /LNG précédemment).
Notons qu’aucun contrôleur de domaine ou serveurs DNS n’a été déployé côté Azure.
Comme nous avons pu le constater dans le cas précédent, la résolution des ressources Azure est possible via le service DNS d’Azure “168.63.129.16” depuis une machine connectée à un vNet où la /les “Private DNS Zones” sont liées. Cependant, dans l’architecture ci-dessus, aucune machine possédant le rôle serveur DNS n’est déployée dans l’environnement Azure.
Il n’est donc pas possible dans l’immédiat de résoudre les ressources Azure depuis le monde On-Premise.
De plus, les machines Azure, ne sont pas non plus en mesure de résoudre (point de vue DNS) les machines On-Premise ou le domaine ADDS.
La première étape dans cette situation est de configurer pour les machines Azure leur serveur DNS.
vNet custom DNS
Le serveur DNS doit être celui du contrôleur de domaine “DC01” présent On-Premise.
Cette configuration est possible via l’option “Custom DNS” du vNet Azure.
Afin que la nouvelle configuration DNS soit prise en compte par les machine Azure, le redémarrage de celle-ci est nécessaire.
Cette fois-ci, les requêtes DNS partent vers le contrôleur de domaine “DC01”, tout fonctionne pour la résolution depuis les machines Azure des ressources On-Premise. Sauf que je ne peux plus résoudre les “Private EndPoint”.
Donc, soit je suis en capacité de résoudre les ressources Azure, soit je suis en capacité de résoudre les ressources On-Premise, mais pas les deux …
Pour résoudre l’ensemble des zones DNS depuis le monde Azure ou le monde On-Premise, il y a deux solutions :
- Avoir un serveur DNS sur Azure.
- Déclarer manuellement les zones Azure sur le DNS On-Premise et alimenter ces mêmes zones manuellement.
Dans la suite de cet article, nous allons déployer la première solution “Mettre un serveur DNS dans Azure”. La seconde solution, ne comporte pas de difficulté technique particulière. Cependant, elle est lourde à maintenir, je déconseille cette solution et ne la traiterai pas.
Configuration d'un serveur(s) DNS dans Azure
L’architecture qui a été retenue est la suivante (ajout par rapport à la précédente) :
- 1 VM Azure “DNS01” –> Serveur DNS pour résoudre les “Private DNS Zone”.
- 1 VM Azure “DC002” –> Contrôleur de domaine du domaine “Teddy.lab”.
Il s’agit d’une maquette. Dans un environnement de production, il vous faudra assurer la haute disponibilité des services DNS et ADDS. De plus par souci de simplicité, j’ai mis l’ensemble des ressources dans le même vNet. En production, il conviendra de positionner chacun de ces composants dans une landing zone dédiée (Identity) et appliquer la sécurité en conséquent (Réseau, IAM, …).
Le choix d’ajouter un serveur DNS dédié pour résoudre les zones DNS Azure plutôt que d’utiliser le serveur DNS des contrôleurs de domaine est motivé par :
- La taille de votre domaine ADDS.
- La topologie de l’architecture DNS de votre entreprise.
En effet, la résolution des enregistrements DNS Azure ne peut être réalisée uniquement par une machine donc :
- La ou les “Private DNS zone” sont liées au vNet sur lequel elle est connectée.
- Et au travers du service DNS Azure “168.63.129.16”.
En conséquent, les zones DNS seront matérialisées par un “conditional forwarder”.
Ces “conditionalforwarder” auront un serveur DNS différent qu’ils soient sur Azure ou On-Premise. A savoir :
- On-Premise : les serveurs DNS hébergés sur Azure.
- Azure : le service DNS Azure “168.63.129.16”.
Dans ce cas de figure, et selon la taille de votre environnement ADDS, il peut être difficile de déclarer manuellement /maintenir l’ensemble des zones sur l’ensemble des serveurs ADDS. Il devient donc plus simple de stocker les “conditional forwarder” dans Active Directory afin que l’ensemble des sereurs ADDS soient en mesure de résoudre les zones DNS Azure au travers de serveurs DNS dédiés. Ce qui a pour effet de donner la configuration suivante :
- Serveurs ADDS : “conditional forwarder” pointe vers les serveurs DNS Azure dédiés.
- Serveurs DNS Azure : “conditional forwarder” pointe vers le service DNS Azure “168.63.129.16”.
Dans l’architecture décrite ci-dessus, nous allons déclarer une nouvelle zone DNS Azure à la fois sur :
- ADDS :
- Type “Conditional forwarder”.
- Serveur cible : DNS01 (10.2.0.6).
- Server DNS “DNS01” (VM Azure) :
- Type “Conditional forwarder”.
- Serveur cible : Azure DNS service (168.63.129.16).
Nous allons donc commencer par ajouter un nouveau contrôleur de domaine sur Azure “DC002”.
Cet article n’étant pas orienté Active Directory, je ne détaille pas la partie promotion du nouveau contrôleur de domaine, ni la configuration d’Active Directory (ajout du nouveau site AD “Azure”). Cependant, avant de déployer un nouveau Contrôleur de Domaine sur Azure, je vous invite à vous renseigner sur les bonnes pratiques techniques et organisationnelles (CAF).
Configuration ADDS conditionnal forwarder
Maintenant que notre nouveau Contrôleur de Domaine (et DNS) est déployé côté Azure, il est nécessaire de reconfigurer la partie “Custom DNS” du vNet Azure en indiquant comme serveur DNS primaire le nouveau DC “DC002” et en secondaire le contrôleur de domaine On-Premise “DC001”.
Pour continuer, nous allons installer un nouveau serveur “DNS01” et installer le rôle DNS Server sur celui-ci. Dès lors que ce serveur DNS est disponible, nous pouvons ajouter un nouveau “Conditional forwarder” :
- “privatelink.blob.core.windows.net” –> Server DNS : 168.63.129.16.
À ce stade, les machines ne sont toujours pas en mesure de résoudre “filesharestk001.privatelink.blob.core.windows.net”, car pour rappel les requêtes DNS de toutes les machines connectées sur le réseau passent par les contrôleurs de domaine.
Configuration DNS Azure conditionnal forwarder
Il ne nous reste plus qu’à déclarer ce même “Conditional forwarder” sur les contrôleurs de domaine, avec comme serveur DNS notre serveur “DNS01”. De plus, la zone sera enregistrée au niveau de la Forest ADDS, ce qui nous évite de devoir ajouter ce même “Conditional forwarder” sur l’ensemble des contrôleurs de domaine.
Désormais, depuis une machine cliente hébergée sur Azure ou On-Premise (ici : “CLT01” qui est On-Premise), nous sommes en mesure de résoudre notre blob via son adresse IP privée.
Comme nous pouvons le constater sur la capture d’écran ci-dessous, le serveur DNS de “CLT01” est “DC001” le contrôleur de domaine On-Premise.
Cette même logique est à appliquer pour l’ensemble des “Private DNS zone” d’Azure, par exemple :
- “privatelink.file.core.windows.net” –> Azure file.
- “privatelink.database.windows.net” –> Azure MS SQL.
- …
Et surtout en plus de résoudre et d’accéder aux ressources via une adresse IP privée, il est possible de restreindre le Firewall de nos services Azure à l’usage de “Private EndPoint” uniquement et par conséquent augmenter la sécurité de nos infrastructures. Sans oublier la multitude de possibilités supplémentaires comme joindre les comptes de stockage (files) à nos domaines ADDS.
Le chemin d'une requète DNS
Ci-dessous un diagramme correspondant au chemin qu’emprunte une requête DNS dans ce cas de figure.
Il s’agit d’un type d’architecture possible. Vous pouvez trouver d’autres architectures elles aussi tout aussi fonctionnelles selon vos besoins. Dans le cas du déploiement de ce type d’architecture, il conviendra de redonder le service DNS “DNS01” en ajoutant une seconde machine + “Availability Set” ou Zone.
L’usage de cette architecture permet un minimum d’action de type MCO dès lors que le nombre de contrôleurs de domaine est élevé dans votre organisation.
Liens annexes
- https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-dns
- https://docs.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16
- https://docs.microsoft.com/en-us/azure/availability-zones/az-region#an-icon-that-signifies-this-service-is-foundational-foundational-services
- https://docs.microsoft.com/en-us/azure/dns/private-dns-getstarted-portal
Bonjour Benoit,
Merci pour cet article très riche.
Une petite remarque:
Quand tu écris “L’option “Auto-Registration” permet la création automatique des ressources dans la “Private DNS Zone”.” , ceci n’est valable que pour les VM à ma connaissance. Un private endpoint n’est pas concerné il me semble: Tu confirmes.
Et une petite question:
Quand un Custom DNS record est créé dans un private endpoint Azure, est-il nécessaire que la zone DNS s’appelle privatelink.****.azure.net pour que l’auto enregistrement de ta ressource dans cette zone DNS privée ?
Merci de ton retour, keep sharing knowledge teddy
Bonjour Charles,
Avec plaisir 🙂
Quand tu écris “L’option “Auto-Registration” permet la création automatique des ressources dans la “Private DNS Zone”.” , ceci n’est valable que pour les VM à ma connaissance. Un private endpoint n’est pas concerné il me semble: Tu confirmes. –> Ceux-ci concerne tout type de (à ma connaissance) “private endpoint” (stk, db …) à condition que le “private endpoint” soit configuré sur la bonne “Private DNS Zone”, ou plutôt sur la zone DNS correspondant à son type (généralement privatelink..windows.net).
Quand un Custom DNS record est créé dans un private endpoint Azure, est-il nécessaire que la zone DNS s’appelle privatelink.****.azure.net pour que l’auto enregistrement de ta ressource dans cette zone DNS privée ? –> Oui, à chaque type de private endpoint correspond une zone et le nom de cette zone est stricte, pas de custom.
https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns#azure-services-dns-zone-configuration
For Azure services, use the recommended zone names as described in the following table: –> “use” devrait être remplacé par “should be”.
En espérant avoir répondu à tes attentes.
Benoit