Partager via

Résolution de noms des ressources dans les réseaux virtuels Azure

  • Article

Vous pouvez utiliser Azure pour héberger infrastructure as a service (IaaS), platform as a service (PaaS) et les solutions hybrides. Pour faciliter la communication entre les machines virtuelles et les autres ressources déployées dans un réseau virtuel, il pourrait être nécessaire de les autoriser à communiquer entre elles. L’utilisation de noms facilement mémorisables et immuables simplifie le processus de communication, plutôt que de s’appuyer sur des adresses IP.

Quand des ressources déployées sur des réseaux virtuels doivent résoudre des noms de domaine en adresses IP internes, elles peuvent utiliser l’une des quatre méthodes suivantes :

Le type de résolution de noms que vous utilisez dépend de la manière dont vos ressources doivent communiquer entre elles. Le tableau suivant montre des scénarios et les solutions de résolution de noms correspondantes.

Les zones DNS privé Azure sont la solution préférée et vous donnent la possibilité de gérer vos zones et enregistrements DNS. Pour plus d’informations, consultez Utilisation d’Azure DNS pour les domaines privés.

Remarque

Si vous utilisez le DNS fourni par Azure, le suffixe DNS approprié est automatiquement appliqué à vos machines virtuelles. Pour toutes les autres options, vous devez utiliser des noms de domaine complets (FQDN) ou appliquer manuellement le suffixe DNS approprié à vos machines virtuelles.

Scénario Solution Suffixe DNS
Résolution de noms entre des machines virtuelles situées dans le même réseau virtuel, ou entre des instances de rôle Azure Cloud Services situées dans le même service cloud. Zones DNS privé Azure ou résolution de noms fournie par Azure Nom d’hôte ou nom de domaine complet
Résolution de noms entre des machines virtuelles situées dans différents réseaux virtuels ou entre des instances de rôle situées dans différents services cloud. Zones DNS privé Azure, Azure DNS Private Resolver ou serveurs DNS gérés par le client qui transfèrent les requêtes entre les réseaux virtuels pour une résolution par Azure (proxy DNS). Consultez Résolution de noms à l’aide de votre propre serveur DNS. Nom de domaine complet uniquement
Résolution de noms à partir d’Azure App Service (application Web, fonction ou Bot) à l’aide de l’intégration au réseau virtuel pour les instances de rôle ou machines virtuelles dans le même réseau virtuel. Azure DNS Private Resolver ou serveurs DNS gérés par le client qui transfèrent les requêtes entre les réseaux virtuels pour une résolution par Azure (proxy DNS). Consultez Résolution de noms à l’aide de votre propre serveur DNS. Nom de domaine complet uniquement
Résolution de noms à partir d’App Service Web Apps vers des machines virtuelles dans le même réseau virtuel. Azure DNS Private Resolver ou serveurs DNS gérés par le client qui transfèrent les requêtes entre les réseaux virtuels pour une résolution par Azure (proxy DNS). Consultez Résolution de noms à l’aide de votre propre serveur DNS. Nom de domaine complet uniquement
Résolution de noms à partir d’App Service Web Apps dans un réseau virtuel vers des machines virtuelles situées dans un réseau virtuel différent. Azure DNS Private Resolver ou serveurs DNS gérés par le client qui transfèrent les requêtes entre les réseaux virtuels pour une résolution par Azure (proxy DNS). Consultez Résolution de noms à l’aide de votre propre serveur DNS. Nom de domaine complet uniquement
Résolution des noms de service et d’ordinateur locaux à partir des machines virtuelles ou des instances de rôle dans Azure. Azure DNS Private Resolver ou serveurs DNS gérés par le client (par exemple, contrôleur de domaine local, contrôleur de domaine en lecture seule local ou serveur DNS secondaire synchronisé via des transferts de zone). Consultez Résolution de noms à l’aide de votre propre serveur DNS. Nom de domaine complet uniquement
Résolution de noms d’hôte Azure à partir d’ordinateurs locaux. Transfert des requêtes à un serveur proxy DNS géré par le client dans le réseau virtuel correspondant. Le serveur proxy transfère les requêtes à Azure pour résolution. Consultez Résolution de noms à l’aide de votre propre serveur DNS. Nom de domaine complet uniquement
DNS inversé pour les adresses IP internes. Zones DNS privé Azure, résolution de noms fournie par Azure, Azure DNS Private Resolver ou résolution de noms à l’aide de votre propre serveur DNS. Non applicable
Résolution de noms entre des machines virtuelles ou instances de rôle situées dans différents services cloud, et non dans un réseau virtuel. Non applicable. La connectivité entre des machines virtuelles et des instances de rôle de différents services cloud n’est pas prise en charge en dehors d’un réseau virtuel. Non applicable

Résolution de noms dans Azure

La résolution de noms fournie par Azure fournit uniquement les fonctionnalités DNS de base faisant autorité. Azure gère les noms et enregistrements de zone DNS si vous utilisez le DNS fourni par Azure. Vous ne pouvez pas contrôler les noms de zone DNS ou le cycle de vie des enregistrements DNS. Si vous avez besoin d’une solution DNS complète pour vos réseaux virtuels, vous pouvez utiliser des zones DNS privé Azure avec des serveurs DNS gérés par le client ou une instance d’Azure DNS Private Resolver.

Avec la résolution des noms DNS publics, Azure fournit la résolution de noms interne pour les machines virtuelles et les instances de rôle qui résident dans le même réseau virtuel ou service cloud. Les machines virtuelles et les instances d’un service cloud partagent le même suffixe DNS, de sorte que le nom d’hôte seul est suffisant. Toutefois, dans les réseaux virtuels déployés à l’aide du modèle de déploiement classique, différents services cloud ont des suffixes DNS différents. Dans ce cas, vous avez besoin du nom de domaine complet pour résoudre les noms des différents services cloud.

Dans les réseaux virtuels déployés à l’aide du modèle de déploiement Azure Resource Manager, le suffixe DNS est cohérent sur toutes les machines virtuelles au sein d’un réseau virtuel, de sorte que le nom de domaine complet n’est pas nécessaire. Vous pouvez affecter des noms DNS aux machines virtuelles et aux interfaces réseau. Bien que la résolution de noms fournie par Azure ne nécessite aucune configuration, il n’est pas le choix approprié pour tous les scénarios de déploiement, comme décrit dans le tableau précédent.

Remarque

Lorsque vous utilisez des rôles Web et de worker Azure Cloud Services, vous pouvez également accéder aux adresses IP internes des instances de rôle à l’aide de l’API REST Management des services Azure. Pour plus d’informations, consultez Référence de l’API REST de management des services. L’adresse est basée sur le nom de rôle et le numéro d’instance.

Fonctionnalités

La résolution de noms fournie par Azure présente les avantages suivants :

  • Vous n’avez pas besoin de configurer quoi que ce soit d’autre.
  • Vous n’avez pas besoin de créer et de gérer des clusters de vos propres serveurs DNS en raison de la haute disponibilité.
  • Vous pouvez utiliser le service avec vos propres serveurs DNS pour résoudre les noms d’hôte locaux et Azure.
  • Vous pouvez utiliser la résolution de noms entre les machines virtuelles et les instances de rôle du même service cloud, sans qu’un nom de domaine complet soit nécessaire.
  • Vous pouvez utiliser la résolution de noms entre les machines virtuelles des réseaux virtuels qui utilisent le modèle de déploiement Resource Manager, sans qu’un nom de domaine complet ne soit nécessaire. Les réseaux virtuels dans le modèle de déploiement classique nécessitent un nom de domaine complet lorsque vous résolvez des noms dans différents services cloud.
  • Vous pouvez utiliser des noms d’hôte qui décrivent le mieux vos déploiements, plutôt que d’utiliser des noms générés automatiquement.

À propos de l’installation

Lorsque vous utilisez la résolution de noms fournie par Azure, tenez compte des points suivants :

  • Le suffixe DNS créé par Azure ne peut pas être modifié.
  • La recherche DNS est étendue à un réseau virtuel. Les noms DNS créés pour un réseau virtuel ne peuvent pas être résolus à partir d’autres réseaux virtuels.
  • L’inscription manuelle de vos propres enregistrements n’est pas autorisée.
  • WINS et NetBIOS ne sont pas pris en charge. Vous ne pouvez pas voir vos machines virtuelles dans l’Explorateur Windows.
  • Les noms d’hôte doivent être compatibles avec DNS. Les noms ne doivent utiliser que 0 à 9, de A à Z et un trait d’union (-). Les noms ne peuvent pas commencer ou se terminer par un trait d’union.
  • Le trafic de requêtes DNS est limité pour chaque machine virtuelle. La limitation ne doit pas affecter la plupart des applications. Si vous observez la limitation des demandes, vérifiez que la mise en cache côté client est bien activée. Pour plus d’informations, consultez Configuration du client DNS.
  • Un nom différent doit être utilisé pour chaque machine virtuelle d’un réseau virtuel afin d’éviter les problèmes de résolution DNS.
  • Seules les machines virtuelles des 180 premiers services cloud sont inscrites pour chaque réseau virtuel dans un modèle de déploiement classique. Cette limite ne s’applique pas aux réseaux virtuels dans Azure Resource Manager.
  • Adresse IP d’Azure DNS : 168.63.129.16. Il s’agit d’une adresse IP statique qui ne change pas.

Considérations relatives au DNS inversé

Le DNS inversé pour les machines virtuelles est pris en charge dans tous les réseaux virtuels basés sur Azure Resource Manager. Le DNS inversé géré par Azure, également appelé pointeur (PTR), les enregistrements de formulaire \[vmname\].internal.cloudapp.net sont automatiquement ajoutés au DNS lorsque vous démarrez une machine virtuelle. Ils sont supprimés lorsque la machine virtuelle est arrêtée (désallouée). Voir l’exemple suivant :

C:\>nslookup -type=ptr 10.11.0.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.0.11.10.in-addr.arpa  name = myeastspokevm1.internal.cloudapp.net

La zone DNS inversée internal.cloudapp.net est gérée par Azure et ne peut pas être directement consultée ou modifiée. La recherche vers l’avant sur le nom de domaine complet du formulaire \[vmname\].internal.cloudapp.net est résolue sur l’adresse IP affectée à la machine virtuelle.

Si une zone DNS privé Azure est liée au réseau virtuel à l’aide d’un lien de réseau virtuel et que l’inscription automatique est activée sur ce lien, les requêtes DNS inversé renvoient alors deux enregistrements. Un enregistrement est de la forme \[vmname\].[privatednszonename] et l’autre est de la forme \[vmname\].internal.cloudapp.net. Voir l’exemple suivant :

C:\>nslookup -type=ptr 10.20.2.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.2.20.10.in-addr.arpa  name = mywestvm1.internal.cloudapp.net
4.2.20.10.in-addr.arpa  name = mywestvm1.azure.contoso.com

Lorsque deux enregistrements PTR sont renvoyés comme illustré ci-dessus, la recherche directe de l’un ou l’autre des noms de domaine complets renvoie l’adresse IP de la machine virtuelle.

Les recherches DNS inversées sont étendues à un réseau virtuel spécifique, même si elles sont appairées à d’autres réseaux virtuels. Les requêtes DNS inversées pour les adresses IP des machines virtuelles situées dans les réseaux virtuels appairés retournent NXDOMAIN.

Les enregistrements DNS inversés (PTR) ne sont pas stockés dans une zone DNS privé de transfert. Les enregistrements DNS inversés sont stockés dans une zone DNS inversée (in-addr.arpa). La zone DNS inversée par défaut associée à un réseau virtuel n’est pas visible ni modifiable.

Vous pouvez désactiver la fonction DNS inversée dans un réseau virtuel. Créez votre propre zone de recherche inversée à l’aide de zones DNS privé Azure. Ensuite, liez cette zone à votre réseau virtuel. Par exemple, si l’espace d’adressage IP de votre réseau virtuel est 10.20.0.0/16, vous pouvez créer une zone DNS privé vide 20.10.in-addr.arpa et la lier au réseau virtuel. Cette zone remplace les zones de recherche inversée par défaut pour le réseau virtuel. Cette zone est vide. Le DNS inversé retourne NXDOMAIN, sauf si vous créez ces entrées manuellement.

L’inscription automatique des enregistrements PTR n’est pas prise en charge. Si vous souhaitez créer des entrées, saisissez-les manuellement. Vous devez désactiver l’inscription automatique dans le réseau virtuel si elle est activée pour d’autres zones. Cette limitation s’explique par les restrictions qui permettent de lier une seule zone privée si l’inscription automatique est activée. Pour plus d’informations sur la création d’une zone DNS privé et son lien vers un réseau virtuel, consultez le guide de démarrage rapide Azure Private DNS.

Remarque

Étant donné que les zones privées Azure DNS sont globales, vous pouvez créer une recherche DNS inversée pour couvrir plusieurs réseaux virtuels. Vous devez créer une zone DNS privé Azure pour les recherches inversées (une zone in-addr.arpa), puis la lier aux réseaux virtuels. Vous devez gérer manuellement les enregistrements DNS inversés pour les machines virtuelles.

Configuration du client DNS

Cette section aborde la mise en cache côté client et les nouvelles tentatives côté client.

Mise en cache côté client

Les requêtes DNS n’ont pas toutes besoin d’être envoyées sur le réseau. La mise en cache côté client permet de réduire la latence et d’améliorer la résilience aux spots réseau en résolvant les requêtes DNS récurrentes à partir d’un cache local. Les enregistrements DNS contiennent un mécanisme de durée de vie, qui permet au cache de stocker l’enregistrement tant que possible sans affecter l’actualisation des enregistrements. La mise en cache côté client convient à la plupart des situations.

Le client DNS Windows par défaut comprend un cache DNS intégré. Certaines distributions Linux n’incluent pas la mise en cache par défaut. Si vous ne disposez pas déjà d’un cache local, ajoutez un cache DNS à chaque machine virtuelle Linux.

De nombreux packages de mise en cache DNS différents sont disponibles (par exemple, dnsmasq). Voici comment installer dnsmasq sur les distributions les plus courantes :

RHEL (utilise NetworkManager)

  1. Installez le package dnsmasq avec la commande suivante :

    sudo yum install dnsmasq

  2. Activez le service dnsmasq avec la commande suivante :

    systemctl enable dnsmasq.service

  3. Démarrez le service dnsmasq en utilisant la commande suivante :

    systemctl start dnsmasq.service

  4. Utilisez un éditeur de texte pour ajouter prepend domain-name-servers 127.0.0.1; à /etc/dhclient-eth0.conf :

  5. Utilisez la commande suivante pour redémarrer le service réseau :

    service network restart

Remarque

Le package dnsmasq constitue l’un des nombreux caches DNS disponibles pour Linux. Avant de l’utiliser, vérifiez son adéquation à vos besoins ; vérifiez aussi qu’aucun autre cache n’est installé.

Nouvelles tentatives côté client

DNS est principalement un protocole UDP (User Datagram Protocol). Comme le protocole UDP ne garantit pas la remise des messages, la logique de nouvelle tentative est gérée dans le protocole DNS. Chaque client DNS (système d’exploitation) peut appliquer une logique de nouvelle tentative différente selon la préférence de son créateur :

  • Les systèmes d’exploitation Windows effectuent une nouvelle tentative après une seconde, puis à nouveau après deux secondes, quatre secondes et encore quatre secondes.
  • La configuration Linux par défaut effectue une nouvelle tentative après cinq secondes. Nous vous recommandons de définir les spécifications de nouvelle tentative sur cinq fois, à intervalles d’une seconde.

Vérifiez les paramètres actuels sur une machine virtuelle Linux avec cat /etc/resolv.conf. Examinez la ligne options, par exemple :

options timeout:1 attempts:5

Le fichier resolv.conf est généré automatiquement et ne doit pas être modifié. Les étapes spécifiques pour l’ajout de la ligne options varient selon la distribution.

RHEL (utilise NetworkManager)

  1. Utilisez un éditeur de texte pour ajouter la ligne RES_OPTIONS="options timeout:1 attempts:5" au fichier /etc/sysconfig/network-scripts/ifcfg-eth0.

  2. Utilisez la commande suivante pour redémarrer le service NetworkManager :

    systemctl restart NetworkManager.service

Résolution de noms utilisant votre propre serveur DNS

Cette section traite des machines virtuelles, des instances de rôle et des applications web.

Notes

Azure DNS Private Resolver remplace la nécessité d’utiliser des serveurs DNS basés sur des machines virtuelles dans un réseau virtuel. La section suivante est fournie si vous souhaitez utiliser une solution DNS basée sur une machine virtuelle. Les nombreux avantages de l’utilisation d’Azure DNS Private Resolver incluent la réduction des coûts, la haute disponibilité intégrée, la scalabilité et la flexibilité.

Machines virtuelles et instances de rôle

Il peut arriver que vous ayez besoin d’autres fonctionnalités que celles fournies par Azure pour la résolution de noms. Par exemple, vous devrez peut-être utiliser des domaines Windows Server Active Directory pour résoudre les noms DNS entre les réseaux virtuels. Pour couvrir ces scénarios, vous pouvez utiliser vos propres serveurs DNS.

Les serveurs DNS d’un réseau virtuel peuvent transférer des requêtes DNS vers le programme de résolution récursive dans Azure. À l’aide de cette procédure, vous pouvez résoudre les noms d’hôte au sein de ce réseau virtuel. Par exemple, un contrôleur de domaine en cours d’exécution dans Azure peut répondre aux requêtes DNS concernant ses domaines et transférer toutes les autres requêtes vers Azure. Le transfert des requêtes permet aux machines virtuelles de voir vos ressources locales (par le biais du contrôleur de domaine) et les noms d’hôtes fournis par Azure (par le biais du redirecteur). Les programmes de résolution récursive d’Azure sont accessibles via l’adresse IP virtuelle 168.63.129.16.

Important

Si la passerelle VPN Azure est utilisée dans cette configuration, ainsi que les adresses IP de serveur DNS personnalisées sur un réseau virtuel, l’adresse IP Azure DNS (168.63.129.16) doit être ajoutée dans la liste pour conserver un service non dissocié.

Le transfert de DNS active également la résolution DNS entre les réseaux virtuels et permet à vos machines locales de résoudre les noms d’hôte fournis par Azure. Pour résoudre le nom d’hôte d’une machine virtuelle, la machine virtuelle du serveur DNS doit résider dans le même réseau virtuel et être configurée pour rediriger les requêtes de nom d’hôte vers Azure. Comme le suffixe DNS est différent dans chaque réseau virtuel, vous pouvez utiliser des règles de redirection conditionnelles pour envoyer les requêtes DNS au réseau virtuel approprié en vue de la résolution.

Deux réseaux virtuels et un réseau local utilisent cette méthode pour effectuer la résolution DNS entre les réseaux virtuels, comme illustré dans le diagramme suivant. Un exemple de redirecteur DNS est disponible dans la Galerie de modèles de démarrage rapide Azure et sur GitHub.

Notes

Une instance de rôle peut résoudre les noms des machines virtuelles appartenant au même réseau virtuel. Il utilise le nom de domaine complet, qui se compose du nom d’hôte de la machine virtuelle et du suffixe DNS internal.cloudapp.net. Dans ce cas, la résolution de noms réussit uniquement si l’instance de rôle a le nom de machine virtuelle défini dans le fichier de schéma de rôle (fichier .cscfg) : <Role name="<role-name>" vmName="<vm-name>">.

Les instances de rôle qui doivent effectuer la résolution de noms de machines virtuelles dans un autre réseau virtuel (FQDN à l’aide du suffixe internal.cloudapp.net) doivent utiliser la méthode décrite dans cette section (transfert de serveurs DNS personnalisés entre les deux réseaux virtuels).

Diagramme montrant le DNS entre les réseaux virtuels.

Lorsque vous utilisez la résolution de noms fournie par Azure, le protocole DHCP (Dynamic Host Configuration Protocol) azure fournit un suffixe DNS interne (.internal.cloudapp.net) à chaque machine virtuelle. Ce suffixe active la résolution de noms d’hôte, car les enregistrements de nom d’hôte se trouvent dans la zone internal.cloudapp.net. Lorsque vous utilisez votre propre solution de résolution de noms, ce suffixe n’est pas fourni aux machines virtuelles, car il interfère avec d’autres architectures DNS (comme dans les scénarios avec jointure de domaine). Au lieu de cela, Azure fournit un espace réservé non fonctionnel (reddog.microsoft.com).

Si nécessaire, vous pouvez déterminer le suffixe DNS interne à l’aide de PowerShell ou de l’API :

Pour les réseaux virtuels des modèles de déploiement Resource Manager, le suffixe est disponible via l’API REST d’interface réseau, la cmdlet PowerShell Get-AzNetworkInterface et la commande az network nic show Azure CLI.

Si le transfert de requêtes vers Azure ne répond pas à vos besoins, fournissez votre propre solution DNS ou déployez une instance d’Azure DNS Private Resolver.

Si vous fournissez votre propre solution DNS, celle-ci doit :

  • Fournissez la résolution de nom d’hôte appropriée, via dns dynamique (DDNS), par exemple. Si vous utilisez DDNS, il peut être nécessaire de désactiver le nettoyage des enregistrements DNS. Les baux DHCP Azure sont longs et le nettoyage peut supprimer prématurément les enregistrements DNS.
  • Fournir la résolution récursive appropriée pour permettre la résolution de noms de domaines externes.
  • Être accessible (TCP et UDP sur le port 53) à partir des clients dont elle traite les demandes et être en mesure d’accéder à Internet.
  • Soyez protégé contre l’accès à partir d’Internet pour atténuer les menaces posées par des agents externes.

Pour des performances optimales, lorsque vous utilisez des machines virtuelles Azure en tant que serveurs DNS, IPv6 doit être désactivé.

Les groupes de sécurité réseau (NSG) agissent en tant que pare-feu pour vos points de terminaison de programme de résolution DNS. Modifiez ou remplacez vos règles de sécurité de groupe de sécurité réseau pour autoriser l’accès au port UDP 53 (et éventuellement au port TCP 53) aux points de terminaison de l’écouteur DNS. Une fois que les serveurs DNS personnalisés sont définis sur un réseau, le trafic via le port 53 contourne les groupes de sécurité réseau du sous-réseau.

Important

Si vous utilisez des serveurs DNS Windows comme serveurs DNS personnalisés qui transfèrent des requêtes DNS vers des serveurs DNS Azure, veillez à augmenter la valeur du délai d’attente de transfert de plus de quatre secondes pour permettre aux serveurs DNS récursifs Azure d’effectuer des opérations de récursivité appropriées.

Pour plus d’informations sur ce problème, consultez redirecteurs et délais de résolution des redirecteurs conditionnels.

Cette recommandation pourrait également s’appliquer à d’autres plateformes de serveur DNS avec une valeur de délai d’attente de transfert de trois secondes ou moins.

L’échec de cette opération pourrait entraîner la résolution des enregistrements de zone DNS privés avec des adresses IP publiques.

les applications web

Supposons que vous ayez besoin d’effectuer la résolution des noms entre votre application web créée à l’aide d’App Service, et liée à un réseau virtuel, et les machines virtuelles du même réseau virtuel. Après avoir configuré un serveur DNS personnalisé comprenant un redirecteur DNS qui transfère les requêtes vers Azure (adresse IP virtuelle : 168.63.129.16), procédez aux étapes suivantes :

  • Si ce n’est déjà fait, activez l’intégration de réseau virtuel pour votre application Web, comme décrit dans Intégrer votre application à un réseau virtuel.
  • Si vous devez effectuer une résolution de noms à partir de votre application Web liée à un réseau virtuel (créée à l’aide d’App Service) vers des machines virtuelles situées dans un autre réseau virtuel qui n’est pas lié à la même zone privée, utilisez des serveurs DNS personnalisés ou des instances d’Azure DNS Private Resolver sur les deux réseaux virtuels.

Pour utiliser des serveurs DNS personnalisés :

  • Configurez un serveur DNS dans votre réseau virtuel cible, sur une machine virtuelle qui peut également transférer les requêtes vers le programme de résolution récursive d’Azure (adresse IP virtuelle : 168.63.129.16). Un exemple de redirecteur DNS est disponible dans la Galerie de modèles de démarrage rapide Azure et sur GitHub.
  • Configurez un redirecteur DNS dans le réseau virtuel source sur une machine virtuelle. Configurez ce redirecteur DNS pour transférer les requêtes au serveur DNS dans votre réseau virtuel cible.
  • Configurez votre serveur DNS source dans les paramètres de votre réseau virtuel source.
  • Activez l’intégration de réseau virtuel pour votre application Web afin de créer un lien vers le réseau virtuel source, en suivant les instructions de l’article Intégrer une application à un réseau virtuel Azure.

Pour utiliser Azure DNS Private Resolver, consultez Liens de l’ensemble de règles.

Spécifier les serveurs DNS

Lorsque vous utilisez vos propres serveurs DNS, vous pouvez spécifier plusieurs serveurs DNS pour chaque réseau virtuel. Vous pouvez également spécifier plusieurs serveurs DNS par interface réseau (pour Resource Manager) ou par service cloud (pour le modèle de déploiement classique). Les serveurs DNS spécifiés pour une interface réseau ou un service cloud ont la priorité sur les serveurs DNS spécifiés pour le réseau virtuel.

Remarque

Les propriétés d’une connexion réseau, telles que les adresses IP des serveurs DNS, ne doivent pas être modifiées directement dans les machines virtuelles. Ces propriétés risquent d’être effacées pendant la réparation du service lors du remplacement de la carte réseau virtuelle. Cette mise en garde s’applique aux machines virtuelles Windows et Linux.

Lorsque vous utilisez le modèle de déploiement Resource Manager, vous pouvez spécifier des serveurs DNS pour un réseau virtuel et une interface réseau. Pour plus d’informations, consultez Gérer un réseau virtuel et Gérer une interface réseau.

Si vous optez pour un serveur DNS personnalisé pour votre réseau virtuel, vous devez spécifier au moins une adresse IP du serveur DNS. Sinon, le réseau virtuel ignore la configuration et utilise plutôt le DNS fourni par Azure.

Remarque

Si vous modifiez les paramètres DNS d’un réseau virtuel ou d’une machine virtuelle déjà déployée, pour que les nouveaux paramètres DNS prennent effet, vous devez effectuer un renouvellement de bail DHCP sur toutes les machines virtuelles affectées dans le réseau virtuel. Pour les machines virtuelles qui exécutent le système d’exploitation Windows, saisissez ipconfig /renew directement dans la machine virtuelle. Les étapes varient selon le système d’exploitation. Consultez la documentation relative à votre type de système d’exploitation.

Contenu connexe

Modèle de déploiement Azure Resource Manager :