Risoluzione dei nomi per le risorse in reti virtuali di Azure

  • Articolo

Attenzione

Questo articolo fa riferimento a CentOS, una distribuzione Linux prossima allo stato EOL (End of Life, fine del ciclo di vita). Valutare le proprie esigenze e pianificare di conseguenza. Per ulteriori informazioni, consultare la Guida alla fine del ciclo di vita di CentOS.

Azure può essere usato per ospitare soluzioni IaaS, PaaS e 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. L'uso di nomi facilmente memorizzati e non modificabili semplifica il processo di comunicazione, invece di basarsi sugli indirizzi IP.

Quando le risorse distribuite nelle reti virtuali devono risolvere i nomi di dominio negli indirizzi IP interni, possono usare uno dei quattro metodi seguenti:

Il tipo di risoluzione dei nomi usato dipende dal modo in cui le risorse devono comunicare tra loro. Nella tabella seguente vengono illustrate diverse ipotesi e le corrispondenti soluzioni di risoluzione dei nomi:

Nota

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

Nota

Se si usa DNS fornito da Azure, il suffisso DNS appropriato verrà applicato automaticamente alle macchine virtuali. Per tutte le altre opzioni è necessario usare nomi di dominio completi (FQDN) o applicare manualmente il suffisso DNS appropriato alle macchine virtuali.

Scenario Soluzione Suffisso DNS
Risoluzione dei nomi tra macchine virtuali situate nella stessa rete virtuale o tra istanze di ruolo di Servizi cloud di Microsoft Azure nello stesso servizio cloud. Zone private di DNS di Azure o risoluzione dei nomi fornita da Azure Nome host o nome di dominio completo
Risoluzione dei nomi tra macchine virtuali in diverse reti virtuali o istanze del ruolo in servizi cloud diversi. Zone private di DNS di Azure, resolver privato DNS di Azure o server DNS gestiti dal cliente che inoltrano query tra reti virtuali per la risoluzione da parte di Azure (proxy DNS). Vedere Risoluzione dei nomi usando il server DNS. Solo nome di dominio completo
Risoluzione dei nomi da un servizio app di Azure (App Web, Funzioni o Bot) con l'integrazione della rete virtuale in istanze del ruolo o macchine virtuali nella stessa rete virtuale. Resolver privato di DNS di Azure o server DNS gestiti dal cliente che inoltrano query tra reti virtuali per la risoluzione da parte di Azure (proxy DNS). Vedere Risoluzione dei nomi usando il server DNS. Solo nome di dominio completo
Risoluzione dei nomi da app Web del servizio app a macchine virtuali nella stessa rete virtuale. Resolver privato di DNS di Azure o server DNS gestiti dal cliente che inoltrano query tra reti virtuali per la risoluzione da parte di Azure (proxy DNS). Vedere Risoluzione dei nomi usando il server DNS. Solo nome di dominio completo
Risoluzione dei nomi da app Web del servizio app in una rete virtuale a macchine virtuali in una rete virtuale diversa. Resolver privato di DNS di Azure o server DNS gestiti dal cliente che inoltrano query tra reti virtuali per la risoluzione da parte di Azure (proxy DNS). Vedere Risoluzione dei nomi usando il server DNS. Solo nome di dominio completo
Risoluzione dei nomi di servizi e computer locali da istanze del ruolo o macchine virtuali in Azure. Resolver privato dns di Azure o server DNS gestiti dal cliente (controller di dominio locale, controller di dominio di sola lettura locale o un server DNS secondario sincronizzato tramite trasferimenti di zona, ad esempio). Vedere Risoluzione dei nomi usando il server DNS. Solo nome di dominio completo
Risoluzione di nomi host di Azure da computer locali. Inoltra le query a un server proxy DNS gestito dal cliente nella rete virtuale corrispondente. Il server proxy trasferisce le query ad Azure per la risoluzione. Vedere Risoluzione dei nomi usando il server DNS. Solo nome di dominio completo
DNS inversi per indirizzi IP interni. Zone private di DNS di Azure, risoluzione dei nomi fornita da Azure, resolver privato DNS di Azure o risoluzione dei nomi usando il proprio server DNS. Non applicabile
Risoluzione dei nomi tra macchine virtuali o istanze del ruolo situate in servizi cloud diversi e non in una rete virtuale. Non applicabile. Connessione tra macchine virtuali e istanze del ruolo in servizi cloud diversi non è supportata all'esterno di una rete virtuale. Non applicabile

Risoluzione dei nomi fornita da Azure

La risoluzione dei nomi fornita da Azure offre solo funzionalità DNS autorevoli di base. Azure gestisce i nomi e i record delle zone DNS se si usa il DNS fornito 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 zone private DNS di Azure con server DNS gestiti dal cliente o un 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 di un servizio cloud condividono lo stesso suffisso DNS, pertanto è sufficiente il solo nome host. Nelle reti virtuali implementate tramite il modello di distribuzione classica, invece, 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. I nomi DNS possono essere assegnati sia alle macchine virtuali che 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.

Nota

In caso di uso di ruoli Web e di lavoro basati su servizi cloud, è possibile accedere anche gli indirizzi IP interni delle istanze del ruolo con l'API REST di gestione del servizio Azure. Per altre informazioni, vedere Riferimento all'API REST di gestione dei servizi. L'indirizzo si basa sul nome del ruolo e sul numero di istanza.

Funzionalità

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

  • Facilità d'uso. Non è richiesta alcuna configurazione.

  • Disponibilità elevata. Non è necessario creare e gestire i cluster dei server DNS propri.

  • È possibile usare il servizio con i propri server DNS per risolvere i nomi host locali e 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.

  • Possibilità di usare la risoluzione dei nomi tra macchine virtuali presenti in reti virtuali che usano il modello di distribuzione Azure 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 risolve i nomi in servizi cloud diversi.

  • È possibile usare nomi host che descrivono meglio le distribuzioni anziché usare nomi generati automaticamente.

Considerazioni

Punti da considerare quando si usa la risoluzione dei nomi fornita da Azure:

  • Il suffisso DNS creato da Azure non può essere modificato.

  • 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.

  • Non è possibile registrare manualmente i propri record.

  • 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 0-9, a-z e '-' e non possono iniziare o terminare con un '-'.

  • Il traffico di query DNS è limitato per ogni VM. La limitazione non deve influire 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.

  • Usare un nome diverso per ogni macchina virtuale in una rete virtuale per evitare problemi di risoluzione DNS.

  • 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 Azure Resource Manager.

  • L'indirizzo IP DNS di Azure è 168.63.129.16. Questo indirizzo è un indirizzo IP statico e non cambia.

Considerazioni sul DNS inverso

IL DNS inverso per le macchine virtuali è supportato in tutte le reti virtuali basate su Azure Resource Manager. I record DNS inversi gestiti da Azure (PTR) nel formato [vmname].internal.cloudapp.net vengono aggiunti automaticamente all'avvio di una macchina virtuale e 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 formato [vmname].internal.cloudapp.net viene risolta nell'indirizzo IP assegnato alla macchina virtuale.

Se una zona privata DNS 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 in avanti di uno dei due nomi di dominio completo restituisce l'indirizzo IP della macchina virtuale.

Le ricerche DNS inverse hanno come ambito una determinata rete virtuale, 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.

Nota

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 creando una propria zona di ricerca inversa usando zone private dns di Azure e quindi collegando questa zona alla rete virtuale. Ad esempio, se lo spazio indirizzi IP della rete virtuale è 10.20.0.0/16, è possibile creare una zona DNS privata vuota 20.10.in-addr.arpa 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 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, è necessario disabilitare la registrazione automatica nella rete virtuale. Questa limitazione è dovuta a restrizioni che consentono di collegare una sola zona privata se la registrazione automatica è abilitata. Vedere la guida introduttiva al DNS privato per informazioni dettagliate su come creare una zona DNS privata e collegarla a una rete virtuale.

Nota

Poiché le zone private dns di Azure sono globali, è possibile creare una ricerca DNS inversa per estendersi su più reti virtuali. A tale scopo, creare una zona privata DNS di Azure per le ricerche inverse (una zona in-addr.arpa) e collegarla alle reti virtuali. Sarà necessario gestire manualmente i record DNS inversi per le macchine virtuali.

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 includono un meccanismo di durata (TTL) che consente alla cache di memorizzare il record per il periodo di tempo più lungo possibile senza che questo influisca sullo stato di aggiornamento del record. Di conseguenza, la memorizzazione nella cache sul lato client è ideale nella maggior parte dei casi.

Il client DNS di Windows predefinito contiene una cache DNS predefinita. Alcune distribuzioni di 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 la procedura per installare dnsmasq nelle distribuzioni più comuni:

RHEL/CentOS (usa NetworkManager):

  1. Installare il pacchetto dnsmasq con il comando seguente:

    sudo yum install dnsmasq

  2. Abilitare il servizio dnsmasq con il comando seguente:

    systemctl enable dnsmasq.service

  3. Avviare il servizio dnsmasq con il comando seguente:

    systemctl start dnsmasq.service

  4. Usare un editor di testo per aggiungere prepend domain-name-servers 127.0.0.1; a /etc/dhclient-eth0.conf:

  5. Usare il comando seguente per riavviare il servizio di rete:

    service network restart

Nota

Il pacchetto dnsmasq è solo una delle numerose cache DNS disponibili per Linux. Prima di usarlo, assicurarsi che sia adatto alle esigenze specifiche e verificare che non siano installate altre cache.

Ripetizione di tentativi sul lato client

DNS è principalmente un protocollo UDP. 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 aumentare il numero di ripetizione dei tentativi a 5, a intervalli di 1 secondo.

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

options timeout:1 attempts:5

Il file resolv.conf viene generato automaticamente e non deve essere modificato. La procedura specifica per aggiungere la riga options varia a seconda della distribuzione:

RHEL/CentOS (usa NetworkManager):

  1. Usare un editor di testo per aggiungere la riga RES_OPTIONS="options timeout:1 attempts:5" al file /etc/sysconfig/network-scripts/ifcfg-eth0.

  2. Usare il comando seguente per riavviare il servizio NetworkManager:

    systemctl restart NetworkManager.service

Risoluzione dei nomi con l'uso del proprio server DNS

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

Nota

Il sistema di risoluzione privato dns di Azure sostituisce la necessità di usare server DNS basati su vm in una rete virtuale. La sezione seguente viene fornita se si vuole usare una soluzione DNS basata su vm, ma esistono molti vantaggi per l'uso del sistema di risoluzione privato DNS di Azure, tra cui riduzione dei costi, disponibilità elevata predefinita, scalabilità e flessibilità.

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 utilizzare i domini di Active Directory in Microsoft Windows Server, risolvere i nomi DNS tra reti virtuali. Per coprire questi scenari, Azure consente di usare i propri server DNS.

I server DNS all'interno di una rete virtuale possono inoltrare query DNS ai resolver ricorsivi di Azure. Questa procedura consente di risolvere i nomi host all'interno della rete virtuale. Ad esempio, un controller di dominio eseguito in Azure può rispondere a query DNS relative ai propri 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, 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.

Importante

Se Gateway VPN viene usato in questa configurazione insieme all'indirizzo IP del server DNS personalizzato nella rete virtuale, è necessario aggiungere l'indirizzo IP DNS di Azure (168.63.129.16) nell'elenco e mantenere il servizio non interrotto.

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 trovarsi nella stessa rete virtuale ed essere configurata per l'inoltro di 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. L'immagine seguente illustra due reti virtuali e una rete locale che gestiscono la risoluzione DNS tra reti virtuali con il metodo descritto. Un esempio di server di inoltro DNS è disponibile nella raccolta di modelli di avvio rapido di Azure e su GitHub.

Nota

Un'istanza del ruolo può eseguire la risoluzione dei nomi di macchine virtuali all'interno della stessa rete virtuale. A tale scopo, usa il nome di dominio completo, costituito dal nome host della macchina virtuale e dal suffisso DNS internal.cloudapp.net. Tuttavia, in questo caso, la risoluzione dei nomi ha esito positivo solo se per l'istanza del ruolo il nome della VM è definito nello schema Role (file con estensione cscfg). <Role name="<role-name>" vmName="<vm-name>">

Le istanze del ruolo che devono eseguire la risoluzione dei nomi delle macchine virtuali in un'altra rete virtuale (nome di dominio completo con il suffisso internal.cloudapp.net) devono usare il metodo descritto in questa sezione (server DNS personalizzati per l'inoltro tra le due reti virtuali).

Figura della risoluzione DNS tra reti virtuali

Quando si usa la risoluzione dei nomi fornita da Azure, il protocollo DHCP (Dynamic Host Configuration Protocol) di Azure fornisce un suffisso DNS interno (con estensione internal.cloudapp.net) a ogni macchina virtuale. Questo suffisso consente la risoluzione dei nomi host perché i record dei nomi host si trovano nell'area internal.cloudapp.net. Quando si usa una 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 offre invece un segnaposto non funzionale (reddog.microsoft.com).

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

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

Se si fornisce una soluzione DNS personalizzata, è necessario:

  • Offrire una soluzione di risoluzione dei nomi host appropriata, ad esempio con DNS dinamico. 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.

  • Essere protetta dagli accessi provenienti da Internet per attenuare i rischi rappresentati da agenti esterni.

Nota

  • 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. È necessario modificare o sostituire le regole di sicurezza del gruppo di sicurezza di rete per consentire l'accesso alla porta UDP 53 (e facoltativamente alla porta TCP 53) agli endpoint del listener DNS. Una volta impostati server DNS personalizzati in una rete, il traffico attraverso la porta 53 ignora il gruppo di sicurezza di rete della subnet.

Importante

Se si usano server DNS Windows come server DNS personalizzati che inoltrano richieste DNS ai server DNS di Azure, assicurarsi di aumentare il valore di timeout di inoltro superiore a 4 secondi per consentire ai server DNS ricorsivi di Azure di eseguire operazioni di ricorsione appropriate.

Per altre informazioni su questo problema, vedere Timeout di risoluzione dei server d'inoltro e dei server d'inoltro condizionali.

Questa raccomandazione può essere applicata anche ad altre piattaforme server DNS con un valore di timeout di inoltro di 3 secondi o inferiore.

In caso contrario, è possibile che i record di zona DNS privato vengano risolti con indirizzi IP pubblici.

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 è ancora stato fatto, abilitare l'integrazione della rete virtuale per l'app Web, come descritto in Integrare un'app in 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 le query al resolver ricorsivo di 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 consentire all'app Web di collegarsi alla rete virtuale di origine, seguendo le istruzioni in Integrare un'app in una rete virtuale.

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

Specificare i server DNS

Quando si usano server DNS personalizzati, Azure consente di specificare più server DNS per ogni rete virtuale. È anche possibile specificare più server DNS per ogni interfaccia di rete (per Azure 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.

Nota

Le proprietà di connessione di rete, ad esempio gli INDIRIZZI IP del server DNS, non devono essere modificate direttamente all'interno delle macchine virtuali. Potrebbero infatti essere cancellate durante la correzione del servizio, quando la scheda di rete virtuale viene sostituita. Questo vale sia per le macchine virtuali Windows che per Linux.

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

Nota

Se si opta per il server DNS personalizzato per la rete virtuale, è necessario specificare almeno un indirizzo IP del server DNS. In caso contrario, la rete virtuale ignorerà la configurazione e userà invece il server DNS fornito da Azure.

Nota

Se si modificano le impostazioni DNS per una rete virtuale o una macchina virtuale già distribuita, per rendere effettive le nuove impostazioni DNS, è necessario eseguire un rinnovo del lease DHCP in tutte le macchine virtuali interessate nella rete virtuale. Per le macchine virtuali che eseguono il sistema operativo Windows, è possibile eseguire questa operazione digitando ipconfig /renew direttamente nella macchina virtuale. I passaggi variano a seconda del sistema operativo. Vedere la documentazione pertinente per il tipo di sistema operativo.

Passaggi successivi

Modello di distribuzione Azure Resource Manager: