Résolution de noms des ressources dans les réseaux virtuels Azure
Vous pouvez utiliser Azure pour héberger des solutions IaaS, PaaS et hybrides. Pour faciliter la communication entre les machines virtuelles et les autres ressources déployées dans un réseau virtuel, il peut ê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 :
Résolution de noms à l’aide de votre propre serveur DNS (qui peut rediriger les requêtes vers les serveurs DNS fournis par Azure)
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 :
Notes
Azure DNS Private Zones constitue la solution par défaut et vous offre la flexibilité nécessaire pour gérer vos enregistrements et zones DNS. Pour plus d’informations, consultez Utilisation d’Azure DNS pour les domaines privés.
Notes
Si vous utilisez le service DNS fourni par Azure, le suffixe DNS approprié est appliqué automatiquement à 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 privées Azure DNS 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 privées Azure DNS, 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. | Transférer les requêtes vers un serveur proxy DNS géré par le client dans le réseau virtuel correspondant ; le serveur proxy transfère les requêtes vers Azure en vue de la 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 privées Azure DNS, 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 privées Azure DNS 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 ; le nom d’hôte est donc suffisant. Toutefois, dans les réseaux virtuels déployés à l’aide du modèle de déploiement classique, les différents services cloud n’ont pas le même suffixe DNS. 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 le même sur toutes les machines virtuelles d’un réseau virtuel, si bien 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, elle ne convient pas à certains scénarios de déploiement, comme expliqué dans le tableau précédent.
Notes
Quand vous utilisez des rôles de travail et web de services cloud, vous pouvez également accéder aux adresses IP internes des instances de rôle à l’aide de l’API REST de gestion des services Azure. Pour plus d’informations, consultez Référence de l’API REST de gestion 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 :
Simplicité d’utilisation. Aucune configuration n'est requise.
Haute disponibilité : Vous n’avez pas besoin de créer et de gérer les clusters de vos propres serveurs DNS.
Vous pouvez utiliser le service avec vos propres serveurs DNS pour résoudre des 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 Azure Resource Manager, sans qu’un nom de domaine complet ne soit nécessaire. Les réseaux virtuels du modèle de déploiement classique nécessitent un nom de domaine complet lors de la résolution de noms dans des services cloud différents.
Vous pouvez utiliser des noms d’hôte qui décrivent vos déploiements de façon plus appropriée, au lieu d’utiliser des noms générés automatiquement.
Considérations
Éléments à prendre en compte lorsque vous utilisez la résolution de noms fournie par Azure :
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.
Vous ne pouvez pas inscrire manuellement vos propres enregistrements.
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 peuvent comporter que les caractères 0-9, a-z et « - », et ils ne peuvent pas commencer ou se terminer par « - ».
Le trafic de requêtes DNS est limité pour chaque machine virtuelle. La limitation ne doit pas affecter la plupart des applications. Si la limitation de requêtes est respectée, assurez-vous que la mise en cache côté client est activée. Pour plus d’informations, consultez Configuration du client DNS.
Utilisez un nom différent pour chaque machine virtuelle dans 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 d’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é destiné aux machines virtuelles est pris en charge dans tous les réseaux virtuels basés sur Azure Resource Manager. Les enregistrements DNS inversés (PTR) gérés par Azure au format [vmname].internal.cloudapp.net sont automatiquement ajoutés au DNS lorsque vous démarrez une machine virtuelle, et supprimés lorsque la machine virtuelle est arrêtée (libéré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 de DNS inversé internal.cloudapp.net est gérée par Azure, et ne peut pas être directement consultée ou modifiée. La recherche directe sur un nom de domaine complet au format [vmname].internal.cloudapp.net se résout sur l’adresse IP attribuée à la machine virtuelle.
Si une zone privée Azure DNS 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 de DNS inversé renvoient alors deux enregistrements. L’un des enregistrements se présente sous la forme [vmname].[privatednszonename], et l’autre sous 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 alors l’adresse IP de la machine virtuelle.
Les recherches DNS inversées sont limitées à un réseau virtuel donné, même s’il est appairé à d’autres réseaux virtuels. Des requêtes de DNS inversé relatives aux adresses IP des machines virtuelles situées dans des réseaux virtuels appairés renvoient NXDOMAIN.
Notes
Les enregistrements DNS inversés (PTR) ne sont pas stockés dans une zone DNS privée directe. 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 ni visible ni modifiable.
Vous pouvez désactiver la fonction de DNS inversé dans un réseau virtuel en créant votre propre zone de recherche inversée à l’aide de zones privées Azure DNS, puis en liant 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 la zone DNS privée 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, entrez-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 est due aux 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ée et sa liaison à un réseau virtuel, consultez notre guide de démarrage rapide consacré au DNS privé.
Notes
É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. Pour ce faire, créez une zone privée Azure DNS destinée aux recherches inversées (zone in-addr.arpa) et liez-la 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 problèmes réseau en résolvant les requêtes DNS récurrentes à partir d’un cache local. Les enregistrements DNS ont une durée de vie qui permet au cache de les stocker aussi longtemps que possible sans impacter leur fraîcheur. Pour cette raison, 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.
Il existe de nombreux packages de mise en cache DNS différents (par exemple, dnsmasq). Voici les étapes nécessaires à l’installation de dnsmasq sur les distributions les plus courantes :
RHEL (utilise NetworkManager):
Installez le package dnsmasq à l’aide commande suivante :
sudo yum install dnsmasqActivez le service dnsmasq à l’aide de la commande suivante :
systemctl enable dnsmasq.serviceDémarrez le service dnsmasq à l’aide de la commande suivante :
systemctl start dnsmasq.serviceUtilisez un éditeur de texte pour ajouter
prepend domain-name-servers 127.0.0.1;à /etc/dhclient-eth0.conf :Utilisez la commande suivante pour redémarrer le service réseau :
service network restart
Notes
Le package dnsmasq constitue l’un des nombreux caches DNS disponibles pour Linux. Avant de l’utiliser, vérifiez son adéquation à vos besoins et vérifiez qu’aucun autre cache n’est installé.
Nouvelles tentatives côté client
DNS est principalement un protocole UDP. 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. Il est recommandé de configurer cinq nouvelles tentatives effectuées à une seconde d’intervalle.
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):
Utilisez un éditeur de texte pour ajouter la ligne
RES_OPTIONS="options timeout:1 attempts:5"au fichier /etc/sysconfig/network-scripts/ifcfg-eth0.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. Vous pouvez consulter la section suivante si vous souhaitez utiliser une solution DNS basée sur des machines virtuelles, mais il existe de nombreux avantages à l’utilisation d’Azure DNS Private Resolver, notamment 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 Microsoft Windows Server Active Directory pour résoudre les noms DNS entre les réseaux virtuels. Dans le cadre de ces scénarios, Azure vous permet d’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. Cette procédure vous permet de résoudre des noms d’hôte au sein de ce réseau virtuel. Par exemple, un contrôleur de domaine exécuté 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ôte 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 est utilisée dans cette configuration avec des adresses IP personnalisées du serveur DNS sur le réseau virtuel, l’adresse IP AZURE DNS (168.63.129.16) doit également être ajoutée à la liste pour garder un service non interrompu.
Le transfert DNS permet aussi la résolution DNS entre 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. L’image suivante montre deux réseaux virtuels et un réseau local effectuant une résolution DNS entre réseaux virtuels à l’aide de cette méthode. 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. Pour cela, elle utilise le nom de domaine complet, qui est constitué du nom d’hôte de la machine virtuelle et du suffixe DNS internal.cloudapp.net. Toutefois, dans ce cas, la résolution de noms réussit uniquement si l’instance de rôle a le nom de la machine virtuelle défini dans le Schéma Rôle (fichier .cscfg).
<Role name="<role-name>" vmName="<vm-name>">
Les instances de rôle qui doivent effectuer une résolution de noms des machines virtuelles dans un autre réseau virtuel (nom de domaine complet utilisant le suffixe internal.cloudapp.net) doivent le faire à l’aide de la méthode décrite dans cette section, c’est-à-dire, en transférant les serveurs DNS personnalisés entre les deux réseaux virtuels.
Lorsque vous utilisez la résolution de noms fournie par Azure, le protocole DHCP d’Azure fournit un suffixe DNS interne (.internal.cloudapp.net) à chaque machine virtuelle. Ce suffixe permet d’effectuer la résolution des noms d’hôte, car les enregistrements de noms 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 Azure 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 :
Fournir la résolution de noms d’hôte appropriée, via DDNS par exemple. Si vous utilisez DDNS, il peut être nécessaire de désactiver le nettoyage des enregistrements DNS. Les baux DHCP d’Azure sont longs et le nettoyage peut supprimer prématurément des 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.
Être protégée contre tout accès à partir d’Internet, pour atténuer les menaces posées par les agents externes.
Notes
- Pour des performances optimales, lorsque vous utilisez des machines virtuelles Azure en tant que serveurs DNS, le protocole IPv6 doit être désactivé.
- Les groupes de sécurité réseau agissent comme des pare-feux pour vos points de terminaison d’outil de résolution DNS. Vous devez modifier ou remplacer 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 les serveurs DNS personnalisés 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 4 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 peut également s’appliquer à d’autres plateformes de serveur DNS avec une valeur de délai d’attente de transfert de 3 secondes ou moins.
L’échec de cette opération peut 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 :
Activez l’intégration de réseau virtuel pour votre application web, si ce n’est pas déjà fait, comme décrit dans Intégrer une application à un réseau virtuel Azure.
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 une instance d’Azure DNS Private Resolver, consultez Liens de l’ensemble de règles.
Spécifier les serveurs DNS
Lorsque vous utilisez vos propres serveurs DNS, Azure vous permet de spécifier plusieurs serveurs DNS par réseau virtuel. Vous pouvez également spécifier plusieurs serveurs DNS par interface réseau (pour Azure 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.
Notes
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. En effet, ces propriétés risquent d’être effacées pendant la réparation du service, lors du remplacement de la carte réseau virtuelle. Cela s’applique pour les machines virtuelles Windows et Linux.
Lorsque vous utilisez le modèle de déploiement Azure 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.
Notes
Si vous choisissez un serveur DNS personnalisé pour votre réseau virtuel, vous devez spécifier au moins une adresse d’IP de serveur DNS, à défaut de quoi, le réseau virtuel ignorera la configuration et utilisera le DNS fourni par Azure.
Notes
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 exécutant le système d’exploitation Windows, vous pouvez taper ipconfig /renew directement sur la machine virtuelle. Les étapes varient selon le système d’exploitation. Consultez la documentation relative à votre type de système d’exploitation.
Étapes suivantes
Modèle de déploiement Azure Resource Manager :