Progettare una soluzione DNS (Domain Name System) ibrida con Azure

Questa architettura di riferimento illustra come progettare una soluzione DNS (Domain Name System) ibrida per risolvere i nomi per i carichi di lavoro ospitati in locale e in Microsoft Azure. Questa architettura funziona per gli utenti e altri sistemi che si connettono dall'ambiente locale e dalla rete Internet pubblica.

Architettura

Scaricare un file di Visio di questa architettura.

Workflow

Questa architettura è costituita dai componenti seguenti:

• Rete locale. La rete locale rappresenta un singolo data center connesso ad Azure tramite una connessione Di Azure ExpressRoute o una rete privata virtuale (VPN). In questo scenario, i componenti seguenti costituiscono la rete locale:
  • Server DNS. Questi server rappresentano due server con il servizio DNS installato che fungono da resolver/server d'inoltro. Questi server DNS vengono usati per tutti i computer nella rete locale come server DNS. I record devono essere creati in questi server per tutti gli endpoint in Azure e in locale.
  • Gateway. Il gateway rappresenta un dispositivo VPN o una connessione ExpressRoute usata per connettersi ad Azure.
• Sottoscrizione dell'hub. La sottoscrizione hub rappresenta una sottoscrizione di Azure usata per ospitare le risorse di connettività, gestione e rete condivise tra più carichi di lavoro ospitati in Azure. Queste risorse possono essere suddivise in più sottoscrizioni, come descritto nell'architettura su scala aziendale.

  Nota

  La rete virtuale hub può essere sostituita da un hub wan (Wide Area Network) virtuale, nel qual caso i server DNS devono essere ospitati in una rete virtuale di Azure diversa. Nell'architettura su scala aziendale, tale rete virtuale viene mantenuta nella propria sottoscrizione con diritto alla sottoscrizione Identity.

  • Subnet di Azure Bastion. Il servizio Azure Bastion nella rete virtuale hub viene usato per la comunicazione remota alle macchine virtuali nell'hub e nelle reti virtuali spoke dalla rete Internet pubblica a scopo di manutenzione.
  • Subnet dell'endpoint privato. La subnet dell'endpoint privato ospita endpoint privati per i carichi di lavoro ospitati in Azure nelle reti virtuali che non sono sottoposte a peering all'hub. Con questo tipo di rete virtuale disconnessa, i relativi indirizzi IP possono conflitto con altri indirizzi IP usati in Azure e in locale.
  • Subnet del gateway: La subnet del gateway ospita la VPN di Azure o ExpressRoute, gateway usato per fornire la connettività al data center locale.
  • Subnet dei servizi condivisi. La subnet dei servizi condivisi ospita servizi condivisi tra più carichi di lavoro di Azure. In questo scenario, questa subnet ospita macchine virtuali che eseguono Windows o Linux che vengono usate anche come server DNS. Questi server DNS ospitano le stesse zone DNS dei server locali.
• Sottoscrizione connessa. La sottoscrizione connessa rappresenta una raccolta di carichi di lavoro che richiedono una rete virtuale e la connettività alla rete locale.
  • Peering reti virtuali. Questo componente è una connessione di peering alla rete virtuale dell'hub. Questa connessione consente la connettività dalla rete locale allo spoke e vice-rete virtuale dell'hub.
  • Subnet predefinita. La subnet predefinita contiene un carico di lavoro di esempio.
    • web-vmss. Questo set di scalabilità di macchine virtuali di esempio ospita un carico di lavoro in Azure accessibile dall'ambiente locale, da Azure e dalla rete Internet pubblica.
    • Servizio di bilanciamento del carico. Il servizio di bilanciamento del carico fornisce l'accesso a un carico di lavoro che ospita una serie di macchine virtuali. L'indirizzo IP di questo servizio di bilanciamento del carico nella subnet predefinita deve essere usato per accedere al carico di lavoro da Azure e dal data center locale.
  • Subnet AppGateway. Questa subnet è la subnet necessaria per il servizio gateway di app Azure lication.
    • AppGateway. gateway applicazione fornisce l'accesso al carico di lavoro di esempio nella subnet predefinita agli utenti dalla rete Internet pubblica.
    • wkld1-pip. Questo indirizzo è l'indirizzo IP pubblico usato per accedere al carico di lavoro di esempio da Internet pubblico.
• Sottoscrizione disconnessa. La sottoscrizione disconnessa rappresenta una raccolta di carichi di lavoro che non richiedono la connettività al data center locale e che usano il servizio collegamento privato.
  • PLSSubnet. La subnet del servizio di collegamento privato (PLSSubnet) contiene una o più risorse del servizio di collegamento privato che forniscono la connettività ai carichi di lavoro ospitati nella sottoscrizione connessa.
  • Subnet predefinita. La subnet predefinita contiene un carico di lavoro di esempio.
    • web-vmss. Questo set di scalabilità di macchine virtuali di esempio ospita un carico di lavoro in Azure accessibile dall'ambiente locale, da Azure e dalla rete Internet pubblica.
    • Servizio di bilanciamento del carico. Il servizio di bilanciamento del carico fornisce l'accesso a un carico di lavoro che ospita una serie di macchine virtuali. Questo servizio di bilanciamento del carico è connesso al servizio di collegamento privato per fornire l'accesso agli utenti provenienti da Azure e dal data center locale.
  • Subnet AppGateway. Questa subnet è la subnet necessaria per il servizio gateway applicazione.
    • AppGateway. gateway applicazione fornisce l'accesso al carico di lavoro di esempio nella subnet predefinita agli utenti dalla rete Internet pubblica.
    • wkld2-pip. Questo indirizzo è l'indirizzo IP pubblico usato per accedere al carico di lavoro di esempio da Internet pubblico.
  • Subnet di Azure Bastion. Il servizio Azure Bastion nella rete virtuale disconnessa viene usato per la comunicazione remota alle macchine virtuali nell'hub e nelle reti virtuali spoke dalla rete Internet pubblica a scopo di manutenzione.

Componenti

• Rete virtuale. Rete virtuale di Azure (VNet) è il blocco predefinito fondamentale per la rete privata in Azure. VNet consente a diversi tipi di risorse di Azure, ad esempio Macchine virtuali di Azure, di comunicare in modo sicuro tra di esse, con Internet e con le reti locali.

• Azure Bastion. Azure Bastion è un servizio completamente gestito che fornisce accesso RDP (Remote Desktop Protocol) e SSH (Secure Shell Protocol) più sicuro e semplice alle macchine virtuali senza esposizione tramite indirizzi IP pubblici.

• Gateway VPN Gateway VPN invia traffico crittografato tra una rete virtuale di Azure e una posizione locale tramite Internet pubblico. È possibile usare Gateway VPN anche per inviare traffico crittografato tra le reti virtuali di Azure sulla rete Microsoft. Un gateway VPN è un tipo specifico di gateway di rete virtuale.

• Collegamento privato. Un collegamento privato di Azure offre connettività privata da una rete virtuale a servizi PaaS (Platform-as-a-Service) di Azure, di proprietà del cliente o del partner Microsoft. Semplifica l'architettura di rete e protegge la connessione tra endpoint in Azure eliminando l'esposizione dei dati alla rete Internet pubblica.

• Gateway applicazione. Il gateway applicazione di Azure è un servizio di bilanciamento del carico del traffico Web che consente di gestire il traffico verso le applicazioni Web. I servizi di bilanciamento del carico tradizionali operano a livello di trasporto (OSI livello 4 - TCP e UDP) ed eseguono il routing del traffico da un indirizzo IP e una porta di origine verso un indirizzo IP e una porta di destinazione.

Consigli

Le raccomandazioni seguenti sono valide per la maggior parte degli scenari. Seguire queste indicazioni, a meno che non si disponga di un requisito specifico che le escluda.

Estendere Active Directory Domain Services ad Azure (facoltativo)

Usare zone DNS integrate in Servizi di dominio Active Directory per ospitare i record DNS per il data center locale e Azure. In questo scenario sono disponibili due set di server DNS di Active Directory Domain Services: uno locale e uno nella rete virtuale dell'hub.

È consigliabile estendere il dominio di Active Directory Domain Services ad Azure. È anche consigliabile configurare le reti virtuali hub-spoke per usare i server DNS di Active Directory Domain Services nella rete virtuale dell'hub per tutte le macchine virtuali in Azure.

Configurare il DNS split-brain

Assicurarsi che il DNS split brain sia attivo per consentire ai sistemi di Azure, agli utenti locali e agli utenti Internet di accedere ai carichi di lavoro in base alla posizione da cui si connettono.

Per i carichi di lavoro connessi e disconnessi, è consigliabile usare i componenti seguenti per la risoluzione DNS:

• Zone DNS di Azure per gli utenti Internet.
• Server DNS per utenti locali e sistemi di Azure.
• Zone DNS private di Azure per la risoluzione tra reti virtuali di Azure.

Per comprendere meglio questa raccomandazione split-brain, prendere in considerazione Il carico di lavoro 1, per il quale si userà il nome di dominio completo (FQDN) wkld1.contoso.com .

In questo scenario, gli utenti Internet devono risolvere il nome nell'indirizzo IP pubblico che gateway applicazione espone tramite Wkld1-pip. Questa risoluzione viene eseguita creando un record di indirizzi (record A) in DNS di Azure per la sottoscrizione connessa.

Gli utenti locali devono risolvere lo stesso nome nell'indirizzo IP interno per il servizio di bilanciamento del carico nella sottoscrizione connessa. Questa risoluzione viene eseguita creando un record A nei server DNS nella sottoscrizione dell'hub.

I sistemi di Azure possono risolvere lo stesso nome in un indirizzo IP interno per il servizio di bilanciamento del carico nella sottoscrizione connessa creando un record A nel server DNS nella sottoscrizione hub o usando zone DNS private. Quando si usano zone DNS private, creare manualmente un record A nella zona DNS privata o abilitare la registrazione automatica.

Usare zone DNS private per un collegamento privato

Nello scenario, il carico di lavoro 2 è ospitato in una sottoscrizione disconnessa e l'accesso a questo carico di lavoro per gli utenti locali e i sistemi di Azure connessi è possibile tramite un endpoint privato nella rete virtuale dell'hub. Tuttavia, esiste una terza possibilità di connessione per questo carico di lavoro: sistemi di Azure nella stessa rete virtuale del carico di lavoro 2.

Per comprendere meglio le raccomandazioni DNS per il carico di lavoro 2, si userà il nome di dominio completo wkld2.contoso.com e si esamineranno le singole raccomandazioni.

In questo scenario, gli utenti Internet devono risolvere il nome nell'indirizzo IP pubblico che gateway applicazione espone tramite Wkld2-pip. Questa risoluzione viene eseguita creando un record A in DNS di Azure per la sottoscrizione connessa.

Gli utenti locali e i sistemi di Azure connessi alla rete virtuale dell'hub e alle reti virtuali spoke devono risolvere lo stesso nome nell'indirizzo IP interno per l'endpoint privato nella rete virtuale dell'hub. Questa risoluzione viene eseguita creando un record A nei server DNS nella sottoscrizione dell'hub.

I sistemi di Azure nella stessa rete virtuale del carico di lavoro 2 devono risolvere il nome nell'indirizzo IP del servizio di bilanciamento del carico nella sottoscrizione disconnessa. Questa risoluzione viene eseguita usando una zona DNS privata in DNS di Azure in tale sottoscrizione.

I sistemi di Azure in reti virtuali diverse possono comunque risolvere l'indirizzo IP del carico di lavoro 2 se si collegano le reti virtuali con la zona DNS privata che ospita il record A per il carico di lavoro 2.

Abilitare la registrazione automatica

Quando si configura un collegamento di rete virtuale con una zona DNS privata, è possibile configurare facoltativamente la registrazione automatica della registrazione automatica per tutte le macchine virtuali.

Se si usa il server DNS di Active Directory Domain Services, configurare le macchine virtuali Windows può usare gli aggiornamenti dinamici per i computer Windows per mantenere aggiornati i propri record DNS nei server DNS di Active Directory Domain Services. È consigliabile abilitare gli aggiornamenti dinamici e configurare i server DNS per consentire solo gli aggiornamenti sicuri.

Le macchine virtuali Linux non supportano aggiornamenti dinamici sicuri. Per i computer Linux locali, usare Dynamic Host Configuration Protocol (DHCP) per registrare i record DNS nei server DNS di Active Directory Domain Services.

Per le macchine virtuali Linux in Azure, usare un processo automatizzato.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Scalabilità

• Per area di Azure o data center locali, è consigliabile usare almeno due server DNS ciascuno.
• Si noti come questa operazione viene eseguita nello scenario precedente, con i server DNS in locale e nella rete virtuale hub.

Disponibilità

• Prendere in considerazione il posizionamento dei server DNS. Come descritto nella sezione Considerazioni sulla scalabilità, i server DNS devono essere posizionati vicino agli utenti e ai sistemi che devono accedervi.
  • Per area di Azure. Ogni area di Azure ha una propria rete virtuale hub o un hub vWAN. È qui che devono essere distribuiti i server DNS.
  • Per data center locale. È anche necessario avere una coppia di server DNS per ogni data center locale per utenti e sistemi in tali posizioni.
  • Per i carichi di lavoro isolati (disconnessi), ospitare una zona DNS privata e una zona DNS pubblica per ogni sottoscrizione per gestire i record DNS split brain.

Gestione

• Prendere in considerazione la necessità di record DNS per i servizi PaaS (Platform as a Service).
• È anche necessario prendere in considerazione la risoluzione DNS per i servizi PaaS che usano un endpoint privato. Usare una zona DNS privata per tale oggetto e usare la pipeline DevOps per creare record nei server DNS.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

• Se è necessario l'uso di DNSSEC, tenere presente che DNS di Azure attualmente non lo supporta.
• Per la convalida DNSSEC, distribuire un server DNS personalizzato e abilitare la convalida DNSEC.
• Protezione DDoS di Azure, in combinazione con le procedure consigliate per la progettazione di applicazioni, offre funzionalità avanzate di mitigazione DDoS per difendersi meglio dagli attacchi DDoS. È consigliabile abilitare Protezione DDOS di Azure in qualsiasi rete virtuale perimetrale.

DevOps

• Automatizzare la configurazione di questa architettura combinando i modelli di Azure Resource Manager per la configurazione di tutte le risorse. Sia le zone DNS private che pubbliche supportano la gestione completa dall'interfaccia della riga di comando di Azure, Da PowerShell, da .NET e dall'API REST.
• Se si usa una pipeline di integrazione continua e sviluppo continuo (CI/CD) per distribuire e gestire i carichi di lavoro in Azure e in locale, è anche possibile configurare la registrazione automatica dei record DNS.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

• I costi della zona DNS di Azure si basano sul numero di zone DNS ospitate in Azure e sul numero di query DNS ricevute.
• Usare il calcolatore dei prezzi di Azure per stimare i costi. I modelli di determinazione dei prezzi per DNS di Azure sono illustrati qui.
• Il modello di fatturazione per Azure ExpressRoute si basa sui dati a consumo, che vengono addebitati per gigabyte per il trasferimento dei dati in uscita o dati illimitati, che addebita una tariffa mensile, incluso tutto il trasferimento dei dati.
• Se si usa la VPN, invece di ExpressRoute, il costo dipende dallo SKU del gateway di rete virtuale e viene addebitato all'ora.

Passaggi successivi

Altre informazioni sulle tecnologie dei componenti:

• Che cos'è DNS di Azure?
• Che cos'è Rete virtuale di Azure?
• Che cos'è Azure ExpressRoute?
• Che cos'è Azure Bastion?

Risorse correlate

Esplorare le architetture correlate:

• Condivisione file del cloud aziendale di Azure
• Applicazione a più livelli con Apache Cassandra
• SaaS multitenant in Azure