Informazioni sui DNS in Azure NetApp Files
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 scarsa connettività di rete tra Azure NetApp Files e i server DNS può causare interruzioni dell'accesso client o timeout del client. I record DNS incompleti o non corretti per Dominio di Active Directory Services (AD DS) o Azure NetApp Files possono causare interruzioni dell'accesso client o timeout del client.
Il servizio DNS è un componente fondamentale dell'accesso ai dati in Azure NetApp Files. L'accesso al protocollo di file tramite SMB, NFSV4.1 Kerberos, LDAP e Individuazione siti Active Directory fa tutti un uso significativo del DNS per le operazioni. L'uso di un nome host che si trova centralmente in DNS semplifica l'accesso a un volume e protegge dagli scenari in cui un indirizzo IP cambia. Anziché un amministratore che deve informare gli utenti di un nuovo indirizzo IP, gli utenti possono continuare a usare il nome host descrittivo.
I server DNS vengono configurati in Connessioni Active Directory. È possibile aggiungere un server primario e secondario, nonché il nome DNS di Active Directory.
Nota
Come procedura consigliata, configurare più server DNS per la ridondanza.
Informazioni sui server DNS
Azure NetApp Files richiede una connessione Active Directory per la funzionalità Kerberos SMB e NFSv4.1. Active Directory richiede DNS per una funzionalità appropriata. Nella maggior parte dei casi, le distribuzioni di Active Directory vengono installate con server DNS integrati con i controller di dominio. Questa configurazione è una procedura consigliata da Microsoft per facilitare l'uso e per garantire che tutti i record DNS necessari vengano creati per i servizi di dominio.
In alcuni casi, i server DNS esterni (ad esempio BIND) possono essere usati al posto dei servizi DNS ospitati in Active Directory (o oltre a). Si tratta di uno spazio dei nomi non contiguo.
Azure NetApp Files supporta l'uso di server DNS integrati ed esterni, ma quando si usano server DNS esterni senza l'integrazione di Active Directory, è importante assicurarsi che i record del servizio (SRV) necessari vengano aggiunti al DNS per una corretta funzionalità e ridondanza dei servizi. Una scarsa connettività di rete tra Azure NetApp Files e i server DNS può causare interruzioni dell'accesso client o timeout del client. I record DNS incompleti o non corretti per Servizi di dominio Active Directory o Azure NetApp Files possono causare interruzioni dell'accesso client o timeout del client.
Per un elenco dei record SRV usati dal servizio, vedere Record DNS in Azure NetApp Files . Vedere anche le linee guida per DNS con Active Directory e Integrazione di Active Directory Domain Services in un'infrastruttura DNS esistente.
Integrazione di DNS di Azure con Azure NetApp Files
DNS di Azure è un servizio di gestione e risoluzione dei nomi DNS ospitato in Microsoft Azure. È possibile usarlo per creare nomi DNS pubblici o privati per altre applicazioni e servizi distribuiti in Azure, tra cui Azure NetApp Files. La distribuzione di DNS in Azure impedisce la necessità di inviare richieste DNS (sulla porta 53) direttamente tra Azure NetApp Files e DNS locale e/o un dominio di Active Directory. È anche possibile usare DNS di Azure per creare server d'inoltro condizionale (usando il sistema di risoluzione di Azure DNS privato) che può essere usato per inviare richieste DNS da Azure NetApp Files a server DNS specifici tramite i server DNS privati ospitati in Azure, che possono essere specificati per l'uso nella connessione Active Directory.
Per informazioni sull'uso di DNS di Azure:
- Funzionamento di DNS di Azure con altri servizi di Azure
- Guida introduttiva: Creare una zona e un record DNS di Azure usando il portale di Azure
- Guida introduttiva: Creare una zona DNS privato di Azure con il portale di Azure
- Avvio rapido: Creare un servizio Resolver privato DNS di Azure usando il portale di Azure
Uso degli indirizzi IP del servizio di bilanciamento del carico con DNS in Azure NetApp Files
Un dispositivo di bilanciamento del carico è un modo per usare un singolo indirizzo IP per gestire più indirizzi IP nel back-end. Ciò garantisce la sicurezza tramite offuscamento, nonché vantaggi di prestazioni e ridondanza per gli ambienti aziendali.
Un servizio di bilanciamento del carico DNS può gestire le richieste e inviarle a più server DNS designati in un pool. Microsoft Azure offre servizi di bilanciamento del carico nativi per più casi d'uso.
Azure NetApp Files supporta l'uso di servizi di bilanciamento del carico DNS, purché forniscano un indirizzo IP come endpoint e che l'indirizzo IP possa comunicare tramite la porta 53 alle reti di Azure NetApp Files. Ad esempio, Gestione traffico di Azure fornisce il bilanciamento del carico DNS al livello 7, ma fornisce solo un nome host front-end da usare. Le connessioni Active Directory di Azure NetApp Files consentono solo di specificare gli indirizzi IP per i server DNS.
Tipi di record DNS in Azure NetApp Files
Azure NetApp Files usa diversi tipi di record DNS per l'accesso ai servizi file.
| Tipo di record DNS | Definizione |
|---|---|
| A/AAAA | I record DNS A sono record di indirizzi che indicano l'indirizzo IPv4 per un nome host. I record AAAA indicano l'indirizzo IPv6 per un nome host. Azure NetApp Files usa record A/AAAA nei modi seguenti:
|
| Record puntatore (PTR) | Un record PTR esegue il mapping di un indirizzo IP a un nome host tramite una zona di ricerca inversa. I record PTR vengono usati principalmente quando viene specificato un indirizzo IP per un montaggio/condivisione in Azure NetApp Files. L'uso di un indirizzo IP nelle richieste di montaggio/condivisione può influire sul metodo di autenticazione usato. Per altre informazioni, vedere Indirizzi IP per l'accesso con Kerberos. |
| Record del servizio (SRV) |
I record SRV vengono usati per specificare quali host e porte vengono usati per un servizio specifico, ad esempio LDAP, NFS, CIFS, Kerberos e così via. I record SRV in Azure NetApp Files vengono usati pesantemente per la sicurezza del servizio file (ad esempio Kerberos), l'individuazione del sito in Active Directory, le query del server LDAP e altro ancora. È importante verificare l'esistenza di questi record per una corretta funzionalità dei servizi Azure NetApp Files. I record SRV possono essere sottoposti a query tramite nslookup comandi o dig . Per esempi, vedere Uso di nslookup e dig per le query DNS. |
| Nomi canonici (CNAME) | Un record CNAME è un modo per fornire alias DNS per i record A/AAAA. I record CNAME sono facoltativi, ma possono essere utili per ridurre la complessità dei record dei nomi host forniti da Azure NetApp Files. Per altre informazioni, vedere Alias DNS e record di nome canonico. |
| Uniform Resource Identifier (URI) | Un record URI è un modo per eseguire il mapping di nomi host/indirizzi IP per i servizi agli URI. Gli URI vengono presentati in un formato simile al seguente: service://fqdn.contoso.com. Azure NetApp Files usa query per i record URI solo quando si eseguono ricerche Kerberos KDC per le richieste Kerberos NFS. I record URI non vengono creati nelle distribuzioni DNS di Active Directory per impostazione predefinita. Di conseguenza, le richieste di ricerca URI hanno in genere esito negativo ed è possibile eseguire il fallback alle ricerche dei record SRV. |
Record del servizio (SRV) usati con Azure NetApp Files
Azure NetApp Files usa i record SRV seguenti:
-
NFS Kerberos*
- _kerberos-master._tcp. CONTOSO.COM (porta 88)*
- _kerberos-master._tcp. CONTOSO.COM (porta 88)*
-
Individuazione sito SMB/Active Directory**
- _kerberos.CONTOSO.COM (porta 88)
- _kerberos._tcp. CONTOSO.COM (porta 88)
- _kerberos._tcp.dc_msdcs. CONTOSO.COM (porta 88)
- _kpasswd._tcp.dc._msdcs. CONTOSO.COM (porta 464)
- _kpasswd._tcp. CONTOSO.COM (porta 464)
- _kerberos._tcp. Default-First-Site-Name._sites.dc._msdcs. CONTOSO.COM (porta 88)
- _kerberos._tcp. {altri nomi di sito}._sites.dc._msdcs. CONTOSO.COM (porta 88)
- _kerberos.udp.CONTOSO.COM (porta 88)
- _kerberos._udp.dc_msdcs. CONTOSO.COM (porta 88)
- _kpasswd._udp.dc._msdcs. CONTOSO.COM (porta 464)
- _kpasswd._udp. CONTOSO.COM (porta 464)
- _kerberos._udp. Default-First-Site-Name._sites.dc._msdcs. CONTOSO.COM (porta 88)
- _kerberos._udp. {altri nomi di sito}._sites.dc._msdcs. CONTOSO.COM (porta 88)
-
LDAP**
- _ldap.CONTOSO.COM (porta 389)
- _ldap._tcp. CONTOSO.COM (porta 389)
- _ldap._udp. CONTOSO.COM (porta 389)
* DNS di Active Directory non crea questi record SRV per impostazione predefinita. È consigliabile crearli se si usa Kerberos NFS.
** DNS di Active Directory crea questi record SRV per impostazione predefinita.
Per altre informazioni su come Azure NetApp Files usa i record SRV, vedere:
Nota
Per l'individuazione e la ridondanza appropriate del Centro distribuzione chiavi in Kerberos NFS, è necessario creare record URI e/o record SRV kerberos-master.
DNS dinamico
I volumi di Azure NetApp Files forniscono un singolo indirizzo IP per un volume, che viene quindi aggiunto automaticamente al DNS tramite DNS dinamico (DDNS) (se il DNS dinamico è supportato nel server DNS). I nomi host (anziché gli indirizzi IP) vengono usati per i percorsi di montaggio del volume in configurazioni specifiche. L'uso dei nomi host nei percorsi di montaggio richiede DNS per una funzionalità appropriata:
- Volumi SMB
- NFSv4.1 Kerberos
- Volumi con doppio protocollo
NFSv4.1 Kerberos:
SMB
Protocollo doppio
Un indirizzo IP viene usato per il percorso di montaggio quando un volume di File Di Azure NetApp non richiede DNS, ad esempio NFSv3 o NFSv4.1 senza Kerberos.
NFSv3
Considerazioni
In Azure NetApp Files gli aggiornamenti DNS dinamici inviano due richieste diverse al server DNS configurato: una per un PTR e una per una creazione/aggiornamento di record A/AAAA.
I volumi di Azure NetApp Files creati con nomi host notificano automaticamente al server DNS di creare un record A/AAAA. Ciò si verifica immediatamente dopo il completamento della creazione del volume.
Se è già presente un record DNS A/AAAA per la combinazione indirizzo IP/nome host, non vengono creati nuovi record.
Se è presente un record DNS A/AAAA per lo stesso nome host con un indirizzo IP diverso , viene creato un secondo record A/AAAA con lo stesso nome.
Per i volumi di Azure NetApp Files creati senza nomi host (ad esempio volumi NFSv3), il DNS dinamico non crea i record DNS perché non è assegnato alcun nome host nel servizio. I record devono essere creati manualmente.
Se esiste una zona di ricerca inversa per la subnet IP dell'interfaccia, il server DNS crea anche un record PTR. Se la zona di ricerca inversa necessaria non esiste, non è possibile creare automaticamente un record PTR. È necessario creare manualmente il record PTR.
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.
DDNS sicuro viene abilitato quando vengono creati volumi SMB o dual protocol. I volumi NFS non abilitano DDNS sicuro, ma abilitano DDNS. Se DDNS sicuro è disabilitato nel server DNS o l'autenticazione Kerberos ha esito negativo, gli aggiornamenti DDNS non funzionano.
Tipo DNS dinamico Porta Standard DNS UDP 53 DNS sicuro TCP 53 Azure NetApp Files supporta il servizio DDNS sicuro solo con i server DNS di Microsoft Active Directory.
Dettagli delle voci DNS dinamiche
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 obsoleta" è selezionata: quando il record DNS diventa "non aggiornato", IL DNS elimina il record, purché sia stato abilitato lo scavenging per DNS.
- La durata (TTL) del record DNS è impostata 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 e il TTL (Time to Live) quando è stato creato un record DNS in DNS di Windows Active Directory, passare al menu Visualizza di Gestione DNS e quindi selezionare Avanzate. Da qui selezionare la voce di record A/AAAA e visualizzare le proprietà.
Funzionamento del DNS dinamico standard in Azure NetApp Files
Azure NetApp Files segue quattro passaggi di base per creare aggiornamenti DNS dinamici ai server DNS configurati. Gli aggiornamenti DDNS (Standard Dynamic DNS) attraversano la porta UDP 53.
- Viene eseguita una query DNS SOA per l'indirizzo IP dell'interfaccia del volume di Azure NetApp Files.
- Viene eseguito un aggiornamento DDNS per il ptr. Se il ptr non esiste, viene creato.
- Viene eseguita una query DNS di inizio dell'autorità (SOA) per il nome di dominio completo (FQDN) del volume di Azure NetApp Files.
- Viene eseguito un aggiornamento DDNS per il record A/AAAA. Se il record non esiste, viene creato.
DNS dinamico tramite acquisizione pacchetti
Le acquisizioni di pacchetti possono essere utili per la risoluzione dei problemi del servizio che potrebbero non avere la registrazione disponibile per l'analisi. Espandere questa visualizzazione per un'analisi dettagliata delle acquisizioni di pacchetti.
Viene eseguita una query DNS SOA per l'indirizzo IP dell'interfaccia del volume di Azure NetApp Files.
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:1111Viene eseguito un aggiornamento DDNS per il ptr. Se il ptr non esiste, viene creato.
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.localViene eseguita una query DNS di inizio dell'autorità (SOA) per il nome di dominio completo (FQDN) del volume di 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:1111Viene eseguito un aggiornamento DDNS per il record A/AAAA. Se il record non esiste, viene creato.
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
Funzionamento di DDNS sicuro in Azure NetApp Files
Quando il DNS sicuro è abilitato, Azure NetApp Files negozia con il server DNS per l'autenticazione tramite GSS usando l'autenticazione con chiave privata per DNS, assicurandosi che gli aggiornamenti richiesti provenano da un'origine legittima. Di seguito vengono illustrati i passaggi usati durante questo processo. Gli aggiornamenti DDNS sicuri attraversano la porta TCP 53.
- Viene eseguita una query DNS SOA per l'indirizzo IP dell'interfaccia del volume di Azure NetApp Files.
- Un ticket di servizio Kerberos viene scambiato per il servizio DNS nel server DNS.
- Il ticket viene quindi usato in una query DNS per una chiave di transazione (TKEY) da Azure NetApp Files al server DNS, che viene passato usando GSS-TSIG (firma della transazione) per l'autenticazione.
- Dopo l'autenticazione, viene inviato un aggiornamento DNS dinamico sicuro tramite TKEY per creare il PTR usando GSS-TSIG. Se il record non esiste già, viene creato.
- Viene inviata una query SOA DNS per il nome di dominio completo (FQDN) del volume di Azure NetApp Files e ha risposto.
- Viene scambiato un nuovo ID TKEY tra il server DNS e Azure NetApp Files.
- Viene inviato un aggiornamento DNS dinamico sicuro tramite TKEY per creare il record A/AAAA per il nome di dominio completo. Se il record esiste già con lo stesso indirizzo IP, non vengono apportate modifiche.
DNS dinamico tramite acquisizione pacchetti
Le acquisizioni di pacchetti possono essere utili per la risoluzione dei problemi del servizio che potrebbero non avere la registrazione disponibile per l'analisi. Espandere questa visualizzazione per un'analisi dettagliata delle acquisizioni di pacchetti.
Viene eseguita una query DNS SOA per l'indirizzo IP dell'interfaccia del volume di Azure NetApp Files.
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 di servizio Kerberos viene scambiato per il servizio DNS nel server 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-REPIl ticket viene quindi usato in una query DNS per una chiave di transazione (TKEY) da Azure NetApp Files al server DNS, che viene passato usando GSS-TSIG (firma della transazione) per l'autenticazione.
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 TSIGDopo l'autenticazione, viene inviato un aggiornamento DNS dinamico sicuro tramite TKEY per creare il PTR usando GSS-TSIG. Se il record non esiste già, viene creato.
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)Viene inviata una query SOA DNS per il nome di dominio completo (FQDN) del volume di Azure NetApp Files e ha risposto.
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:1111Viene scambiato un nuovo ID TKEY tra il server DNS e 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 TSIGViene inviato un aggiornamento DNS dinamico sicuro tramite TKEY per creare il record A/AAAA per il nome di dominio completo. Se il record esiste già con lo stesso indirizzo IP, non vengono apportate modifiche.
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)
Memorizzazione nella cache DNS
Per ridurre il carico sui server DNS, i client DNS usano i concetti di memorizzazione nella cache per archiviare le query precedenti in memoria in modo che le richieste ripetute per un nome host, un indirizzo IP o un servizio vengano mantenute localmente per il periodo di tempo definito dal TTL del record DNS.
Azure NetApp Files usa cache DNS come qualsiasi altro client DNS standard. Quando il servizio richiede un record DNS, tale record ha una durata (TTL) definita. Per impostazione predefinita, le voci DNS di Active Directory hanno un valore TTL di 600 secondi (10 minuti), a meno che non sia specificato diversamente. Se un record DNS viene aggiornato e si trova nella cache di Azure NetApp Files e la durata (TTL) è di 10 minuti, il nuovo record non viene aggiornato in Azure NetApp Files finché la cache non viene ripulita dopo il valore di timeout. Attualmente non è possibile eliminare manualmente questa cache. Se si desidera un valore TTL inferiore, apportare la modifica dal server DNS.
Quando si usano server DNS esterni (ad esempio BIND), i valori di timeout predefiniti possono variare. Se non definito, il TTL di un record DNS BIND è di 604.800 secondi (sette giorni), troppo lungo per una memorizzazione nella cache DNS efficace. Di conseguenza, quando si creano manualmente record DNS, è importante impostare manualmente il valore TTL per il record su un valore ragionevole. L'uso di Microsoft predefinito di 10 minuti è consigliato per una combinazione di prestazioni e affidabilità per le ricerche DNS.
È possibile eseguire manualmente una query sulla durata (TTL) di un record DNS usando nslookup i comandi o dig . Per esempi, vedere Uso di nslookup e dig per le query DNS.
Eliminazione/scavenging del record DNS
La maggior parte dei server DNS fornisce metodi per eliminare e scavenge i 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.
Uso di nslookup e ricerca per le query DNS
I server DNS possono essere sottoposti a query manualmente usando strumenti DNS come nslookup (client Windows e Linux) e dig (client Linux). L'uso di questi strumenti è utile negli scenari, tra cui il tentativo di verificare la funzionalità dei servizi, il test della risoluzione dei nomi host/IP, la ricerca di record DNS esistenti/non aggiornati, il controllo della configurazione del server, la verifica della durata (TTL). È anche possibile usare lo strumento di risoluzione dei problemi di connessione di Azure per risolvere altri problemi.
I nslookup comandi e dig possono essere eseguiti da una connessione remota alla macchina virtuale (ad esempio da Bastion) o direttamente alla macchina virtuale tramite l'opzione esegui comando nella macchina virtuale stessa.
nslookup con Windows
È possibile eseguire nslookup per raccogliere informazioni sull'indirizzo IP di base senza opzioni:
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
Per eseguire query solo sulle informazioni TTL per il record, usare l'opzione -query=hinfo di comando .
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'opzione -debug può essere usata anche per raccogliere informazioni più dettagliate sul record 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)
scavare con 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
Procedure consigliate per DNS in Azure NetApp Files
Assicurarsi di soddisfare i requisiti di configurazione DNS seguenti:
- Specificare più server DNS nella configurazione DNS per la ridondanza.
- Per ottenere risultati ottimali, usare DNS integrato con e/o installato con Active Directory.
- Se si usano server DNS autonomi:
- Assicurarsi che i server DNS dispongano della connettività di rete alla subnet delegata di Azure NetApp Files che ospita i volumi di Azure NetApp Files.
- Verificare che le porte di rete UDP 53 e TCP 53 non siano bloccate da firewall o gruppi di sicurezza di rete.
- Verificare che i record SRV registrati dal servizio Accesso rete di Active Directory Domain Services siano stati creati nei server DNS, nonché i record del servizio elencati in Tipi di record DNS in Azure NetApp Files.
- 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.
- Assicurarsi che sia stata creata una zona di ricerca inversa per la subnet di Azure NetApp Files per consentire al DNS dinamico di creare record PTR oltre al record A/AAAA.
- Se è necessario un alias DNS, usare un record CNAME. Puntare il record CNAME ai record A/AAAA per Azure NetApp Files.
- Se non si usano aggiornamenti DNS dinamici, è necessario creare manualmente un record A e un record PTR per gli account computer di Servizi di dominio Active Directory creati nell'unità organizzativa di Active Directory Domain Services (specificata nella connessione Azure NetApp Files AD) per supportare la firma LDAP di Azure NetApp Files, LDAP su TLS, SMB, doppio protocollo o volumi Kerberos NFSv4.1.
- Per topologie di Active Directory Domain Services complesse o di grandi dimensioni, potrebbe essere necessario definire la priorità di criteri DNS o subnet DNS per supportare i 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.