Comprendre les systèmes de noms de domaine dans Azure NetApp Files
Azure NetApp Files prend en charge l’utilisation de serveurs DNS intégrés ou DNS autonomes Active Directory et nécessite un accès fiable aux services DNS (Domain Name System) et aux enregistrements DNS à jour. Une mauvaise connectivité réseau entre Azure NetApp Files et les serveurs DNS peut entraîner des interruptions de l’accès client ou des dépassements de délai d’expiration des clients. Des enregistrements DNS incomplets ou incorrects pour Active Directory Domain Services (AD DS) ou pour Azure NetApp Files peuvent entraîner des interruptions de l’accès client ou des dépassements de délai d’expiration des clients.
Le service DNS est un composant essentiel de l’accès aux données dans Azure NetApp Files. Les protocoles d’accès aux fichiers SMB, NFSV4.1 Kerberos, LDAP et Active Directory Site Discovery font tous une utilisation significative de DNS pour leurs opérations. L’utilisation d’un nom d’hôte placé de façon centralisée dans DNS simplifie l’accès à un volume et protège contre certains scénarios quand une adresse IP change. Au lieu qu’un administrateur doive informer les utilisateurs d’une nouvelle adresse IP, ceux-ci peuvent continuer à utiliser le nom d’hôte convivial.
Les serveurs DNS sont configurés sous des connexions Active Directory. Un serveur principal et secondaire peut être ajouté, ainsi que le nom DNS d’Active Directory.
Remarque
Au titre de meilleure pratique, configurez plusieurs serveurs DNS à des fins de redondance.
À propos des serveurs DNS
Azure NetApp Files nécessite une connexion Active Directory pour les fonctionnalités Kerberos SMB et NFSv4.1. Active Directory nécessite DNS pour fonctionner correctement. Dans la plupart des cas, les déploiements Active Directory sont installés avec des serveurs DNS intégrés aux contrôleurs de domaine. Cette configuration est une meilleure pratique de Microsoft pour faciliter l’utilisation et faire en sorte que tous les enregistrements DNS requis soient créés pour les services de domaine.
Dans certains cas, des serveurs DNS externes (comme BIND) peuvent être utilisés à la place (ou en plus) des services DNS hébergés par Active Directory. Ceci s’appelle un espace de noms disjoint.
Azure NetApp Files prend en charge l’utilisation de serveurs DNS intégrés et externes. Cependant, quand vous utilisez des serveurs DNS externes sans intégration Active Directory, il est important de s’assurer que les enregistrements de service (SRV) nécessaires sont ajoutés au DNS pour le fonctionnement et la redondance corrects des services. Une mauvaise connectivité réseau entre Azure NetApp Files et les serveurs DNS peut entraîner des interruptions de l’accès client ou des dépassements de délai d’expiration des clients. Des enregistrements DNS incomplets ou incorrects pour AD DS ou Azure NetApp Files peuvent entraîner des interruptions de l’accès client ou des dépassements de délai d’expiration des clients.
Consultez Enregistrements DNS dans Azure NetApp Files pour obtenir la liste des enregistrements SRV utilisés par le service. Passez également en revue les instructions pour DNS avec Active Directory et Intégration d’AD DS dans une infrastructure DNS existante.
Intégration d’Azure DNS à Azure NetApp Files
Azure DNS est un service hébergé de gestion et de résolution de noms DNS dans Microsoft Azure. Vous pouvez l’utiliser pour créer des noms DNS publics ou privés pour d’autres applications et services que vous déployez dans Azure, y compris Azure NetApp Files. Le déploiement du DNS dans Azure évite de devoir envoyer des requêtes DNS (sur le port 53) directement entre Azure NetApp Files et le DNS local et/ou un domaine Active Directory. En outre, Azure DNS peut être utilisé pour créer des redirecteurs conditionnels (en utilisant Azure DNS Private Resolver) qui peuvent être utilisés pour envoyer des requêtes DNS depuis Azure NetApp Files vers des serveurs DNS spécifiques via des serveurs DNS privés hébergés dans Azure, qui peuvent être spécifiés pour une utilisation dans la connexion Active Directory.
Pour plus d’informations sur l’utilisation d’Azure DNS :
- Fonctionnement d’Azure DNS avec d’autres services Azure
- Démarrage rapide : Créer une zone et un enregistrement Azure DNS en utilisant le portail Azure
- Démarrage rapide : Créer une zone Azure DNS privée avec le portail Azure
- Démarrage rapide : Créer un résolveur privé Azure DNS en utilisant le portail Azure
Utilisation des adresses IP d’un équilibreur de charge avec DNS dans Azure NetApp Files
Un appareil équilibreur de charge est un moyen d’utiliser une seule adresse IP pour desservir plusieurs adresses IP sur le back-end. Ceci apporte une sécurité via l’obfuscation, ainsi que des avantages en matière de performances et de redondance pour les environnements d’entreprise.
Un équilibreur de charge DNS peut traiter des requêtes et les envoyer à plusieurs serveurs DNS désignés dans un pool. Microsoft Azure fournit des services d’équilibrage de charge natifs pour plusieurs cas d’usage.
Azure NetApp Files prend en charge l’utilisation d’équilibreurs de charge DNS, à condition qu’ils fournissent une adresse IP en tant que point de terminaison et que cette adresse IP puisse communiquer sur le port 53 vers les réseaux Azure NetApp Files. Par exemple, Azure Traffic Manager fournit l’équilibrage de charge DNS au niveau de la couche 7, mais fournit seulement un nom d’hôte front-end à utiliser. Les connexions Active Directory d’Azure NetApp Files autorisent seulement la spécification d’adresses IP pour les serveurs DNS.
Types d’enregistrements DNS dans Azure NetApp Files
Azure NetApp Files utilise différents types d’enregistrements DNS pour accéder aux services de fichiers.
| Type d’enregistrement DNS | Définition |
|---|---|
| A/AAAA | Les enregistrements A DNS sont des enregistrements d’adresse qui indiquent l’adresse IPv4 pour un nom d’hôte. Les enregistrements AAAA indiquent l’adresse IPv6 d’un nom d’hôte. Azure NetApp Files utilise des enregistrements A/AAAA des façons suivantes :
|
| Enregistrements de pointeur (PTR) | Un enregistrement PTR mappe une adresse IP à un nom d’hôte via une zone de recherche inversée. Les enregistrements PTR sont principalement utilisés quand une adresse IP est spécifiée pour un montage/partage dans Azure NetApp Files. L’utilisation d’une adresse IP dans des requêtes de montage/partage peut avoir un impact sur la méthode d’authentification utilisée. Pour plus d’informations, consultez Adresses IP pour l’accès avec Kerberos. |
| Enregistrements de service (SRV) | Les enregistrements SRV sont utilisés pour spécifier les hôtes et les ports utilisés pour un service spécifique, comme LDAP, NFS, CIFS, Kerberos, etc. Les enregistrements SRV dans Azure NetApp Files sont largement utilisés pour la sécurité du service de fichiers (comme Kerberos), la découverte de sites dans Active Directory, les requêtes de serveur LDAP, etc. Il est important de vérifier l’existence de ces enregistrements pour le fonctionnement correct des services Azure NetApp Files. Les enregistrements SRV peuvent être interrogés en utilisant nslookup ou dig. Pour obtenir des exemples, consultez Utilisation de nslookup et dig pour les requêtes DNS. |
| Noms canoniques (CNAME) | Un enregistrement CNAME est un moyen de fournir des alias DNS pour des enregistrements A/AAAA. Les enregistrements CNAME sont facultatifs mais ils peuvent être utiles pour réduire la complexité des enregistrements de nom d’hôte fournis par Azure NetApp Files. Pour plus d’informations, consultez Alias DNS et enregistrements de noms canoniques. |
| URI (Uniform Resource Identifier) | Un enregistrement d’URI est un moyen de mapper des noms d’hôte/adresses IP pour des services à des URI. Les URI sont présentés selon le format : service://fqdn.contoso.com. Azure NetApp Files utilise des requêtes pour les enregistrements d’URI seulement lors de l’exécution de recherches KDC Kerberos pour les requêtes Kerberos NFS. Par défaut, les enregistrements d’URI ne sont pas créés dans les déploiements DNS Active Directory. Par conséquent, les requêtes de recherche d’URI échouent généralement et sont remplacées par des recherches d’enregistrements SRV. |
Enregistrements de service (SRV) utilisés avec Azure NetApp Files
Azure NetApp Files utilise les enregistrements SRV suivants :
-
NFS Kerberos*
- _kerberos-master._tcp.CONTOSO.COM (port 88)*
- _kerberos-master._tcp.CONTOSO.COM (port 88)*
-
Découverte de sites SMB/Active Directory**
- _kerberos.CONTOSO.COM (port 88)
- _kerberos._tcp.CONTOSO.COM (port 88)
- _kerberos._tcp.dc_msdcs.CONTOSO.COM (port 88)
- _kpasswd._tcp.dc._msdcs.CONTOSO.COM (port 464)
- _kpasswd._tcp.CONTOSO.COM (port 464)
- _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.CONTOSO.COM (port 88)
- _kerberos._tcp.{noms d’autres sites}._sites.dc._msdcs.CONTOSO.COM (port 88)
- _kerberos.udp.CONTOSO.COM (port 88)
- _kerberos._udp.dc_msdcs.CONTOSO.COM (port 88)
- _kpasswd._udp.dc._msdcs.CONTOSO.COM (port 464)
- _kpasswd._udp.CONTOSO.COM (port 464)
- _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.CONTOSO.COM (port 88)
- _kerberos._udp.{noms d’autres sites}._sites.dc._msdcs.CONTOSO.COM (port 88)
-
LDAP**
- _ldap.CONTOSO.COM (port 389)
- _ldap._tcp.CONTOSO.COM (port 389)
- _ldap._udp.CONTOSO.COM (port 389)
* Par défaut, le DNS Active Directory ne crée pas ces enregistrements SRV. Il est fortement recommandé de les créer si vous utilisez NFS Kerberos.
** Par défaut, le DNS Active Directory crée ces enregistrements SRV.
Pour plus d’informations sur la façon dont Azure NetApp Files utilise des enregistrements SRV, consultez :
- Comprendre l’utilisation du protocole LDAP dans Azure NetApp Files
- À propos de Kerberos dans Azure NetApp Files
Remarque
Pour une découverte et une redondance appropriées du Centre de distribution de clés dans les enregistrements NFS Kerberos, les enregistrements d’URI et/ou les enregistrements SRV kerberos-master doivent être créés.
DNS dynamique
Les volumes Azure NetApp Files fournissent une adresse IP unique pour un volume, qui est ensuite ajoutée automatiquement au DNS via le DNS dynamique (DDNS) (si le DNS dynamique est pris en charge dans le serveur DNS). Les noms d’hôte sont utilisés (au lieu des adresses IP) pour les chemins de montage de volume dans des configurations spécifiques. L’utilisation de noms d’hôte dans les chemins de montage nécessite un DNS pour un fonctionnement correct :
- Volumes SMB
- NFSv4.1 Kerberos
- Volumes à deux protocoles
NFSv4.1 Kerberos :
SMB
Protocole double
Une adresse IP est utilisée pour le chemin de montage quand un volume Azure NetApp File ne nécessite pas de DNS, par exemple NFSv3 ou NFSv4.1 sans Kerberos.
NFSv3
À propos de l’installation
Dans Azure NetApp Files, les mises à jour du DNS dynamique envoient deux requêtes différentes au serveur DNS configuré : une pour un enregistrement PTR et une pour la création/mise à jour d’un enregistrement A/AAAA.
Les volumes Azure NetApp Files créés avec des noms d’hôte notifient automatiquement le serveur DNS pour qu’il crée un enregistrement A/AAAA. Ceci se produit immédiatement après la création du volume.
Si un enregistrement DNS A/AAAA est déjà présent pour la combinaison adresse IP/nom d’hôte, aucun nouvel enregistrement n’est créé.
Si un enregistrement DNS A/AAAA est présent pour le même nom d’hôte avec une adresse IP différente, un deuxième enregistrement A/AAAA portant le même nom est créé.
Pour les volumes Azure NetApp Files créés sans nom d’hôte (comme des volumes NFSv3), le DNS dynamique ne crée pas les enregistrements DNS, car aucun nom d’hôte n’est affecté dans le service. Les enregistrements doivent être créés manuellement.
Si une zone de recherche inversée pour le sous-réseau IP de l’interface existe, le serveur DNS crée également un enregistrement PTR. Si la zone de recherche inversée nécessaire n’existe pas, un enregistrement PTR ne peut pas être créé automatiquement. Vous devez créer l’enregistrement PTR manuellement.
Si une entrée DNS créée par le DNS dynamique est supprimée sur le serveur DNS, elle est recréée dans les 24 heures suivant une nouvelle mise à jour DNS dynamique à partir d’Azure NetApp Files.
Le DDNS sécurisé est activé quand des volumes SMB ou à protocole double sont créés. Les volumes NFS n’activent pas le DDNS sécurisé, mais ils activent DDNS. Si le DDNS sécurisé est désactivé sur le serveur DNS ou si l’authentification Kerberos échoue, les mises à jour DDNS ne fonctionnent pas.
Type de DNS dynamique Port DNS standard UDP 53 DNS sécurisé TCP 53 Azure NetApp Files prend en charge le DDNS sécurisé seulement avec des serveurs DNS Microsoft Active Directory.
Détails de l’entrée du DNS dynamique
Quand Azure NetApp Files crée un enregistrement DNS A/AAAA via DNS dynamique, les configurations suivantes sont utilisées :
- Une case d’enregistrement PTR associée est cochée : s’il existe des zones de recherche inversée pour le sous-réseau, les enregistrements A/AAAA créent automatiquement des enregistrements PTR sans intervention de l’administrateur.
- La case « Supprimer cet enregistrement quand il devient obsolète » est cochée : quand l’enregistrement DNS devient « obsolète », DNS le supprime, à condition que le nettoyage DNS soit activé.
- La durée de vie de l’enregistrement DNS est définie sur 1 jour (24 heures) : le paramètre de durée de vie peut être modifié par l’administrateur DNS en fonction des besoins. La durée de vie d’un enregistrement DNS détermine la durée de vie d’une entrée DNS dans le cache DNS d’un client.
Remarque
Pour voir les horodatages et la durée de vie lors de la création d’un enregistrement DNS dans DNS Windows Active Directory, accédez au menu Affichage du Gestionnaire DNS, puis sélectionnez Avancé. À partir de là, sélectionnez l’entrée d’enregistrement A/AAAA et visualisez les propriétés.
Fonctionnement du DNS dynamique standard dans Azure NetApp Files
Azure NetApp Files suit quatre étapes de base pour créer des mises à jour du DNS dynamique sur les serveurs DNS configurés. Les mises à jour du DNS dynamique (DDNS) standard passent par le port 53 d’UDP.
- Une requête DNS SOA pour l’adresse IP de l’interface du volume Azure NetApp Files est effectuée.
- Une mise à jour DDNS pour le PTR est effectuée. Si le PTR n’existe pas, il est créé.
- Une requête DNS SOA (Start Of Authority) est effectuée pour le nom de domaine complet (FQDN) du volume Azure NetApp Files.
- Une mise à jour DDNS pour l’enregistrement A/AAAA est effectuée. Si l’enregistrement n’existe pas, il est créé.
DNS dynamique via la capture de paquets
Les captures de paquets peuvent être utiles pour résoudre les problèmes des services qui peuvent ne pas disposer d’une journalisation à analyser. Développez cette vue pour obtenir un aperçu détaillé des captures de paquets.
Une requête DNS SOA pour l’adresse IP de l’interface du volume Azure NetApp Files est effectuée.
143 x.x.x.y x.x.x.x DNS 86 Standard query 0x77c8 SOA y.x.x.x.in-addr.arpa 144 x.x.x.x x.x.x.y DNS 229 Standard query response 0x77c8 No such name SOA y.x.x.x.in-addr.arpa SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111 AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111Une mise à jour DDNS pour le PTR est effectuée. Si le PTR n’existe pas, il est créé.
145 x.x.x.y x.x.x.x DNS 121 Dynamic update 0x1a43 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local 146 x.x.x.x x.x.x.y DNS 121 Dynamic update response 0x1a43 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.localUne requête DNS SOA (Start Of Authority) est effectuée pour le nom de domaine complet (FQDN) du volume Azure NetApp Files.
147 x.x.x.y x.x.x.x DNS 81 Standard query 0xcfab SOA ANF1234.anf.local 148 x.x.x.x x.x.x.y DNS 214 Standard query response 0xcfab No such name SOA ANF1234.anf.local SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111Une mise à jour DDNS pour l’enregistrement A/AAAA est effectuée. Si l’enregistrement n’existe pas, il est créé.
149 x.x.x.y x.x.x.x DNS 97 Dynamic update 0x83b2 SOA anf.local A x.x.x.y 150 x.x.x.x x.x.x.y DNS 97 Dynamic update response 0x83b2 SOA anf.local A x.x.x.y
Fonctionnement de DDNS dans Azure NetApp Files
Quand le DNS sécurisé est activé, Azure NetApp Files négocie avec le serveur DNS pour s’authentifier via GSS en utilisant l’authentification de transaction de clé secrète pour DNS, ce qui garantit que les mises à jour demandées proviennent d’une source légitime. Voici les étapes utilisées pendant ce processus. Les mises à jour du DDNS sécurisé passent par le port TCP 53.
- Une requête DNS SOA pour l’adresse IP de l’interface du volume Azure NetApp Files est effectuée.
- Un ticket de service Kerberos est échangé pour le service DNS sur le serveur DNS.
- Le ticket est ensuite utilisé dans une requête DNS pour une clé de transaction (TKEY) depuis Azure NetApp Files vers le serveur DNS, qui est passée en utilisant GSS-TSIG (signature de transaction) pour s’authentifier.
- Une fois authentifiée, une mise à jour du DNS dynamique sécurisé est envoyée en utilisant la TKEY pour créer le PTR avec GSS-TSIG. Si l’enregistrement n’existe pas déjà, il est créé.
- Une requête DNS SOA est envoyée pour le nom de domaine complet (FQDN) du volume Azure NetApp Files et obtient une réponse.
- Un nouvel ID de TKEY est échangé entre le serveur DNS et Azure NetApp Files.
- Une mise à jour du DNS dynamique sécurisé est envoyée en utilisant la TKEY pour créer l’enregistrement A/AAAA pour le nom de domaine complet. Si l’enregistrement existe déjà avec la même adresse IP, aucune modification n’est apportée.
DNS dynamique via la capture de paquets
Les captures de paquets peuvent être utiles pour résoudre les problèmes des services qui peuvent ne pas disposer d’une journalisation à analyser. Développez cette vue pour obtenir un aperçu détaillé des captures de paquets.
Une requête DNS SOA pour l’adresse IP de l’interface du volume Azure NetApp Files est effectuée.
1135 x.x.x.y x.x.x.x DNS 86 Standard query 0xd29a SOA y.x.x.x.in-addr.arpa 1136 x.x.x.x x.x.x.y DNS 229 Standard query response 0xd29a No such name SOA y.x.x.x.in-addr.arpa SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111Un ticket de service Kerberos est échangé pour le service DNS sur le serveur DNS.
1141 x.x.x.y x.x.x.x KRB5 406 TGS-REQ • SNameString: DNS • SNameString: dc1.anf.local 1143 x.x.x.x x.x.x.y KRB5 1824 TGS-REPLe ticket est ensuite utilisé dans une requête DNS pour une clé de transaction (TKEY) depuis Azure NetApp Files vers le serveur DNS, qui est passée en utilisant GSS-TSIG (signature de transaction) pour s’authentifier.
1152 x.x.x.y x.x.x.x DNS 191 Standard query 0x147c TKEY 1492998148.sig-dc1.anf.local TKEY • Name: 1492998148.sig-dc1.anf.local • Type: TKEY (249) (Transaction Key) • Algorithm name: gss-tsig 1154 x.x.x.x x.x.x.y DNS 481 Standard query response 0x147c TKEY 1492998148.sig-dc1.anf.local TKEY TSIGUne fois authentifiée, une mise à jour du DNS dynamique sécurisé est envoyée en utilisant la TKEY pour créer le PTR avec GSS-TSIG. Si l’enregistrement n’existe pas déjà, il est créé.
1155 x.x.x.y x.x.x.x DNS 240 Dynamic update 0xf408 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local TSIG • Zone o x.x.x.in-addr.arpa: type SOA, class IN o y.x.x.x.in-addr.arpa: type PTR, class IN, ANF1234.anf.local • Type: PTR (12) (domain name PoinTeR) o Additional records o 1492998148.sig-dc1.anf.local: type TSIG, class ANY 1156 x.x.x.x x.x.x.y DNS 240 Dynamic update response 0xf408 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local TSIG • Updates o y.x.x.x.in-addr.arpa: type PTR, class IN, ANF1234.anf.local o Type: PTR (12) (domain name PoinTeR)Une requête DNS SOA est envoyée pour le nom de domaine complet (FQDN) du volume Azure NetApp Files et obtient une réponse.
1162 x.x.x.y x.x.x.x DNS 81 Standard query 0xe872 SOA ANF1234.anf.local 1163 x.x.x.x x.x.x.y DNS 214 Standard query response 0xe872 No such name SOA ANF1234.anf.local SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111 AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111Un nouvel ID de TKEY est échangé entre le serveur DNS et Azure NetApp Files.
1165 x.x.x.y x.x.x.x DNS 191 Standard query 0x020e TKEY 1260534462.sig-dc1.anf.local TKEY 1167 x.x.x.x x.x.x.y DNS 481 Standard query response 0x020e TKEY 1260534462.sig-dc1.anf.local TKEY TSIGUne mise à jour du DNS dynamique sécurisé est envoyée en utilisant la TKEY pour créer l’enregistrement A/AAAA pour le nom de domaine complet. Si l’enregistrement existe déjà avec la même adresse IP, aucune modification n’est apportée.
1168 x.x.x.y x.x.x.x DNS 216 Dynamic update 0x014a SOA anf.local A x.x.x.y TSIG • Zone o anf.local: type SOA, class IN • Updates o ANF1234.anf.local: type A, class IN, addr x.x.x.y o Type: A (1) (Host Address) o Address: x.x.x.y • Additional records o 1260534462.sig-dc1.anf.local: type TSIG, class ANY 1170 x.x.x.x x.x.x.y DNS 216 Dynamic update response 0x014a SOA anf.local A x.x.x.y TSIG • Updates o ANF1234.anf.local: type A, class IN, addr x.x.x.y o Type: A (1) (Host Address)
Mise en cache DNS
Pour réduire la charge sur les serveurs DNS, les clients DNS utilisent des concepts de mise en cache pour stocker les requêtes précédentes en mémoire afin que les requêtes répétées pour un nom d’hôte, une adresse IP ou un service soient conservées localement pendant la période définie par la durée de vie de l’enregistrement DNS.
Azure NetApp Files utilise des caches DNS comme n’importe quel autre client DNS standard. Quand le service demande un enregistrement DNS, cet enregistrement a une durée de vie définie. Par défaut, les entrées DNS Active Directory ont une durée de vie de 600 secondes (10 minutes), sauf indication contraire. Si un enregistrement DNS est mis à jour et se trouve dans le cache Azure NetApp Files, et que sa durée de vie est de 10 minutes, le nouvel enregistrement ne se met pas à jour dans Azure NetApp Files jusqu’à ce que le cache soit vidé au terme du délai d’expiration. Il n’y a actuellement aucun moyen de vider manuellement ce cache. Si une durée de vie inférieure est souhaitée, effectuez la modification depuis le serveur DNS.
Quand vous utilisez des serveurs DNS externes (comme BIND), les valeurs de délai d’expiration par défaut peuvent différer. Si elle n’est pas définie, la durée de vie d’un enregistrement DNS de BIND est de 604 800 secondes (7 jours), trop longue pour une mise en cache DNS efficace. Par conséquent, lors de la création manuelle d’enregistrements DNS, il est important de définir la durée de vie de l’enregistrement sur une valeur raisonnable. L’utilisation de la valeur par défaut de 10 minutes établie par Microsoft est recommandée afin de combiner les performances et la fiabilité pour les recherches DNS.
Vous pouvez interroger manuellement la durée de vie d’un enregistrement DNS en utilisant les commandes nslookup ou dig. Pour obtenir des exemples, consultez Utilisation de nslookup et dig pour les requêtes DNS.
Élagage/nettoyage d’enregistrements DNS
La plupart des serveurs DNS fournissent des méthodes pour élaguer et nettoyer les enregistrements expirés. L’élagage permet d’empêcher les enregistrements obsolètes d’encombrer les serveurs DNS et de créer des scénarios avec des enregistrements A/AAAA et/ou PTR dupliqués, ce qui peut créer des résultats imprévisibles pour les volumes Azure NetApp Files.
Si plusieurs enregistrements PTR pour le même point d’adresse IP pointent vers des noms d’hôte différents, les requêtes Kerberos peuvent échouer, car le SPN incorrect est récupéré pendant les recherches DNS. DNS ne discerne pas l’enregistrement PTR auquel appartient le nom d’hôte. Au lieu de cela, les recherches inversées effectuent une recherche en tourniquet à travers chaque enregistrement A/AAAA pour chaque nouvelle recherche.
Par exemple :
C:\> nslookup x.x.x.x
Server: contoso.com
Address: x.x.x.x
Name: ANF-1234.contoso.com
Address: x.x.x.x
C:\> nslookup x.x.x.x
Server: contoso.com
Address: x.x.x.x
Name: ANF-5678.contoso.com
Address: x.x.x.x
Alias DNS et enregistrements CNAME (Canonical Name)
Azure NetApp Files crée un nom d’hôte DNS pour un volume configuré pour un protocole qui requiert DNS pour des fonctionnalités appropriées, telles que SMB, double protocole ou NFSv4.1 avec Kerberos. Le nom créé utilise le format du serveur SMB (compte d’ordinateur) comme préfixe lors de la création de la connexion Active Directory pour le compte NetApp. Des caractères alphanumériques sont ajoutés afin que plusieurs entrées de volume dans le même compte NetApp aient des noms uniques. Dans la plupart des cas, plusieurs volumes nécessitant des noms d’hôte et qui existent dans le même compte NetApp tentent d’utiliser les mêmes noms d’hôte/adresses IP. Par exemple, si le nom du serveur SMB est SMB-West.contoso.com, les entrées de nom d’hôte suivent le format SMB-West-XXXX.contoso.com.
Dans certains cas, le nom utilisé par Azure NetApp Files peut ne pas être suffisamment convivial pour être utilisés par les utilisateurs finaux, ou les administrateurs peuvent souhaiter conserver des noms DNS plus familiers utilisés quand les données ont été migrées du stockage local vers Azure NetApp Files (par exemple, si le nom DNS d’origine était datalake.contoso.com, les utilisateurs finaux peuvent souhaiter conserver ce nom).
Azure NetApp Files n’autorise pas en mode natif la spécification des noms d’hôte DNS utilisés. Si vous avez besoin d’un autre nom DNS avec la même fonctionnalité, vous devez utiliser un alias DNS/nom canonique (CNAME).
L’utilisation d’un enregistrement CNAME (plutôt qu’un enregistrement A/AAAA supplémentaire) qui pointe vers l’enregistrement A/AAAA du volume Azure NetApp Files tire parti du même SPN que le serveur SMB pour activer l’accès Kerberos à la fois pour l’enregistrement A/AAAA et CNAME. Prenons l’exemple d’un enregistrement A/AAAA de SMB-West-XXXX.contoso.com. L’enregistrement CNAME de datalake.contoso.com est configuré pour pointer vers l’enregistrement A/AAAA de SMB-West-XXXX.contoso.com. Les requêtes Kerberos SMB ou NFS effectuées pour datalake.contoso.com utiliser le SPN Kerberos pour SMB-West-XXXX afin de fournir l’accès au volume.
Utilisation de nslookup et dig pour les requêtes DNS
Les serveurs DNS peuvent être interrogés manuellement en utilisant des outils DNS comme nslookup (clients Windows et Linux) et dig (clients Linux). L’utilisation de ces outils est pratique dans certains scénarios, comme essayer de vérifier le fonctionnement de services, tester la résolution du nom d’hôte ou de l’adresse IP, rechercher des enregistrements DNS existants/obsolètes, vérifier la configuration du serveur ou vérifier la durée de vie. Vous pouvez également utiliser l’utilitaire de résolution des problèmes de connexion Azure pour résoudre d’autres problèmes.
Les commandes nslookup et dig peuvent être exécutées depuis une connexion distante à la machine virtuelle (par exemple depuis Bastion) ou directement depuis la machine virtuelle via l’option d’exécution d’une commande sur la machine virtuelle elle-même.
nslookup avec Windows
Vous pouvez exécuter nslookup pour collecter des informations de base sur les adresses IP de base sans aucune option :
C:\>nslookup anf.local
Server: dns.anf.local
Address: x.x.x.a
Name: anf.local
Addresses: x.x.x.x
x.x.x.y
Pour interroger seulement les informations de durée de vie pour l’enregistrement, utilisez l’option de commande -query=hinfo.
C:\>nslookup -query=hinfo anf.local
Server: dns.anf.local
Address: x.x.x.a
anf.local
primary name server = dns.anf.local
responsible mail addr = root.dns.anf.local
serial = 7
refresh = 604800 (7 days)
retry = 86400 (1 day)
expire = 2419200 (28 days)
default TTL = 604800 (7 days)
L’option -debug peut également être utilisée pour collecter des informations plus détaillées sur l’enregistrement DNS.
C:\>nslookup -debug anf.local
------------
Got answer:
HEADER:
opcode = QUERY, id = 1, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS:
x.x.x.x.in-addr.arpa, type = PTR, class = IN
ANSWERS:
-> x.x.x.x.in-addr.arpa
name = dns.anf.local
ttl = 604800 (7 days)
------------
Server: dns.anf.local
Address: x.x.x.a
------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
anf.local.ANF.LOCAL, type = A, class = IN
AUTHORITY RECORDS:
-> anf.local
ttl = 604800 (7 days)
primary name server = dns.anf.local
responsible mail addr = root.dns.anf.local
serial = 7
refresh = 604800 (7 days)
retry = 86400 (1 day)
expire = 2419200 (28 days)
default TTL = 604800 (7 days)
dig avec Linux
# dig anf.local
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> anf.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12196
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;anf.local. IN A
;; ANSWER SECTION:
anf.local. 604800 IN A x.x.x.x
anf.local. 604800 IN A x.x.x.y
;; Query time: 0 msec
;; SERVER: 10.193.67.250#53(10.193.67.250)
;; WHEN: Thu Aug 29 15:27:47 EDT 2024
;; MSG SIZE rcvd: 70
Meilleures pratiques relatives au DNS dans Azure NetApp Files
Vérifiez que vous répondez aux exigences de configuration de DNS suivantes :
- Spécifiez plusieurs serveurs DNS dans la configuration DNS pour la redondance.
- Pour obtenir de meilleurs résultats, utilisez le DNS intégré et/ou installé avec Active Directory.
- Si vous utilisez des serveurs DNS autonomes :
- Vérifiez que les serveurs DNS disposent d’une connectivité réseau vers le sous-réseau délégué Azure NetApp Files hébergeant les volumes Azure NetApp Files.
- Vérifiez que les ports UDP 53 et TCP 53 du réseau ne sont pas bloqués par des pare-feux ou des groupes de sécurité réseau.
- Vérifiez que les enregistrements SRV inscrits par le service Net Logon d’AD DS ont été créés sur les serveurs DNS, ainsi que les enregistrements de service listés dans Types d’enregistrements DNS dans Azure NetApp Files.
- Vérifiez que les enregistrements PTR des contrôleurs de domaine AD DS utilisés par Azure NetApp Files ont été créés sur les serveurs DNS dans le même domaine que votre configuration Azure NetApp Files.
- Azure NetApp Files prend en charge les mises à jour DNS dynamiques standard et sécurisées. Si vous avez besoin de mises à jour DNS dynamiques sécurisées, vérifiez que les mises à jour sécurisées sont configurées sur les serveurs DNS.
- Vérifiez qu’une zone de recherche inversée a été créée pour le sous-réseau Azure NetApp Files pour permettre au DNS dynamique de créer des enregistrements PTR en plus de l’enregistrement A/AAAA.
- Si un alias DNS est requis, utilisez un enregistrement CNAME. Faites pointer l’enregistrement CNAME vers les enregistrements A/AAAA pour Azure NetApp Files.
- Si vous n’utilisez pas les mises à jour du DNS dynamique, vous devez créer manuellement un enregistrement A et un enregistrement PTR pour les comptes d’ordinateur AD DS créés dans l’unité d’organisation AD DS (spécifiée dans la connexion AD Azure NetApp Files) afin de prendre en charge les volumes avec Signature LDAP d’Azure NetApp Files, LDAP sur TLS, SMB, protocole double ou Kerberos NFSv4.1.
- Pour les topologies AD DS complexes ou étendues, des stratégies DNS ou la hiérarchisation de sous-réseaux DNS peuvent être nécessaires pour prendre en charge les volumes NFS avec LDAP.
- Si la récupération DNS est nettoyée (les entrées DNS périmées sont automatiquement supprimées en fonction de l’horodatage/de l’âge) et que le DNS dynamique a été utilisé pour créer les enregistrements DNS pour le volume Azure NetApp Files, le processus de récupération peut élaguer par inadvertance les enregistrements pour le volume. Cet élagage peut entraîner une panne de service pour les requêtes basées sur le nom. Jusqu’à ce que ce problème soit résolu, créez manuellement les entrées DNS A/AAAA et PTR pour le volume Azure NetApp Files si le nettoyage DNS est activé.