Risoluzione dei nomi per le risorse in reti virtuali di Azure

È possibile usare Azure per ospitare l'infrastruttura distribuita come servizio (IaaS), la piattaforma distribuita come servizio (PaaS) e le soluzioni ibride. Per facilitare la comunicazione tra le macchine virtuali (VM) e altre risorse distribuite in una rete virtuale, potrebbe essere necessario consentire loro di comunicare tra loro. Rispetto agli indirizzi IP, l'uso di nomi facili da ricordare e non modificabili semplifica il processo di comunicazione.

Quando le risorse distribuite nelle reti virtuali devono risolvere nomi di dominio trasformandoli in indirizzi IP interni, possono usare uno di questi quattro metodi:

• Zone DNS privato di Azure
• Risoluzione dei nomi fornita da Azure
• Risoluzione dei nomi che usa il proprio server DNS (Domain Name System) (che potrebbe inoltrare query ai server DNS forniti da Azure)
• Resolver privato DNS di Azure

Il tipo di risoluzione dei nomi usato dipende dal modo in cui le risorse devono comunicare tra loro. La tabella seguente illustra gli scenari e le soluzioni di risoluzione dei nomi corrispondenti.

Le zone DNS privato di Azure sono la soluzione preferita e offrono flessibilità nella gestione delle zone e dei record DNS. Per altre informazioni, vedere Usare DNS di Azure per i domini privati.

Risoluzione dei nomi fornita da Azure

La risoluzione dei nomi fornita da Azure offre solo funzionalità DNS autorevoli di base. Se si usa il DNS fornito da Azure, i nomi e i record delle zone DNS sono gestiti da Azure. Non è possibile controllare i nomi delle zone DNS o il ciclo di vita dei record DNS. Se è necessaria una soluzione DNS completa per le reti virtuali, è possibile usare le zone di Azure DNS privato con server DNS gestiti dal cliente o resolver privato DNS di Azure.

Oltre alla risoluzione dei nomi DNS pubblici, Azure offre la risoluzione dei nomi interni per VM e istanze del ruolo che si trovano all'interno della stessa rete virtuale o dello stesso servizio cloud. Le macchine virtuali e le istanze in un servizio cloud condividono lo stesso suffisso DNS, quindi il solo nome host è sufficiente. Nelle reti virtuali distribuite usando il modello di distribuzione classica, tuttavia, servizi cloud diversi hanno suffissi DNS diversi. In questo caso, è necessario il nome di dominio completo per la risoluzione dei nomi tra servizi cloud diversi.

Nelle reti virtuali distribuite usando il modello di distribuzione azure Resource Manager, il suffisso DNS è coerente in tutte le macchine virtuali all'interno di una rete virtuale, quindi il nome di dominio completo non è necessario. È possibile assegnare nomi DNS alle macchine virtuali e alle interfacce di rete. Anche se la risoluzione dei nomi fornita da Azure non richiede alcuna configurazione, non è la scelta appropriata per tutti gli scenari di distribuzione, come descritto nella tabella precedente.

Funzionalità

La risoluzione dei nomi fornita da Azure presenta le caratteristiche seguenti:

• Non è necessario configurare nulla.
• Non è necessario creare e gestire cluster dei propri server DNS a causa della disponibilità elevata.
• È possibile usare il servizio con i propri server DNS per risolvere sia i nomi host locali che i nomi host di Azure.
• Possibilità di usare la risoluzione dei nomi tra istanze del ruolo e macchine virtuali presenti nello stesso servizio cloud, senza la necessità di un nome di dominio completo.
• È possibile usare la risoluzione dei nomi tra le macchine virtuali nelle reti virtuali che usano il modello di distribuzione Resource Manager, senza la necessità di un nome di dominio completo. Le reti virtuali nel modello di distribuzione classica richiedono un nome di dominio completo quando si risolvono i nomi in servizi cloud diversi.
• È possibile usare nomi host che descrivono meglio le distribuzioni, anziché usare nomi generati automaticamente.

Considerazioni

Quando si usa la risoluzione dei nomi fornita da Azure, considerare i punti seguenti:

• Non è possibile modificare il suffisso DNS creato da Azure.
• L'ambito della ricerca DNS è limitato a una rete virtuale. I nomi DNS creati per una rete virtuale non possono essere risolti da altre reti virtuali.
• La registrazione manuale dei propri record non è consentita.
• WINS e NetBIOS non sono supportati. Non è possibile visualizzare le macchine virtuali in Esplora risorse.
• I nomi host devono essere compatibili con DNS. I nomi devono usare solo da 0 a 9, da a z e un trattino (-). I nomi non possono iniziare o terminare con un trattino.
• Il traffico di query DNS è limitato per ogni VM. La limitazione in genere non influisce sulla maggior parte delle applicazioni. Se si osserva la limitazione delle richieste, assicurarsi che la memorizzazione nella cache lato client sia abilitata. Per altre informazioni, vedere Configurazione del client DNS.
• Per evitare problemi di risoluzione DNS, è necessario usare un nome diverso per ogni macchina virtuale in una rete virtuale.
• Solo le VM nei primi 180 servizi cloud sono registrate per ogni rete virtuale in un modello di distribuzione classica. Questo limite non si applica alle reti virtuali in Resource Manager.
• L'indirizzo IP DNS di Azure è 168.63.129.16. Si tratta di un indirizzo IP statico non modificabile.

Considerazioni sul DNS inverso

Il DNS inverso per le macchine virtuali è supportato in tutte le reti virtuali basate su Resource Manager. DNS inverso gestito da Azure, noto anche come puntatore (PTR), i record di modulo \[vmname\].internal.cloudapp.net vengono aggiunti automaticamente al DNS all'avvio di una macchina virtuale. Vengono rimossi quando la macchina virtuale viene arrestata (deallocata). Vedere l'esempio seguente:

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 internal.cloudapp.net zona DNS inversa è gestita da Azure e non può essere visualizzata o modificata direttamente. La ricerca diretta sul nome di dominio completo del modulo \[vmname\].internal.cloudapp.net viene risolta nell'indirizzo IP assegnato alla macchina virtuale.

Se una zona DNS privato di Azure è collegata alla rete virtuale con un collegamento di rete virtuale e la registrazione automatica è abilitata in tale collegamento, le query DNS inverse restituiscono due record. Un record è del formato \[vmname\].[privatednszonename] e l'altro è del formato \[vmname\].internal.cloudapp.net. Vedere l'esempio seguente:

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

Quando vengono restituiti due record PTR come illustrato in precedenza, la ricerca diretta di uno dei due nomi di dominio completo restituisce l'indirizzo IP della macchina virtuale.

Le ricerche DNS inverse hanno come ambito una rete virtuale specifica, anche se viene eseguito il peering ad altre reti virtuali. Le query DNS inverse per gli indirizzi IP delle macchine virtuali che si trovano nelle reti virtuali con peering restituiscono NXDOMAIN.

I record DNS inversi (PTR) non vengono archiviati in una zona DNS privata in avanti. I record DNS inversi vengono archiviati in una zona DNS inversa (in-addr.arpa). La zona DNS inversa predefinita associata a una rete virtuale non è visualizzabile o modificabile.

È possibile disabilitare la funzione DNS inversa in una rete virtuale. Creare una propria zona di ricerca inversa usando le zone di DNS privato di Azure. Collegare quindi questa zona alla rete virtuale. Ad esempio, se lo spazio indirizzi IP della rete virtuale è 10.20.0.0/16, è possibile creare una zona 20.10.in-addr.arpa DNS privata vuota e collegarla alla rete virtuale. Questa zona esegue l'override delle zone di ricerca inversa predefinite per la rete virtuale. Questa zona è vuota. Il DNS inverso restituisce a NXDOMAIN meno che non si creino manualmente queste voci.

La registrazione automatica dei record PTR non è supportata. Se si desidera creare voci, immetterle manualmente. Se abilitata per altre zone, la registrazione automatica deve essere disabilitata nella rete virtuale. Questa limitazione è dovuta a restrizioni che consentono di collegare una sola zona privata se la registrazione automatica è abilitata. Per informazioni su come creare una zona DNS privata e collegarla a una rete virtuale, vedere l'argomento di avvio rapido di Azure DNS privato.

Configurazione del client DNS

Questa sezione descrive la memorizzazione nella cache sul lato client e la ripetizione di tentativi sul lato client.

Memorizzazione nella cache sul lato client

Non tutte le query DNS devono essere inviate attraverso la rete. La memorizzazione nella cache sul lato client consente di ridurre la latenza e migliorare la resilienza ai blip (brevi interruzioni) di rete, tramite la risoluzione di query DNS ricorrenti da una cache locale. I record DNS contengono un meccanismo time-to-live, che consente alla cache di archiviare il record per tutto il tempo possibile senza influire sull'aggiornamento del record. La memorizzazione nella cache lato client è adatta per la maggior parte delle situazioni.

Il client DNS Windows predefinito include una cache DNS incorporata. Alcune distribuzioni Linux non includono la memorizzazione nella cache per impostazione predefinita. Se si verifica che non è presente una cache locale, aggiungere una cache DNS a ogni macchina virtuale Linux.

Sono disponibili molti pacchetti di memorizzazione nella cache DNS diversi, ad esempio dnsmasq. Ecco come eseguire l'installazione dnsmasq nelle distribuzioni più comuni:

sudo apt-get install dnsmasq

Ripetizione di tentativi sul lato client

DNS è principalmente un protocollo UDP (User Datagram Protocol). Poiché UDP non garantisce il recapito dei messaggi, la logica di ripetizione dei tentativi viene gestita nel protocollo DNS stesso. Ogni client DNS (sistema operativo) può includere una logica di ripetizione dei tentativi diversa, in base alle preferenze dell'autore:

• I sistemi operativi Windows eseguono un nuovo tentativo dopo 1 secondo e quindi ne eseguono un altro dopo 2, 4 e altri 4 secondi.
• La configurazione di Linux predefinita esegue il tentativo dopo 5 secondi. È consigliabile modificare le specifiche dei tentativi impostando cinque volte, a intervalli di un secondo.

Controllare le impostazioni correnti in una VM Linux con cat /etc/resolv.conf. Esaminare la options riga, ad esempio:

options timeout:1 attempts:5

Il resolv.conf file viene generato automaticamente e non deve essere modificato. I passaggi specifici per l'aggiunta della riga variano in base alla options distribuzione.

Risoluzione dei nomi con l'uso del proprio server DNS

Questa sezione descrive le macchine virtuali, le istanze del ruolo e le app Web.

Istanze del ruolo e delle VM

Le funzionalità offerte da Azure possono non essere sufficienti a soddisfare le esigenze di risoluzione dei nomi di un utente. Ad esempio, potrebbe essere necessario usare i domini di Active Directory di Windows Server per risolvere i nomi DNS tra reti virtuali. Per coprire questi scenari, è possibile usare i propri server DNS.

I server DNS all'interno di una rete virtuale possono inoltrare query DNS ai resolver ricorsivi di Azure. Usando questa procedura, è possibile risolvere i nomi host all'interno della rete virtuale. Ad esempio, un controller di dominio in esecuzione in Azure può rispondere a query DNS per i relativi domini e inoltrare tutte le altre query ad Azure. L'inoltro delle query consente alle VM di visualizzare sia le risorse locali, tramite il controller di dominio, sia i nomi host forniti da Azure, tramite il server di inoltro. L'accesso ai resolver ricorsivi di Azure viene fornito tramite l'indirizzo IP virtuale 168.63.129.16.

L'inoltro DNS consente anche la risoluzione DNS tra reti virtuali e consente ai computer locali di risolvere i nomi host forniti da Azure. Per risolvere il nome host di una macchina virtuale, la macchina virtuale del server DNS deve risiedere nella stessa rete virtuale ed essere configurata per inoltrare le query relative ai nomi host ad Azure. Poiché il suffisso DNS è diverso in ogni rete virtuale, è possibile usare le regole di inoltro condizionale per inviare le query DNS alla rete virtuale corretta per la risoluzione.

Due reti virtuali e una rete locale usano questo metodo per eseguire la risoluzione DNS tra reti virtuali, come illustrato nel diagramma seguente. Un esempio di server di inoltro DNS è disponibile nella raccolta di modelli di avvio rapido di Azure e su GitHub.

.

Quando si usa la risoluzione dei nomi fornita da Azure, il protocollo DHCP (Dynamic Host Configuration Protocol) di Azure fornisce un suffisso DNS interno (.internal.cloudapp.net) a ogni macchina virtuale. Questo suffisso abilita la risoluzione del nome host perché i record del nome host si trovano nella internal.cloudapp.net zona. Quando si usa la soluzione di risoluzione dei nomi personalizzata, questo suffisso non viene fornito alle macchine virtuali perché interferisce con altre architetture DNS ,ad esempio scenari aggiunti a un dominio. Azure assegna invece un segnaposto non funzionante (reddog.microsoft.com).

Se necessario, è possibile determinare il suffisso DNS interno usando PowerShell o l'API.

Per le reti virtuali nei modelli di distribuzione di Resource Manager, il suffisso è disponibile tramite l'API REST dell'interfaccia di rete, il cmdlet PowerShell Get-AzNetworkInterface e il comando az network nic show dell'interfaccia di comando di Azure.

Se l'inoltro di query ad Azure non soddisfa le proprie esigenze, fornire una soluzione DNS personalizzata o distribuire il resolver privato DNS di Azure.

Se si fornisce la propria soluzione DNS, è necessario:

• Fornire una risoluzione del nome host appropriata, ad esempio tramite DNS dinamico (DDNS). Se si usa DDNS, potrebbe essere necessario disabilitare lo scavenging dei record DNS. I lease DHCP di Azure sono lunghi e lo scavenging potrebbe rimuovere prematuramente i record DNS.
• Fornire una soluzione di risoluzione ricorsiva appropriata per consentire la risoluzione dei nomi di dominio esterni.
• Essere accessibile (tramite TCP e UDP sulla porta 53) dai client che gestisce ed essere in grado di accedere a Internet.
• Essere protetti dall'accesso da Internet per attenuare le minacce poste da agenti esterni.

Per ottenere prestazioni ottimali, quando si usano macchine virtuali di Azure come server DNS, IPv6 deve essere disabilitato.

I gruppi di sicurezza di rete fungono da firewall per gli endpoint del resolver DNS. Modificare o ignorare le regole di sicurezza del gruppo di sicurezza di rete per consentire l'accesso per la porta UDP 53 (e facoltativamente, la porta TCP 53) agli endpoint del listener DNS. Dopo che i server DNS personalizzati sono impostati in una rete, il traffico attraverso la porta 53 ignora i gruppi di sicurezza di rete della subnet.

App Web

Si supponga di dover eseguire la risoluzione dei nomi dall'app Web creata tramite il servizio app, collegato a una rete virtuale, nelle macchine virtuali presenti nella stessa rete virtuale. Oltre a configurare un server DNS personalizzato dotato di un server di inoltro di query ad Azure (IP virtuale 168.63.129.16), eseguire la procedura seguente:

• Se non è già stato fatto, abilitare l'integrazione della rete virtuale per l'app Web, come descritto in Integrare l'app con una rete virtuale.
• Se è necessario eseguire la risoluzione dei nomi dall'app Web collegata alla rete virtuale (compilata usando servizio app) alle macchine virtuali in una rete virtuale diversa non collegata alla stessa zona privata, usare server DNS personalizzati o resolver privati DNS di Azure in entrambe le reti virtuali.

Per usare server DNS personalizzati:

• Configurare un server DNS nella rete virtuale di destinazione in una macchina virtuale che può anche inoltrare query al resolver ricorsivo in Azure (INDIRIZZO IP virtuale 168.63.129.16). Un esempio di server di inoltro DNS è disponibile nella raccolta di modelli di avvio rapido di Azure e su GitHub.
• Configurare un server d'inoltro DNS nella rete virtuale di origine in una VM. Configurare questo server d'inoltro DNS per inoltrare le query al server DNS nella rete virtuale di destinazione.
• Configurare il server DNS di origine nelle impostazioni della rete virtuale di origine.
• Abilitare l'integrazione della rete virtuale per l'app Web per collegarsi alla rete virtuale di origine seguendo le istruzioni riportate in Integrare l'app con una rete virtuale.

Per usare il sistema di risoluzione privato DNS di Azure, vedere Collegamenti al set di regole.

Specificare i server DNS

Quando si usano server DNS personalizzati, è possibile specificare più server DNS per rete virtuale. È anche possibile specificare più server DNS per ogni interfaccia di rete (per Resource Manager) o per servizio cloud (per il modello di distribuzione classica). I server DNS specificati per un'interfaccia di rete o un servizio cloud hanno la precedenza su quelli specificati per la rete virtuale.

Quando si usa il modello di distribuzione Resource Manager, è possibile specificare i server DNS per una rete virtuale e un'interfaccia di rete. Per altre informazioni, vedere Gestire una rete virtuale e Gestire un'interfaccia di rete.

Se si sceglie un server DNS personalizzato per la rete virtuale, è necessario specificare almeno un indirizzo IP del server DNS. In caso contrario, la rete virtuale ignora la configurazione e usa il DNS fornito da Azure.

Contenuto correlato

Modello di distribuzione Azure Resource Manager:

• Gestire una rete virtuale
• Gestire un'interfaccia di rete