Informazioni sui DNS in Azure NetApp Files
Il servizio DNS (Domain Name Systems) è un componente fondamentale dell'accesso ai dati in Azure NetApp Files quando si usano protocolli di file che si basano su Kerberos per l'autenticazione (inclusi SMB e NFSv4.1). Un nome host semplifica l'accesso a un volume e protegge dagli scenari in cui un indirizzo IP cambia; invece di informare gli utenti di un nuovo indirizzo IP, possono continuare a usare il nome host.
Per impostazione predefinita, l'autenticazione Kerberos sfrutta la risoluzione degli indirizzi IP per formulare il nome dell'entità servizio (SPN) usato per recuperare il ticket Kerberos. Ad esempio, quando si accede a una condivisione SMB con un percorso UNC, ad esempio \SMB.CONTOSO.COM, viene eseguita una richiesta DNS per SMB.CONTOSO.COM e viene recuperato l'indirizzo IP del volume di Azure NetApp Files. Se non è presente alcuna voce DNS (o la voce presente è diversa da quella richiesta, ad esempio con alias/CNAMEs), non è possibile recuperare un nome SPN appropriato e la richiesta Kerberos non riesce. Di conseguenza, l'accesso al volume potrebbe non essere consentito se il metodo di autenticazione di fallback (come New Technology LAN Manager) è disabilitato.
NFSv4.1 Kerberos funziona in modo analogo per il recupero di SPN, in cui le ricerche DNS sono integrate nel processo di autenticazione e possono essere usate anche per l'individuazione dell'area di autenticazione Kerberos.
Azure NetApp Files supporta l'uso di server DNS integrati o DNS autonomi di Active Directory e richiede un accesso affidabile ai servizi DNS (Domain Name System) e ai record DNS aggiornati. Una connettività di rete di scarsa qualità tra Azure NetApp Files e i server DNS può causare interruzioni dell'accesso client o timeout del client. Record DNS incompleti o non corretti per Active Directory Domain Services o Azure NetApp Files possono causare interruzioni dell'accesso client o timeout del client.
Indirizzi IP per l'accesso con Kerberos
Se un indirizzo IP viene usato in una richiesta di accesso a un volume di Azure NetApp Files, una richiesta Kerberos funzionerà in modo diverso a seconda del protocollo in uso.
SMB
Quando si usa SMB, una richiesta per un UNC che usa \x.x.x.x.x per impostazione predefinita tenta di usare NTLM per l'autenticazione. Negli ambienti in cui NTLM non è consentito per motivi di sicurezza, una richiesta SMB che usa un indirizzo IP non è in grado di usare Kerberos o NTLM per l'autenticazione per impostazione predefinita. Di conseguenza, l'accesso al volume di Azure NetApp Files viene negato. Nelle versioni successive di Windows (a partire da Windows 10 versione 1507 e Windows Server 2016), i client Kerberos possono essere configurati per supportare i nomi host IPv4 e IPv6 negli SPN per le comunicazioni SMB.
NFSv4.1
Quando si usa NFSv4.1, una richiesta di montaggio a un indirizzo IP usando una delle opzioni sec=[krb5/krb5i/krb5p] usa ricerche DNS inverse tramite un record del puntatore (PTR) per risolvere un indirizzo IP in un nome host, che viene quindi usato per formulare il nome SPN per il recupero del ticket. Se si usa NFSv4.1 con Kerberos, è necessario disporre di A/AAAA e PTR per il volume di Azure NetApp Files per coprire sia il nome host che l'accesso agli indirizzi IP ai montaggi.
Voci DNS in Azure NetApp Files
I volumi di Azure NetApp Files supportano gli aggiornamenti DNS dinamici se il server DNS supporta DNS dinamico. Con DNS dinamico, i volumi creati con nomi host notificano automaticamente al server DNS di creare un record A/AAAA. Se esiste una zona di ricerca inversa, DNS crea anche un record PTR. Se la zona di ricerca inversa non esiste, un record PTR non viene creato automaticamente, ma deve essere creato manualmente.
I nomi host (anziché gli indirizzi IP) vengono usati per i percorsi di montaggio del volume in configurazioni specifiche, che richiedono il DNS per le funzionalità appropriate:
- Volumi SMB
- NFSv4.1 Kerberos
- Volumi con doppio protocollo
Un indirizzo IP viene usato quando un volume di Azure NetApp File non richiede DNS, ad esempio NFSv3 o NFSv4.1 senza Kerberos. In questi casi, è possibile creare manualmente una voce DNS se si desidera.
Se una voce DNS creata dal DNS dinamico viene eliminata nel server DNS, viene ricreata entro 24 ore da un nuovo aggiornamento DNS dinamico da Azure NetApp Files.
Quando Azure NetApp Files crea un record DNS A/AAAA tramite DNS dinamico, vengono usate le configurazioni seguenti:
- Viene selezionata una casella di record PTR associata: se esistono zone di ricerca inversa per la subnet, i record A/AAAA creano automaticamente record PTR senza l'intervento dell'amministratore.
- La casella "Elimina questo record quando diventa obsoleto" è selezionata. Quando il record DNS diventa "obsoleto", il DNS elimina il record, purché sia stato abilitato lo scavenging per DNS.
- Il TTL del record DNS è impostato su un giorno (24 ore). L'impostazione TTL può essere modificata dall'amministratore DNS in base alle esigenze. Il TTL in un record DNS determina l'intervallo di tempo in cui una voce DNS esiste nella cache DNS di un client.
Nota
Per visualizzare i timestamp di quando è stato creato un record DNS in DNS di Windows Active Directory, passare al menu Visualizza di Gestione DNS, quindi selezionare Avanzate.
Eliminazione/scavenging del record DNS
La maggior parte dei server DNS fornisce metodi per eseguire l'eliminazione/lo scavenging dei record scaduti. L'eliminazione consente di evitare che i record non aggiornati appesantiscano i server DNS e creino scenari in cui esistono record A/AAAA e/o PTR duplicati, che possono creare risultati imprevedibili per i volumi di Azure NetApp Files.
Se più record PTR per lo stesso indirizzo IP puntano a nomi host diversi, le richieste Kerberos potrebbero non riuscire perché il nome SPN non corretto viene recuperato durante le ricerche DNS. DNS non distingue il record PTR a cui appartiene il nome host; le ricerche inverse eseguono invece una ricerca round robin tramite ogni record A/AAAAA per ogni nuova ricerca. Ad esempio:
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
Record di nome canonico (CNAME) e alias DNS
Azure NetApp Files crea un nome host DNS per un volume configurato per un protocollo che richiede DNS per una funzionalità appropriata, ad esempio SMB, protocollo doppio o NFSv4.1 con Kerberos. Il nome creato usa il formato del server SMB (account computer) come prefisso durante la creazione della connessione di Active Directory per l'account NetApp; vengono aggiunti caratteri alfanumerici in modo che più voci di volume nello stesso account NetApp abbiano nomi univoci. Nella maggior parte dei casi, più volumi che richiedono nomi host ed esistono nello stesso account NetApp tentano di usare gli stessi nomi host/indirizzi IP. Ad esempio, se il nome del server SMB è SMB-West.contoso.com, le voci del nome host seguono il formato di SMB-West-XXXX.contoso.com.
In alcuni casi, il nome usato da Azure NetApp Files potrebbe non essere sufficientemente intuitivo da passare agli utenti finali o gli amministratori potrebbero voler mantenere nomi DNS più familiari usati quando i dati sono stati migrati dall'archiviazione locale ad Azure NetApp Files (ad esempio, se il nome DNS originale è stato datalake.contoso.com, gli utenti finali potrebbero voler continuare a usare tale nome).
Azure NetApp Files non consente in modo nativo la specifica dei nomi host DNS usati. Se è necessario un nome DNS alternativo con la stessa funzionalità, è consigliabile usare un nome canonico (CNAME)/alias DNS.
L'uso di un record CNAME (anziché un record A/AAAA aggiuntivo) che punta al record A/AAAA del volume di Azure NetApp Files sfrutta lo stesso SPN del server SMB per abilitare l'accesso Kerberos sia per il record A/AAAA che per CNAME. Si consideri l'esempio di un record A/AAAA di SMB-West-XXXX.contoso.com. Il record CNAME di datalake.contoso.com è configurato per fare riferimento al record A/AAAA di SMB-West-XXXX.contoso.com. Le richieste Kerberos SMB o NFS effettuate a datalake.contoso.com usano il nome SPN Kerberos per SMB-West-XXXX per fornire l'accesso al volume.
Procedure consigliate per DNS in Azure NetApp Files
Accertarsi di soddisfare i requisiti seguenti relativi alle configurazioni DNS:
- Se si usano server DNS autonomi:
- Accertarsi che i server DNS dispongano della connettività di rete alla subnet delegata di Azure NetApp Files che ospita i volumi di Azure NetApp Files.
- Accertarsi che le porte di rete UDP 53 e TCP 53 non siano bloccate da firewall o NSG.
- Accertarsi che i record SRV registrati dal servizio Accesso rete di Active Directory Domain Services siano stati creati nei server DNS.
- Accertarsi che i record PTR per i controller di dominio di Active Directory Domain Services usati da Azure NetApp Files siano stati creati nei server DNS nello stesso dominio della configurazione di Azure NetApp Files.
- Azure NetApp Files supporta aggiornamenti DNS dinamici standard e sicuri. Se sono necessari aggiornamenti DNS dinamici sicuri, accertarsi che gli aggiornamenti sicuri siano configurati nei server DNS.
- Se non vengono usati gli aggiornamenti DNS dinamici, è necessario creare manualmente un record A e un record PTR per gli account computer di Active Directory Domain Services creati nell’unità organizzativa di Active Directory Domain Services, specificata nella connessione AD di Azure NetApp Files, per supportare volumi Kerberos NFSv4.1, dual-protocol, SMB, LDAP su TLS e firma LDAP.
- Per topologie di Active Directory Domain Services complesse o di grandi dimensioni, potrebbero essere necessari criteri DNS o la definizione di priorità di subnet DNS per supportare volumi NFS abilitati per LDAP.
- Se è abilitato lo scavenging DNS (in cui le voci DNS non aggiornate vengono eliminate automaticamente in base al timestamp o all’età) e il DNS dinamico è stato usato per creare i record DNS per il volume di Azure NetApp Files, il processo scavenger potrebbe eliminare inavvertitamente i record per il volume. Questa eliminazione può causare un'interruzione del servizio per le query basate sui nomi. Fino a quando questo problema non viene risolto, creare manualmente voci DNS A/AAAA e PTR per il volume di Azure NetApp Files se è abilitato lo scavenging DNS.