Endpoint e set di regole del resolver privato del DNS di Azure

Questo articolo illustra i componenti del resolver privato DNS di Azure. Vengono illustrati gli endpoint in ingresso, gli endpoint in uscita e i set di regole di inoltro DNS. Vengono descritte le proprietà e le impostazioni di questi componenti e vengono forniti esempi per usarli.

L'architettura per il servizio Resolver privato DNS di Azure è riepilogata nella figura seguente. In questa rete di esempio un resolver DNS viene distribuito in una rete virtuale hub che esegue il peering con una rete virtuale spoke.

Diagramma che mostra l'architettura del resolver privato

Figura 1: Rete hub-spoke di esempio con resolver DNS

  • Il provisioning dei collegamenti del set di regole viene effettuato nel set di regole di inoltro DNS sia alle reti virtuali hub che spoke, consentendo alle risorse in entrambe le reti virtuali di risolvere spazi dei nomi DNS personalizzati usando regole di inoltro DNS.
  • Viene distribuita e collegata anche una zona DNS privata alla rete virtuale dell'hub, consentendo alle risorse nella rete virtuale dell'hub di risolvere i record nella zona.
  • La rete virtuale spoke risolve i record nella zona privata usando una regola di inoltro DNS che inoltra le query di zona privata all'indirizzo VIP dell'endpoint in ingresso nella rete virtuale dell'hub.
  • Nella figura è illustrata anche una rete locale connessa a ExpressRoute, con i server DNS configurati per inoltrare le query per la zona privata di Azure all'indirizzo VIP dell'endpoint in ingresso. Per altre informazioni sull'abilitazione della risoluzione DNS ibrida tramite il resolver privato DNS di Azure, vedere Risolvere i domini di Azure e locali.

Nota

La connessione di peering illustrata nel diagramma non è necessaria per la risoluzione dei nomi. Le reti virtuali collegate da un set di regole di inoltro DNS usano il set di regole durante l'esecuzione della risoluzione dei nomi, indipendentemente dal fatto che i peer di reti virtuali collegate con la rete virtuale del set di regole.

Endpoint in ingresso

Come suggerisce il nome, gli endpoint in ingresso in ingresso in Azure. Gli endpoint in ingresso forniscono un indirizzo IP per inoltrare le query DNS dall'ambiente locale e da altre posizioni all'esterno della rete virtuale. Le query DNS inviate all'endpoint in ingresso vengono risolte tramite DNS di Azure. DNS privato zone collegate alla rete virtuale in cui viene effettuato il provisioning dell'endpoint in ingresso vengono risolte dall'endpoint in ingresso.

L'indirizzo IP associato a un endpoint in ingresso fa sempre parte dello spazio di indirizzi della rete virtuale privata in cui viene distribuito il resolver privato. Nessun'altra risorsa può esistere nella stessa subnet con l'endpoint in ingresso.

Indirizzi IP statici ed endpoint dinamici

L'indirizzo IP assegnato a un endpoint in ingresso può essere statico o dinamico. Se si seleziona statico, non è possibile scegliere un indirizzo IP riservato nella subnet. Se si sceglie un indirizzo IP dinamico, viene assegnato il quinto indirizzo IP disponibile nella subnet. Ad esempio, 10.10.0.4 è il quinto indirizzo IP nella subnet 10.10.0.0/28 (.0, .1, .2, .3, .4). Se viene eseguito nuovamente il provisioning dell'endpoint in ingresso, questo indirizzo IP potrebbe cambiare, ma in genere viene usato di nuovo il 5° indirizzo IP nella subnet. L'indirizzo IP dinamico non cambia a meno che non venga eseguito nuovamente il provisioning dell'endpoint in ingresso. L'esempio seguente specifica un indirizzo IP statico:


Screenshot che mostra come scegliere un indirizzo IP statico.

L'esempio seguente mostra il provisioning di un endpoint in ingresso con un indirizzo IP virtuale (VIP) 10.10.0.4 all'interno della subnet snet-E-inbound all'interno di una rete virtuale con spazio indirizzi 10.10.0.0/16.

Screenshot che mostra gli endpoint in ingresso.

Endpoint in uscita

Gli endpoint in uscita da Azure e possono essere collegati a set di regole di inoltro DNS.

Gli endpoint in uscita fanno anche parte dello spazio indirizzi della rete virtuale privata in cui viene distribuito il sistema di risoluzione privato. Un endpoint in uscita è associato a una subnet, ma non viene effettuato il provisioning con un indirizzo IP come l'endpoint in ingresso. Nessun'altra risorsa può esistere nella stessa subnet con l'endpoint in uscita. Lo screenshot seguente mostra un endpoint in uscita all'interno della subnet snet-E-outbound.

Visualizzare gli endpoint in uscita

Set di regole di inoltro DNS

I set di regole di inoltro DNS consentono di specificare uno o più server DNS personalizzati per rispondere a query per spazi dei nomi DNS specifici. Le singole regole in un set di regole determinano la modalità di risoluzione di questi nomi DNS. I set di regole possono anche essere collegati a una o più reti virtuali, consentendo alle risorse nelle reti virtuali di usare le regole di inoltro configurate.

I set di regole hanno le associazioni seguenti:

  • Un singolo set di regole può essere associato a un massimo di 2 endpoint in uscita appartenenti alla stessa istanza del resolver privato DNS. Non può essere associato a 2 endpoint in uscita in due diverse istanze del resolver privato DNS.
  • Un set di regole può avere fino a 1000 regole di inoltro DNS.
  • Un set di regole può essere collegato a un massimo di 500 reti virtuali nella stessa area.

Un set di regole non può essere collegato a una rete virtuale in un'altra area. Per altre informazioni sul set di regole e altri limiti del resolver privato, vedere Quali sono i limiti di utilizzo per DNS di Azure?.

Quando si collega un set di regole a una rete virtuale, le risorse all'interno della rete virtuale usano le regole di inoltro DNS abilitate nel set di regole. Le reti virtuali collegate non sono necessarie per eseguire il peering con la rete virtuale in cui è presente l'endpoint in uscita, ma queste reti possono essere configurate come peer. Questa configurazione è comune in una progettazione hub-spoke. In questo scenario hub-spoke, la rete virtuale spoke non deve essere collegata alla zona DNS privata per risolvere i record di risorse nella zona. In questo caso, la regola del set di regole di inoltro per la zona privata invia query all'endpoint in ingresso della rete virtuale dell'hub. Ad esempio: azure.contoso.com a 10.10.0.4.

Lo screenshot seguente mostra un set di regole di inoltro DNS collegato alla rete virtuale spoke: myeastspoke.

Visualizzare i collegamenti del set di regole

I collegamenti di rete virtuale per i set di regole di inoltro DNS consentono alle risorse in altre reti virtuali di usare regole di inoltro durante la risoluzione dei nomi DNS. La rete virtuale con il sistema di risoluzione privato deve essere collegata anche da qualsiasi zona DNS privata per cui sono presenti regole del set di regole.

Ad esempio, le risorse nella rete myeastspoke virtuale possono risolvere i record nella zona azure.contoso.com DNS privata se:

  • Il set di regole di cui è stato effettuato il provisioning in myeastvnet è collegato a myeastspoke
  • Una regola del set di regole è configurata e abilitata nel set di regole collegato per risolvere azure.contoso.com l'uso dell'endpoint in ingresso in myeastvnet

Nota

È anche possibile collegare un set di regole a una rete virtuale in un'altra sottoscrizione di Azure. Tuttavia, il gruppo di risorse specificato deve trovarsi nella stessa area del sistema di risoluzione privato.

Regole

Le regole di inoltro DNS (regole del set di regole) hanno le proprietà seguenti:

Proprietà Descrizione
Nome regola Nome della regola. Il nome deve iniziare con una lettera e può contenere solo lettere, numeri, caratteri di sottolineatura e trattini.
Nome di dominio Spazio dei nomi DNS con terminazione con punto in cui si applica la regola. Lo spazio dei nomi deve avere etichette zero (per caratteri jolly) o tra 1 e 34 etichette. Ad esempio, contoso.com. ha due etichette.1
IP di destinazione:Porta Destinazione di inoltro. Uno o più indirizzi IP e porte dei server DNS usati per risolvere le query DNS nello spazio dei nomi specificato.
Stato della regola Stato della regola: abilitato o disabilitato. Se una regola è disabilitata, viene ignorata.

1 Sonosupportati nomi di dominio con etichetta singola.

Se vengono confrontate più regole, viene usata la corrispondenza del prefisso più lunga.

Ad esempio, se si dispone delle regole seguenti:

Nome regola Nome di dominio IP di destinazione:Porta Stato della regola
Contoso .contoso.com 10.100.0.2:53 Attivata
AzurePrivate azure.contoso.com. 10.10.0.4:53 Attivata
Wildcard (Carattere jolly) . 10.100.0.2:53 Attivata

Una query per secure.store.azure.contoso.com corrisponde alla regola AzurePrivate per azure.contoso.com e anche alla regola Contoso per contoso.com, ma la regola AzurePrivate ha la precedenza perché il prefisso azure.contoso è più lungo di contoso.

Importante

Se una regola è presente nel set di regole con come destinazione un endpoint in ingresso del resolver privato, non collegare il set di regole alla rete virtuale in cui viene effettuato il provisioning dell'endpoint in ingresso. Questa configurazione può causare cicli di risoluzione DNS. Ad esempio: nello scenario precedente non deve essere aggiunto alcun collegamento al myeastvnet set di regole perché viene effettuato il provisioning dell'endpoint 10.10.0.4 in ingresso in myeastvnet e una regola viene risolta azure.contoso.com usando l'endpoint in ingresso.

Le regole illustrate in questo articolo sono esempi di regole che è possibile usare per scenari specifici. Gli esempi usati non sono obbligatori. Prestare attenzione a testare le regole di inoltro.

Se si include una regola con caratteri jolly nel set di regole, assicurarsi che il servizio DNS di destinazione possa risolvere i nomi DNS pubblici. Alcuni servizi di Azure hanno dipendenze dalla risoluzione dei nomi pubblici.

Elaborazione delle regole

  • Se vengono immessi più server DNS come destinazione per una regola, viene usato il primo indirizzo IP immesso, a meno che non risponda. Un algoritmo di backoff esponenziale viene usato per determinare se un indirizzo IP di destinazione è reattivo o meno.
  • Alcuni domini vengono ignorati quando si usa una regola con caratteri jolly per la risoluzione DNS, perché sono riservati ai servizi di Azure. Per un elenco di domini riservati, vedere Configurazione della zona DNS dei servizi di Azure. I nomi DNS a due etichette elencati in questo articolo, ad esempio windows.net, azure.com, azure.net windowsazure.us, sono riservati ai servizi di Azure.

Importante

  • Non è possibile immettere l'indirizzo IP DNS di Azure 168.63.129.16 come indirizzo IP di destinazione per una regola. Il tentativo di aggiungere questo indirizzo IP restituisce l'errore: eccezione durante l'esecuzione di una richiesta di aggiunta per la regola.
  • Non usare l'indirizzo IP dell'endpoint in ingresso del resolver privato come destinazione di inoltro per le zone che non sono collegate alla rete virtuale in cui viene effettuato il provisioning del resolver privato.

Opzioni di progettazione

La modalità di distribuzione dei set di regole di inoltro e degli endpoint in ingresso in un'architettura hub-spoke dipende idealmente dalla progettazione della rete. Due opzioni di configurazione sono descritte brevemente nelle sezioni seguenti. Per una descrizione più dettagliata degli esempi di configurazione, vedere Architettura del resolver privato.

Il collegamento di un set di regole di inoltro a una rete virtuale consente le funzionalità di inoltro DNS in tale rete virtuale. Ad esempio, se un set di regole contiene una regola per inoltrare le query all'endpoint in ingresso di un resolver privato, questo tipo di regola può essere usato per abilitare la risoluzione delle zone private collegate alla rete virtuale dell'endpoint in ingresso. Questa configurazione può essere usata in cui una rete virtuale hub è collegata a una zona privata e si vuole consentire la risoluzione della zona privata nelle reti virtuali spoke che non sono collegate alla zona privata. In questo scenario, la risoluzione DNS della zona privata viene eseguita dall'endpoint in ingresso nella rete virtuale dell'hub.

Lo scenario di progettazione dei collegamenti al set di regole è più adatto a un'architettura DNS distribuita in cui il traffico di rete viene distribuito nella rete di Azure e potrebbe essere univoco in alcune posizioni. Con questa progettazione, è possibile controllare la risoluzione DNS in tutte le reti virtuali collegate al set di regole modificando un singolo set di regole.

Nota

Se si usa l'opzione di collegamento del set di regole e è presente una regola di inoltro con l'endpoint in ingresso come destinazione, non collegare il set di regole di inoltro alla rete virtuale dell'hub. Il collegamento di questo tipo di set di regole alla stessa rete virtuale in cui viene effettuato il provisioning dell'endpoint in ingresso può comportare un ciclo di risoluzione DNS.

Endpoint in ingresso come DNS personalizzato

Gli endpoint in ingresso sono in grado di elaborare le query DNS in ingresso e possono essere configurati come DNS personalizzati per una rete virtuale. Questa configurazione può sostituire le istanze in cui si usa il proprio server DNS come DNS personalizzato in una rete virtuale.

Lo scenario di progettazione DNS personalizzato è più adatto a un'architettura DNS centralizzata in cui la risoluzione DNS e il flusso del traffico di rete si trovano principalmente in una rete virtuale hub ed è controllato da una posizione centrale.

Per risolvere una zona DNS privata da una rete virtuale spoke usando questo metodo, la rete virtuale in cui è presente l'endpoint in ingresso deve essere collegata alla zona privata. La rete virtuale hub può essere (facoltativamente) collegata a un set di regole di inoltro. Se un set di regole è collegato all'hub, tutto il traffico DNS inviato all'endpoint in ingresso viene elaborato dal set di regole.

Passaggi successivi