Azure Private DNS Resolver : optimiser la résolution DNS dans un Environnement Azure

Azure DNS Private DNS est disponible depuis un certain temps à présent. Cet article propose une vue d’ensemble de ce service, précédée d’un rappel des fondamentaux de la résolution DNS dans Azure.

Notre agenda sera le suivant :

1. Gérer la résolution DNS dans Azure
2. DNS dans une infrastructure hybride
3. Exemple de configuration dans une topologie VWAN

Gérer la résolution DNS dans Azure

Base du DNS

Le DNS (Domain Name System) est un service incontournable de notre monde connecté. Il est beaucoup plus simple de retenir un nom de domaine qu’une suite de chiffres correspondant à une adresse IP, notamment avec IPv6.

Dans le cadre d’Azure, Microsoft prend en charge ses propres domaines DNS. L’utilisateur n’a donc aucune configuration à effectuer.

Microsoft permet aussi de gérer des DNS public mais ne fait pas office de Registrar.  Dans ce cas, il est nécessaire de gérer la délégation de la zone DNS depuis le registrar du nom de domaine en question. Les enregistrements NS présents dans la zone DNS publique Azure doivent être configurés dans la console du registrar.

Mais que se passe-t-il dans le cas de nom DNS privés pour des workloads non accessibles sur Internet ?

Il s’agit ici de workloads résidant dans un Virtual Network, ce qui les rend isolés de l’extérieur. Tant que la configuration reste inchangée, tout fonctionne correctement sans nécessité de paramétrage supplémentaire. Une machine virtuelle vivant dans un Vnet hérite sa configuration DNS depuis ce dernier.

Il est également possible d’appliquer une configuration DNS au niveau de la carte réseau, pour être plus granulaire.

Cependant, pour une personnalisation, il est possible d’attribuer une configuration DNS au niveau de la carte réseau. Si une zone DNS privée Azure est utilisée, celle-ci est connectée au VNet via un Virtual Network Link avec l’option  » Enable auto-registration ».

PaaS, private endpoint et DNS

Comme mentionné plus haut, tout est public dans Azure. Cela fait donc sens qu’une instance PaaS dispose d’un IP public. Sauf que… Ce n’est pas forcément ce qui est souhaitable.

Pour passer en mode privé, Microsoft propose la technologie Private Link, qui, dans le cadre d’instances PaaS, devient  Private Endpoint

En résumé, cette technologie permet de changer l’interface publique d’une instance PaaS en interface privé, intégrée dans un Virtual Network (VNet).

Lors du passage d’une adresse IP publique à une adresse privée, il est logique que la gestion du DNS soit impactée. La documentation pour les Privates Endpoints montre que ces derniers reposent sur des zones DNS privées configurées avec des sous-domaines des noms de domaines publics Azure.

Par exemple, pour une instance de Key Vault, l’adresse publique : <azure_key_vault_name>.vault.azure.net devient <azure_key_vault_name>.privatelink.vaultcore.azure.net. 

Lorsque l’accès public est désactivé au profit d’un Private Endpoint, il faut être connecté au réseau privé contenant le Private Endpoint pour être en mesure d’accéder à l’instance privatisée.

Dans un environnement entièrement Azure, la configuration reste relativement simple :

• Une zone Azure DNS privée correctement nommée.
• Un Private Endpoint enregistré dans cette zone DNS.
• Un Virtual Network Link reliant la zone DNS au Virtual Network du Private Endpoint (ou à un Virtual Network connecté à celui-ci).

Maintenant, que se passe-t-il dans le cadre d’environnement hybride ?

DNS dans une infrastructure hybride

L’un des principaux défis liés à l’hybridation concerne le réseau. Étant donné que le DNS est utilisé pour résoudre des adresses IP, la configuration DNS en mode hybride devient une composante importante de ce défi.

Pour commencer, examinons la résolution DNS dans Azure à partir d’un système On-premise.

Résoudre des noms DNS dans Azure depuis le réseau On-premise

Dans un environnement On-premise, il est fort probable qu’une solution DNS soit déjà mise en place pour gérer la résolution sur ce réseau. Il est également fréquent que cette solution soit intégrée à Active Directory.

Lorsqu’Azure est intégré à l’infrastructure, il est nécessaire de prévoir une connexion entre les VNet et les réseaux On-premise.

Sans approfondir les aspects réseau, voici la situation à ce stade :

• Un réseau On-premise connecté à un réseau Azure contenant des private endpoints.
• Un système DNS On-premise capable de résoudre les noms privés internes.
• Des services Azure, comme des machines virtuelles dans un VNet, ou des instances PaaS également connectées à un VNet via des private endpoints.
• Des zones Azure DNS privées, qui enregistrent les FQDN des services Azure, qu’il s’agisse de machines virtuelles ou d’instances PaaS privatisées. Ces zones sont associées aux VNet où la résolution doit être possible.

Pour activer la résolution des noms dans Azure, il est essentiel d’indiquer au système DNS On-premise où diriger les requêtes afin de trouver les enregistrements des workloads Azure.

Cela se fait en configurant un DNS conditional forwarding. Plus précisément, une adresse IP spécifique d’Azure, 168.63.129.16 est utilisée. Cette IP, identifiée via la commande nslookup précédemment mentionnée, est renseignée dans la configuration. La documentation Azure précise également les domaines pour lesquels le forwarding doit être configuré.

Pour une machine enregistrer dans une zone Azure DNS privée, il est nécessaire d’ajouter un conditional forwarder vers la zone en question. Dans un DNS Windows, cela ressemble à ceci :

Depuis une machine cliente, voici les éléments :

Voyons à présent comment faire dans le sens inverse.

Résoudre des noms DNS depuis Azure vers On-premise

Avec le conditional forwarding, il devient possible de permettre à une machine On-premise d’obtenir la résolution DNS dans Azure. Mais comment gérer la résolution dans le sens inverse ?

Deux scénarios principaux se présentent :

• Une machine virtuelle Azure doit résoudre un service On-premise.
• Une instance PaaS doit résoudre un service On-premise.

En théorie, la solution est relativement simple. Tant que le service se trouve dans un Virtual Network, sa configuration DNS est récupérée à partir des paramètres DNS du VNet définis précédemment.

Modifier la configuration DNS d’un VNet pour indiquer une adresse de serveur DNS On-premise permet d’accéder aux zones DNS hébergées sur ce serveur, rendant ainsi la résolution possible. Cependant, cette approche peut s’avérer problématique. En effet, configurer un serveur DNS On-premise pour tous les VNet implique que chaque requête DNS transite par le lien de connexion vers le réseau On-premise, ce qui n’est pas recommandé dans une  topologie hybride.

Dans ce cas, une première option est d’ajouter une infrastructure DNS dans Azure, sous la forme d’une paire de serveur DNS IaaS. Les adresses IP de ces serveurs seront ensuite ajoutées aux paramètres DNS des VNet concernés.

Il convient de noter que l’adresse IP des serveurs DNS IaaS Azure est ensuite utilisée dans la configuration du DNS forwarding.

Bien que cette solution réponde aux besoins, elle impose une gestion supplémentaire côté client en raison de sa nature IaaS.

Pour une approche plus managée, Azure Private DNS Resolver peut être utilisé comme alternative.

Exemple de configuration dans une topologie VWAN

Dans cette dernière partie, une topologie Hub & Spoke avec Virtual WAN est prise en compte. L’environnement est composé de :

• Un spoke hébergeant un cluster AKS, plusieurs machines virtuelles et une application App Service intégrée à un VNet.
• Un spoke dédié à l’hébergement du Private DNS Resolver.
• Un troisième spoke simulant le réseau On-premise, contenant un contrôleur de domaine (Domain Controller) / serveur DNS ainsi qu’une machine cliente. Ces deux machines virtuelles utilisent le contrôleur de domaine comme serveur DNS et l’adresse IP Azure 168.63.129.16 pour le conditional forwarding.

Dans cet état, les spokes Azure ne peuvent pas résoudre les noms des services hébergés sur le contrôleur de domaine ou sur la machine cliente du réseau On-premise.

Ajoutons à présent un Private DNS Resolver.

DNS private resolver

Ce service managé offre une solution à divers scénarios de résolution DNS.

Le premier scénario consiste à activer la résolution DNS d’Azure vers un environnement On-premise, sans avoir à gérer une infrastructure IaaS.

En se référant à la documentation associée, il est précisé que le DNS Resolver repose sur un outbound endpoint et/ou un inbound endpoint.

Outbound Endpoint

L’outbound endpoint est conçu pour gérer le trafic sortant d’Azure vers un réseau On-premise. Il requiert un sous-réseau dédié, bien que celui-ci n’utilise pas visiblement d’adresse IP.

Pour gérer le forwarding vers les DNS On-premise, l’outbound endpoint utilise un DNS forwarding ruleset. Grâce à ce mécanisme, il est possible de définir des règles de forwarding pour des domaines DNS spécifiques.

Dans cet exemple, le nom de domaine dcdemo.infra est transféré vers l’adresse du serveur dc1 en tant que cible du forwarding.

Dans cet état, les services on-premise ne sont pas encore disponibles. Un lien doit être établi entre les VNET devant résoudre vers l’On-premise et le DNS resolver. Cependant, il n’est pas nécessaire de modifier la configuration DNS du VNET.

Lors d’un test de résolution à partir de la machine client2 dans le VNET, le résultat attendu permet de résoudre les noms de domaine On-premise.

Et cela nous permet de résoudre les noms de domaines on-premise. Ce pattern est une architecture DNS distribuée.  Il est important de noter que le serveur DNS répondant à la requête est celui d’Azure, avec l’adresse IP 168.63.129.16.

Regardons à présent l’inbound endpoint.

Inbound Endpoint

L’outbound endpoint gère le trafic DNS sortant d’Azure vers l’On-premise, tandis que l’inbound endpoint répond au besoin inverse, en dirigeant les requêtes DNS de l’On-premise vers Azure.

Comme l’outbound endpoint, l’inbound endpoint requiert un sous-réseau dédié, mais il consomme des adresses IP dans ce sous-réseau.

Plutôt que de pointer vers un serveur IaaS, comme dc1, le DNS On-premise fait désormais référence à l’IP de l’inbound endpoint.

Il est possible de vérifier que la résolution DNS fonctionne toujours sur la machine On-premise.

Ce schéma permet d’obtenir une infrastructure DNS hybride totalement fonctionnelle. Pour passer d’une architecture DNS distribuée à une architecture centralisée, il suffit de configurer l’IP de l’inbound endpoint dans les paramètres DNS des VNET. Sur le VNET du resolver, les liens vers l’outbound resolver endpoint et les zones DNS privées Azure nécessaires à la résolution DNS dans Azure doivent être conservés. Dans ce modèle centralisé, un client DNS dans Azure transmet ses requêtes à l’IP de l’inbound endpoint.

Un filtrage réseau peut être ajouté pour le trafic DNS en ouvrant les connexions entre le VNET du DNS resolver et les autres VNET.

Pour conclure

 Cet article a couvert les principes fondamentaux du DNS :

• La gestion DNS est principalement automatisée par Azure, sauf en cas de personnalisation.
• La gestion DNS dans un VNET nécessite l’utilisation de zones DNS privées et de liens entre les VNETs et ces zones.
• La gestion hybride du DNS repose sur l’utilisation du DNS forwarding.
• Azure DNS Private Resolver permet de se passer d’un DNS IaaS, offrant une solution utilisable dans des architectures DNS distribuées ou centralisées.