Configurare la risoluzione dei nomi DNS per le reti virtuali di Azure

Le reti virtuali di Azure supportano più metodi di risoluzione dei nomi per l'infrastruttura distribuita come servizio (IaaS), la piattaforma distribuita come servizio (PaaS) e le soluzioni ibride. Per abilitare la comunicazione tra macchine virtuali e altre risorse in una rete virtuale, è necessaria una configurazione DNS appropriata. L'uso di nomi facilmente memorizzati e coerenti semplifica il processo di comunicazione, anziché basarsi sugli indirizzi IP.

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 con l'uso del 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 seguente tabella illustra gli scenari e le corrispondenti soluzioni di risoluzione dei nomi.

Le zone DNS privato di Azure rappresentano la soluzione preferita, offrendo 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 DNS privato di Azure 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 interna per le macchine virtuali e le istanze di ruolo nel contesto della stessa rete virtuale o servizio cloud. Le macchine virtuali e le istanze in un servizio cloud condividono lo stesso suffisso DNS, rendendo il nome host sufficiente per la risoluzione. Tuttavia, nelle reti virtuali del modello di distribuzione classica, servizi cloud diversi hanno suffissi DNS distinti, che richiedono il nome di dominio completo per risolvere i nomi tra i servizi cloud.

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 soluzione adatta a tutti gli scenari di distribuzione, come descritto nella tabella precedente.

Features

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

• Non è necessario configurare nulla.
• Non è necessario creare e gestire cluster di server DNS propri grazie alla disponibilità elevata.
• È possibile usare il servizio con i propri server DNS per la risoluzione sia dei nomi host locali che quelli di Azure.
• È possibile utilizzare la risoluzione dei nomi tra macchine virtuali e istanze di ruolo all'interno dello 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 per la risoluzione dei nomi tra diversi servizi cloud.
• È possibile usare nomi host che descrivano al meglio le distribuzioni, anziché lavorare con nomi generati automaticamente.

Considerations

Quando si usa la risoluzione dei nomi fornita da Azure, tenere presenti i seguenti aspetti:

• Non è possibile modificare il suffisso DNS creato da Azure.
• La ricerca DNS è limitata 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 file di Windows.
• I nomi host devono essere compatibili con DNS. I nomi possono contenere solo numeri da 0 a 9, lettere dalla a alla z e un trattino (-). I nomi non possono iniziare o terminare con un trattino.
• Il traffico di query DNS è limitato per ogni macchina virtuale. La limitazione non influisce sulla maggior parte delle applicazioni. Se viene osservata la limitazione delle richieste, assicurarsi che la memorizzazione nella cache sul 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 macchine virtuali nei primi 180 servizi cloud vengono 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 del 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. I record DNS inversi gestiti da Azure, noto anche come puntatore (PTR), nel formato \[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 zona DNS inversa internal.cloudapp.net è gestita da Azure e non può essere visualizzata o modificata direttamente. La ricerca diretta sul nome di dominio completo della forma \[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 è nel formato \[vmname\].[privatednszonename] e l'altro è nel 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 completi restituisce l'indirizzo IP della macchina virtuale.

Le ricerche DNS inverse sono limitate a una specifica rete virtuale, anche se la rete è peering con 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 privato diretta. 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 né modificabile.

È possibile disabilitare la funzione DNS inversa in una rete virtuale. Creare una propria zona di ricerca inversa usando le zone DNS privato di Azure. Quindi collegare questa zona alla rete virtuale. Ad esempio, se lo spazio degli indirizzi IP della rete virtuale è 10.20.0.0/16, è possibile creare una zona DNS privata 20.10.in-addr.arpa 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 NXDOMAIN, a meno che queste voci non vengano create manualmente.

La registrazione automatica dei record PTR non è supportata. Immettere manualmente le voci che si intende creare. Se abilitata per altre zone, la registrazione automatica deve essere disabilitata nella rete virtuale. Questa limitazione esiste a causa di restrizioni che consentono di collegare una sola zona privata se la registrazione automatica è abilitata. Per informazioni su come creare una zona DNS privato e collegarla a una rete virtuale, vedere la guida introduttiva su Zona 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 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 includono un meccanismo time-to-live, che consente alla cache di archiviare il record il più a lungo possibile senza comprometterne l'aggiornamento. La memorizzazione nella cache lato client è adatta alla maggior parte delle situazioni.

Il client DNS predefinito di Windows include una cache DNS integrata. 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 diversi pacchetti per la memorizzazione nella cache DNS (ad esempio dnsmasq). "Ecco come installare dnsmasq sulle distribuzioni più comuni:

sudo apt-get install dnsmasq

Ripetizione di tentativi sul lato client

DNS utilizza principalmente il 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 di ripetizione a cinque volte, a intervalli di un secondo.

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

options timeout:1 attempts:5

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

Risoluzione dei nomi con l'uso del proprio server DNS

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

Macchine virtuali e istanze di ruolo

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 domini di Windows Server Active Directory per risolvere i nomi DNS tra le reti virtuali. Per gestire 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 di quella 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 macchine virtuali di visualizzare sia le risorse locali (tramite il controller di dominio) che i nomi host forniti da Azure (tramite il server d'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 permette 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 utilizzano questo metodo per la risoluzione DNS tra le reti virtuali, come mostrato nel diagramma seguente. Un esempio di server di inoltro DNS è disponibile nella raccolta di modelli di avvio rapido di Azure e su GitHub.

! [Diagramma che mostra il DNS tra reti virtuali](./media/virtual-networks-name-resolution-for-virtual machines-and-role-instances/inter-vnet-dns.png).

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 zona internal.cloudapp.net. 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). Al contrario, Azure fornisce un segnaposto non funzionale (reddog.microsoft.com).

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

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

Se l'inoltro delle query ad Azure non soddisfa le esigenze specifiche, sarà necessario offrire la propria soluzione DNS o implementare 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. Le lease DHCP di Azure sono lunghe e lo scavenging potrebbe rimuovere i record DNS in modo anomalo.
• 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.
• Proteggersi dall'accesso da Internet per mitigare le minacce provenienti 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 (NSG) fungono da firewall per gli endpoint del risolutore Domain Name Server. Modificare o sostituire le regole di sicurezza del gruppo di sicurezza di rete per consentire l'accesso agli endpoint del listener DNS tramite la porta UDP 53 (e facoltativamente la porta TCP 53). Dopo aver impostato server DNS personalizzati su una rete, il traffico attraverso la porta 53 passa oltre gli NSG della subnet e la scheda di rete.

Applicazioni web

Si supponga di dover eseguire la risoluzione dei nomi dalla tua app Web costruita utilizzando App Service, collegata a una rete virtuale, verso macchine virtuali 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 con la rete virtuale per l'app Web, come descritto in Integrare l'app con una rete virtuale.
• Per eseguire la risoluzione dei nomi dall'app Web collegata alla rete virtuale (creata con 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:

• Configura un server DNS nella rete virtuale di destinazione in una macchina virtuale che possa anche inoltrare le query al resolver ricorsivo in Azure (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 in Integrare l'app con una rete virtuale.

Per usare DNS di Azure resolver privato, vedere collegamenti Ruleset.

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 ogni 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 di usare 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 invece il DNS fornito da Azure.

Contenuti correlati

Modello di distribuzione Azure Resource Manager:

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