Comprendre les systèmes de noms de domaine dans Azure NetApp Files
Le service DNS (Domain Name Systems) est un composant essentiel de l’accès aux données dans Azure NetApp Files lors de l’utilisation de protocoles de fichiers qui s’appuient sur Kerberos pour l’authentification (y compris SMB et NFSv4.1). Un nom d’hôte simplifie l’accès à un volume et protège contre les scénarios où une adresse IP change ; au lieu d’informer les utilisateurs d’une nouvelle adresse IP, ils peuvent continuer à utiliser le nom d’hôte.
Par défaut, l’authentification Kerberos s’appuie sur la résolution d’adresse IP pour formuler le nom de principal du service (SPN) utilisé pour récupérer le ticket Kerberos. Par exemple, lors de l’accès à un partage SMB avec un chemin d’accès UNC (Universal Naming Convention) tel que \SMB.CONTOSO.COM, une requête DNS est émise pour SMB.CONTOSO.COM, et l’adresse IP du volume Azure NetApp Files est récupérée. S’il n’y a pas d’entrée DNS présente (ou si l’entrée actuelle est différente de ce qui est demandé, par exemple avec des alias/CNAME), il est impossible de récupérer un SPN approprié et la requête Kerberos échoue. Par conséquent, l’accès au volume peut être interdit si la méthode d’authentification de secours (par exemple, New Technology LAN Manager) est désactivée.
NFSv4.1 Kerberos fonctionne de manière similaire pour la récupération SPN, où les recherches DNS sont une partie intégrante du processus d’authentification et peuvent également être utilisées pour la découverte de domaine Kerberos.
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 les serveurs Azure NetApp Files et DNS peut entraîner des interruptions d’accès client ou des dépassements des délais d’attente du client. Des enregistrements DNS incomplets ou incorrects pour AD DS ou Azure NetApp Files peuvent entraîner des interruptions d’accès client ou des dépassements des délais d’attente du client.
Adresses IP pour l’accès avec Kerberos
Si une adresse IP est utilisée dans une demande d’accès à un volume Azure NetApp Files, une requête Kerberos fonctionne différemment en fonction du protocole utilisé.
PME
Lorsque vous utilisez SMB, une demande d’UNC à l’aide de \x.x.x.x.x.x par défaut tente d’utiliser NTLM pour l’authentification. Dans les environnements où NTLM n’est pas autorisé pour des raisons de sécurité, une requête SMB utilisant une adresse IP n’est pas en mesure d’utiliser Kerberos ni NTLM pour l’authentification par défaut. Par conséquent, l’accès au volume Azure NetApp Files est refusé. Dans les versions ultérieures de Windows (à compter de Windows 10 version 1507 et Windows Server 2016), les clients Kerberos peuvent être configurés pour prendre en charge les noms d’hôte IPv4 et IPv6 dans les noms d’hôte dans les SPN pour la communication SMB.
NFSv4.1
Lorsque vous utilisez NFSv4.1, une demande de montage vers une adresse IP à l’aide de l’une des options sec=[krb5/krb5i/krb5p] utilise des recherches DNS inversées via un enregistrement de pointeur (PTR) pour résoudre une adresse IP en nom d’hôte, qui est ensuite utilisée pour formuler le SPN pour la récupération de ticket. Si vous utilisez NFSv4.1 avec Kerberos, vous devez disposer d’un A/AAAA et d’un PTR pour le volume Azure NetApp Files pour couvrir à la fois l’accès par nom d’hôte et adresse IP aux montages.
Entrées DNS dans Azure NetApp Files
Les volumes Azure NetApp Files prennent en charge les mises à jour DNS dynamiques si le serveur DNS prend en charge le DNS dynamique. Avec le DNS dynamique, les volumes créés avec des noms d’hôte notifient automatiquement le serveur DNS pour créer un enregistrement A/AAAA. Si une zone de recherche inversée existe, DNS crée également un enregistrement PTR. Si la zone de recherche inverse n’existe pas, un enregistrement PTR n’est pas créé automatiquement, ce qui signifie que vous devez le créer manuellement.
Les noms d’hôte (plutôt que les adresses IP) sont utilisés pour les chemins de montage de volume dans des configurations spécifiques, qui nécessitent toutes un DNS pour des fonctionnalités appropriées :
- Volumes SMB
- NFSv4.1 Kerberos
- Volumes à deux protocoles
Une adresse IP est utilisée lorsqu’un volume Azure NetApp File ne nécessite pas de DNS, par exemple NFSv3 ou NFSv4.1 sans Kerberos. Dans ce cas, vous pouvez créer manuellement une entrée DNS si vous le souhaitez.
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.
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 lorsqu’il devient obsolète » est cochée. Lorsque l’enregistrement DNS devient « obsolète », DNS le supprime, à condition que le nettoyage DNS soit activé.
- La « durée de vie (TTL) » de l’enregistrement DNS est définie sur un jour (24 heures). L’administrateur DNS peut modifier le paramètre de durée de vie 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 afficher les horodatages de la création d’un enregistrement DNS dans Windows Active Directory DNS, accédez au menu Affichage du Gestionnaire DNS, puis sélectionnez Avancé.
Élagage/nettoyage d’enregistrements DNS
La plupart des serveurs DNS fournissent des méthodes pour élaguer/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 transmis aux utilisateurs finaux, ou les administrateurs peuvent souhaiter conserver des noms DNS plus familiers utilisés lorsque les données ont migré du stockage local vers Azure NetApp Files (par exemple, si le nom DNS d’origine était datalake.contoso.com, les utilisateurs finaux peuvent continuer à utiliser 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.
Meilleures pratiques relatives au DNS dans Azure NetApp Files
Vérifiez que vous répondez aux exigences suivantes concernant les configurations DNS :
- 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 réseau UDP 53 et TCP 53 ne sont pas bloqués par des pare-feu ou des groupes de sécurité réseau.
- Vérifiez que les enregistrements SRV inscrits par le service d’ouverture de session AD DS Net ont été créés sur les serveurs DNS.
- 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.
- Si vous n’utilisez pas les mises à jour DNS dynamiques, 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) pour prendre en charge la signature LDAP Azure NetApp Files, LDAP sur TLS, SMB, double protocole ou les volumes Kerberos NFSv4.1.
- Pour les topologies AD DS complexes ou volumineuses, les stratégies DNS ou la hiérarchisation de sous-réseaux DNS peuvent être nécessaires pour prendre en charge les volumes NFS compatibles 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é.