Best practice per Cloud DNS

Questo documento fornisce le best practice per le zone private, il forwarding DNS e le architetture di riferimento per il DNS ibrido.

Per persone e applicazioni, utilizzare il DNS (Domain Name System) per fare riferimento ad applicazioni e servizi è più semplice, perché un nome è più facile da ricordare e più flessibile rispetto all'utilizzo di indirizzi IP. In un ambiente ibrido composto da una o più piattaforme cloud e on-premise, spesso è necessario accedere ai record DNS per le risorse interne in tutti gli ambienti. Tradizionalmente, i record DNS on-premise vengono amministrati manualmente utilizzando un server DNS autorevole, ad esempio BIND negli ambienti UNIX/Linux o Active Directory negli ambienti Microsoft Windows.

Questo documento descrive le best practice per il forwarding delle richieste DNS private tra ambienti per assicurarsi che i servizi possano essere raggiunti sia dagli ambienti on-premise, sia all'interno di Google Cloud.

Principi generali

Scopri di più sui concetti relativi al DNS su Google Cloud

Quando utilizzi il DNS su Google Cloud, è importante comprendere i diversi sistemi e servizi disponibili in Google Cloud per la risoluzione DNS e i nomi di dominio:

• Il DNS interno è un servizio che crea automaticamente nomi DNS per macchine virtuali e bilanciatori del carico interni su Compute Engine.
• Cloud DNS è un servizio che fornisce una gestione delle zone DNS a bassa latenza e ad alta affidabilità. Può fungere da server DNS autorevole per le zone pubbliche visibili su internet o per le zone private visibili solo all'interno della tua rete.
• Microsoft Active Directory gestito è un servizio protetto e ad alta affidabilità che esegue Microsoft Active Directory, incluso un domain controller.
• Public DNS è un servizio Google che non fa parte di Google Cloud che funge da resolver DNS ricorsivo aperto.
• Cloud Domains è un registrar di domini per l'acquisto, il trasferimento e la gestione dei domini all'interno di Google Cloud. Cloud Domains ti consente di interagire con il sistema di registrazione dei domini tramite un'API.

Identifica stakeholder, strumenti e processi

Quando pensi di creare una strategia per il DNS in un ambiente ibrido, è importante acquisire familiarità con l'architettura attuale e contattare tutti gli stakeholder. Segui questi passaggi:

• Identifica e contatta l'amministratore dei server DNS aziendali della tua organizzazione. Chiedi informazioni sulle configurazioni necessarie per mappare la configurazione on-premise a un'architettura adatta su Google Cloud. Per informazioni sui metodi di accesso ai record DNSGoogle Cloud , consulta Utilizza il forwarding condizionale per accedere ai record DNS da on-premise.
• Acquisisci familiarità con il software DNS attuale e identifica i nomi di dominio utilizzati privatamente all'interno della tua organizzazione.
• Identifica i contatti del team di networking che possono assicurarsi che il traffico verso i server Cloud DNS venga instradato correttamente.
• Acquisisci familiarità con la tua strategia di connettività ibrida e con i modelli e le procedure per ambienti ibridi e multi-cloud.

Crea uno standard di denominazione coerente

Crea uno standard di denominazione coerente in tutta l'organizzazione. Ad esempio, supponiamo che la tua organizzazione utilizzi example.com come nome di dominio di secondo livello e dominio per le risorse pubbliche (ad esempio www.example.com). La posizione in cui sono ospitate le zone pubbliche è irrilevante ai fini di questo documento perché l'ambito è la migrazione delle zone private.

Per la denominazione delle risorse aziendali on-premise, puoi scegliere tra i seguenti modelli:

• Puoi utilizzare nomi di dominio diversi per i server on-premise e per Google Cloud. Questo modello utilizza un dominio separato per i diversi ambienti, ad esempio, corp.example.com per i server on-premise e gcp.example.com per tutte le risorse su Google Cloud. Se utilizzi altri ambienti cloud pubblici, ognuno può avere un sottodominio separato. Questo è il modello preferibile, perché consente di inoltrare le richieste tra gli ambienti.

  Puoi anche utilizzare nomi di dominio separati come example.com e example.cloud.

• Puoi utilizzare il dominio Google Cloud come sottodominio del dominio che contiene server on-premise. Utilizzando il dominio example.com, on-premise potrebbe utilizzare corp.example.com e Google Cloud potrebbe utilizzare gcp.corp.example.com. Questo è un modello comune quando la maggior parte delle risorse rimane on-premise.

• Puoi utilizzare il dominio on-premise come sottodominio del dominio che contiene recordGoogle Cloud . Utilizzando il dominio example.com, Google Cloud potrebbe utilizzare corp.example.com e il dominio on-premise potrebbe utilizzare dc.corp.example.com. Si tratta di un modello insolito, ma potrebbe essere utile per le organizzazioni digitali che hanno poche risorse on-premise.

• Puoi utilizzare lo stesso dominio per Google Cloud e per l'ambiente on-premise. In questo caso, sia Google Cloud che l'ambiente on-premise utilizzano risorse che utilizzano il dominio corp.example.com. Evita questo modello, perché rende molto più difficile la gestione dei record in un ambiente ibrido; è possibile solo quando utilizzi un unico sistema DNS autorevole.

Nel resto di questa pagina vengono utilizzati i seguenti nomi di dominio:

• example.com come nome di dominio per i tuoi documenti pubblici, indipendentemente da dove sono ospitati.
• corp.example.com come zona ospitata dal tuo server DNS on-premise. Questa zona ospita i record delle tue risorse on-premise.
• gcp.example.com come zona Cloud DNS privata gestita che ospita i record per le tue risorse Google Cloud .

La Figura 1 mostra una configurazione del nome di dominio coerente sia nella tua rete on-premise, sia in Google Cloud.

Figura 1. La configurazione del nome di dominio è coerente in tutta l'organizzazione.

Per assegnare il nome alle risorse all'interno della rete VPC (Virtual Private Cloud), puoi seguire linee guida come quelle nella guida alle soluzioni Best practice e architetture di riferimento per la progettazione di VPC.

Scegli dove eseguire la risoluzione DNS

In un ambiente ibrido, la risoluzione DNS può essere eseguita in diverse posizioni. Puoi:

• Utilizzare un approccio ibrido con due sistemi DNS autorevoli.
• Mantenere la risoluzione DNS on-premise.
• Spostare tutta la risoluzione DNS su Cloud DNS.

Ti consigliamo l'approccio ibrido, pertanto questo documento si concentra su questo approccio. Tuttavia, per completezza, questo documento descrive brevemente gli approcci alternativi.

Utilizza un approccio ibrido con due sistemi DNS autorevoli

Ti consigliamo di utilizzare un approccio ibrido con due sistemi DNS autorevoli. Con questo approccio:

• La risoluzione DNS autorevole per il tuo ambiente Google Cloud privato viene eseguita da Cloud DNS.
• La risoluzione DNS autorevole per le risorse on-premise è ospitata dai server DNS on-premise esistenti.

La Figura 2 mostra questa configurazione.

Figura 2. Un'architettura DNS ibrida che utilizza sia Cloud DNS che server DNS on-premise fornisce una risoluzione DNS autorevole.

Lo scenario mostrato nella figura 2 è il caso d'uso preferito. Più avanti in questa pagina sono trattati i seguenti dettagli:

• Come configurare il forwarding tra ambienti utilizzando zone private e forwarding DNS.
• Come configurare firewall e routing.
• Architetture di riferimento che mostrano come utilizzare una o più reti VPC.

Mantieni la risoluzione DNS on-premise

Un approccio alternativo consiste nel continuare a utilizzare il server DNS on-premise esistente per ospitare in modo autorevole tutti i nomi di dominio interni. In questo caso, puoi utilizzare un server dei nomi alternativo per inoltrare tutte le richieste daGoogle Cloud tramite il forwarding DNS in uscita.

Questo approccio presenta i seguenti vantaggi:

• Devi apportare meno modifiche ai processi aziendali.
• Puoi continuare a utilizzare gli strumenti esistenti.
• Puoi utilizzare elenchi degli elementi non consentiti per filtrare le singole richieste DNS on-premise.

Tuttavia, presenta i seguenti svantaggi:

• Le richieste DNS provenienti da Google Cloud hanno una latenza maggiore.
• Il tuo sistema si basa sulla connettività agli ambienti on-premise per le operazioni DNS.
• Potresti avere difficoltà a integrare ambienti altamente flessibili come i gruppi di istanze con scalabilità automatica.
• Il sistema potrebbe non essere compatibile con prodotti come Dataproc, perché questi prodotti si basano sulla risoluzione inversa dei nomi delle istanze Google Cloud.

Sposta tutta la risoluzione DNS su Cloud DNS

Un altro approccio consiste nell'eseguire la migrazione a Cloud DNS come servizio autorevole per la risoluzione di tutti i domini. Potrai quindi utilizzare le zone private e il forwarding DNS in entrata per eseguire la migrazione della risoluzione dei nomi on-premise esistente a Cloud DNS.

Questo approccio presenta i seguenti vantaggi:

• Non è necessario gestire un servizio DNS ad alta affidabilità on-premise.
• Il tuo sistema può utilizzare Cloud DNS per sfruttare il logging e il monitoraggio centralizzati.

Tuttavia, presenta i seguenti svantaggi:

• Le richieste DNS on-premise hanno una latenza più elevata.
• Il tuo sistema deve avere una connessione affidabile alla rete VPC per la risoluzione dei nomi.

Best practice per le zone private di Cloud DNS

Le zone private ospitano record DNS visibili solo all'interno della tua organizzazione. Le zone pubbliche su Cloud DNS non sono trattate in questo documento. Le zone pubbliche coprono i record pubblici dell'organizzazione, come i record DNS per il sito web pubblico, e non sono così pertinenti in una configurazione ibrida.

Utilizza l'automazione per gestire le zone private nel progetto host del VPC condiviso

Se utilizzi reti VPC condivise all'interno della tua organizzazione, devi ospitare tutte le zone private su Cloud DNS all'interno del progetto host. Tutti i progetti di servizio possono accedere automaticamente ai record nelle zone private collegate alla rete VPC condivisa. In alternativa, puoi configurare la zona in un progetto di servizio utilizzando l'associazione tra progetti.

La figura 3 mostra come vengono ospitate le zone private in una rete VPC condivisa.

Figura 3. Questa configurazione mostra come le zone private sono collegate a una rete VPC condivisa.

Se vuoi che i team configurino i propri record DNS, ti consigliamo di automatizzare la creazione dei record DNS. Ad esempio, puoi creare un'applicazione web o un'API interna in cui gli utenti configurano i propri record DNS in sottodomini specifici. L'app verifica che i record siano conformi alle regole della tua organizzazione.

In alternativa, puoi inserire la configurazione DNS in un repository di codice come Cloud Source Repositories sotto forma di descrittori Terraform o Cloud Deployment Manager e accettare le richieste di pull dai team.

In entrambi i casi, un service account con il ruolo IAM DNS Administrator nel progetto host può eseguire automaticamente il deployment delle modifiche dopo l'approvazione.

Imposta i ruoli IAM utilizzando il principio del privilegio minimo

Utilizza il principio di sicurezza del privilegio minimo per concedere il diritto di modificare i record DNS solo alle persone della tua organizzazione che devono svolgere questa attività. Evita di utilizzare i ruoli di base, perché potrebbero consentire l'accesso ad altre risorse oltre a quelle necessarie per l'utente. Cloud DNS offre ruoli e autorizzazioni che ti consentono di concedere l'accesso in lettura e scrittura specifico per il DNS.

Se è importante separare la possibilità di creare zone DNS private dalla possibilità di creare zone pubbliche, utilizza l'autorizzazione dns.networks.bindPrivateDNSZone.

Best practice per le zone di forwarding DNS e le policy dei server

Cloud DNS offre zone di forwarding DNS e policy dei server DNS per consentire le ricerche di nomi DNS tra l'ambiente on-premise e quello Google Cloud . Hai diverse opzioni per configurare il forwarding DNS. La sezione seguente elenca le best practice per la configurazione del DNS ibrido. Queste best practice sono illustrate in Architetture di riferimento per DNS in un ambiente ibrido.

Nota: il forwarding DNS non può essere utilizzato per il forwarding tra ambienti Google Cloud diversi, indipendentemente dal modo in cui sono interconnessi. Per questo caso d'uso, utilizza il peering DNS.

Utilizza le zone di forwarding per fare query sui server on-premise

Per assicurarti di poter fare query sui record DNS nel tuo ambiente on-premise, configura una zona di forwarding per il dominio che utilizzi on-premise per le risorse aziendali (ad esempio corp.example.com). Questo approccio è preferibile all'utilizzo di una policy DNS che abilita un server dei nomi alternativo. Consente di mantenere l'accesso ai nomi DNS interni di Compute Engine e gli indirizzi IP esterni vengono comunque risolti senza bisogno di un hop aggiuntivo tramite un server dei nomi on-premise.

Il flusso di traffico che utilizza questa configurazione è mostrato in Architetture di riferimento per DNS in un ambiente ibrido.

Utilizza server dei nomi alternativi solo se tutto il traffico DNS deve essere monitorato o filtrato on-premise e se il logging DNS per le zone private non soddisfa i tuoi requisiti.

Nota: Cloud DNS non si sincronizza automaticamente con i server dei nomi on-premise. I server dei nomi on-premise devono essere disponibili per rispondere alle query inoltrate in uscita. Come descritto in Zone di forwarding DNS, Cloud DNS memorizza nella cache i risultati delle query inoltrate in uscita per un massimo di 60 secondi o per la durata del TTL. Google Cloud non sincronizza né memorizza nella cache i record on-premise; le richieste vengono inoltrate man mano che arrivano. Pertanto, è fondamentale che i server DNS on-premise siano disponibili e raggiungibili in modo che i domini on-premise possano essere risolti.

Utilizza le policy dei server DNS per consentire query da on-premise

Per consentire agli host on-premise di fare query sui record DNS ospitati nelle zone private di Cloud DNS (ad esempio gcp.example.com), crea una policy dei server DNS utilizzando il forwarding DNS in entrata. Il forwarding DNS in entrata consente al sistema di fare query su tutte le zone private del progetto, nonché sugli indirizzi IP DNS interni e sulle zone in peering.

Il flusso di traffico che utilizza questa configurazione è mostrato in Architetture di riferimento per DNS in un ambiente ibrido.

Apri i firewall on-premise e Google Cloud per consentire il traffico DNS

Assicurati che il traffico DNS non venga filtrato in alcun punto all'interno della rete VPC o dell'ambiente on-premise procedendo come segue:

• Assicurati che il firewall on-premise passi le query provenienti da Cloud DNS. Cloud DNS invia query dall'intervallo di indirizzi IP 35.199.192.0/19. Il DNS utilizza la porta UDP 53 o la porta TCP 53, a seconda della dimensione della richiesta o della risposta.

• Assicurati che il server DNS non blocchi le query. Se il tuo server DNS on-premise accetta richieste solo da indirizzi IP specifici, assicurati che sia incluso l'intervallo di indirizzi IP 35.199.192.0/19.

• Assicurati che il traffico possa fluire dall'ambiente on-premise agli indirizzi IP di forwarding. Nelle istanze del router Cloud, aggiungi una route annunciata personalizzata per l'intervallo di indirizzi IP 35.199.192.0/19 nella tua rete VPC all'ambiente on-premise.

Utilizza il forwarding condizionale per accedere ai record DNS da on-premise

Con Cloud DNS, per accedere ai record privati ospitati sui server DNS aziendali on-premise puoi utilizzare solo le zone di forwarding. Tuttavia, a seconda del software del server DNS che utilizzi, potresti avere più opzioni per accedere ai record DNS in Google Cloud da on-premise. In ogni caso, l'accesso ai record avviene tramite il forwarding DNS in entrata:

• Forwarding condizionale. Usare il forwarding condizionale significa che il server DNS aziendale inoltra le richieste per zone o sottodomini specifici agli indirizzi IP di forwarding su Google Cloud. Consigliamo questo approccio perché è il meno complesso e ti consente di monitorare centralmente tutte le richieste DNS sui server DNS aziendali.

• Delega. Se la tua zona privata su Google Cloud è un sottodominio della zona che utilizzi on-premise, puoi anche delegare questo sottodominio al server dei nomiGoogle Cloud impostando voci NS all'interno della zona. Quando utilizzi questa configurazione, i client possono comunicare con gli indirizzi IP di forwarding su Google Cloud direttamente, quindi assicurati che il firewall passi queste richieste.

• Trasferimenti di zone. Cloud DNS non supporta i trasferimenti delle zone, pertanto non puoi utilizzarli per sincronizzare i record DNS con i tuoi server DNS on-premise.

Utilizza il peering DNS per evitare il forwarding in uscita da più reti VPC

Non utilizzare il forwarding in uscita verso i server DNS on-premise da più reti VPC, perché questo crea problemi con il traffico di ritorno. Google Cloud accetta le risposte dai server DNS solo se vengono instradate alla rete VPC da cui ha avuto origine la query. Tuttavia, le query provenienti da qualsiasi rete VPC hanno come origine lo stesso intervallo di indirizzi IP 35.199.192.0/19. Pertanto, le risposte non possono essere instradate correttamente a meno che tu non disponga di ambienti on-premise separati.

Figura 4. Problema con più reti VPC che eseguono il forwarding in uscita.

Ti consigliamo di designare una singola rete VPC per fare query sui server dei nomi on-premise utilizzando il forwarding in uscita. Altre reti VPC potranno così fare query sui server dei nomi on-premise scegliendo come target la rete VPC designata con una zona di peering DNS. Le query verrebbero quindi inoltrate ai server dei nomi on-premise in base all'ordine di risoluzione dei nomi della rete VPC designata. Questa configurazione è illustrata in Architetture di riferimento per DNS in un ambiente ibrido.

Differenza tra il peering DNS e il peering di rete VPC

Il peering di rete VPC non è uguale al peering DNS. Il peering di rete VPC consente alle istanze di macchine virtuali (VM) in più progetti di raggiungersi a vicenda, ma non modifica la risoluzione dei nomi. Le risorse in ogni rete VPC continuano a seguire il proprio ordine di risoluzione.

Al contrario, tramite il peering DNS, puoi consentire il forwarding delle richieste per zone specifiche a un'altra rete VPC. In questo modo puoi inoltrare le richieste a diversi ambienti Google Cloud , indipendentemente dal fatto che le reti VPC siano interconnesse.

Il peering di rete VPC e il peering DNS si configurano anche in modo diverso. Per il peering di rete VPC, entrambe le reti VPC devono configurare una relazione di peering con l'altra rete VPC. Il peering diventa automaticamente bidirezionale.

Il peering DNS inoltra le richieste DNS in modo unidirezionale e non richiede una relazione bidirezionale tra le reti VPC. Una rete VPC denominata rete consumer DNS esegue ricerche per una zona di peering DNS di Cloud DNS in un'altra rete VPC, denominata rete producer DNS. Gli utenti con l'autorizzazione IAM dns.networks.targetWithPeeringZone sul progetto della rete del producer possono stabilire il peering DNS tra le reti consumer e producer. Per configurare il peering DNS da una rete VPC consumer, devi disporre del ruolo DNS Peer per il progetto host della rete VPC producer.

Se utilizzi nomi generati automaticamente, utilizza il peering DNS per le zone interne

Se utilizzi i nomi generati automaticamente per le VM create dal servizio DNS interno, puoi utilizzare il peering DNS per inoltrare le zone projectname.internal ad altri progetti. Come mostrato nella figura 5, puoi raggruppare tutte le zone .internal in un progetto hub per renderle accessibili dalla tua rete on-premise.

Figura 5. Il peering DNS viene utilizzato per organizzare tutte le zone .internal in un hub.

In caso di difficoltà, segui la guida alla risoluzione dei problemi

La guida alla risoluzione dei problemi di Cloud DNS fornisce istruzioni per risolvere gli errori comuni che potresti riscontrare durante la configurazione di Cloud DNS.

Architetture di riferimento per DNS in un ambiente ibrido

Questa sezione illustra alcune architetture di riferimento per gli scenari comuni che utilizzano le zone private di Cloud DNS in un ambiente ibrido. In ogni caso, sia le risorse on-premise, sia le zone e i record di risorse Google Cloud vengono gestiti all'interno dell'ambiente. Tutti i record sono disponibili per l'esecuzione di query sia dagli host on-premise, sia da quelli Google Cloud .

Utilizza l'architettura di riferimento che corrisponde al progetto della tua rete VPC:

• Architettura ibrida con un'unica rete VPC condivisa: utilizza una singola rete VPC connessa a o da ambienti on-premise.

• Architettura ibrida con più reti VPC separate: connette più reti VPC agli ambienti on-premise tramite diversi tunnel VPN o collegamenti VLAN e condivide la stessa infrastruttura DNS on-premise.

• Architettura ibrida con una rete VPC hub connessa a reti VPC spoke: utilizza il peering di rete VPC per avere una rete VPC hub connessa a più reti VPC spoke indipendenti.

In ogni caso, l'ambiente on-premise è connesso alle reti VPC Google Cloud da uno o più tunnel Cloud VPN o connessioni Dedicated Interconnect o Partner Interconnect. Il metodo di connessione utilizzato per ogni rete VPC è irrilevante.

Architettura ibrida con un'unica rete VPC condivisa

Il caso d'uso più comune è una singola rete VPC condivisa connessa all'ambiente on-premise, come mostrato nella figura 6.

Figura 6. Un'architettura ibrida utilizza una singola rete VPC condivisa per connettersi a una rete on-premise.

Per configurare questa architettura:

1. Configura i tuoi server DNS on-premise come autorevoli per corp.example.com.
2. Configura una zona privata autorevole (ad esempio gcp.example.com) su Cloud DNS nel progetto host della rete VPC condivisa e configura tutti i record per le risorse in quella zona.
3. Imposta una policy dei server DNS sul progetto host per la rete VPC condivisa in modo da consentire il forwarding DNS in entrata.
4. Imposta una zona di forwarding DNS che inoltri corp.example.com ai server DNS on-premise. La rete VPC condivisa deve essere autorizzata a fare query sulla zona di forwarding.
5. Configura il forwarding a gcp.example.com sui tuoi server DNS on-premise, puntando a un indirizzo IP dell'agente di inoltro in entrata nella rete VPC condivisa.
6. Assicurati che il traffico DNS sia consentito sul firewall on-premise.
7. Nelle istanze del router Cloud, aggiungi una route annunciata personalizzata per l'intervallo 35.199.192.0/19 all'ambiente on-premise.

Architettura ibrida con più reti VPC separate

Un'altra opzione per le architetture ibride è usare più reti VPC separate. Queste reti VPC nel tuo ambienteGoogle Cloud non sono connesse tra loro tramite il peering di rete VPC. Tutte le reti VPC utilizzano tunnel Cloud VPN separati o collegamenti VLAN per connettersi ai tuoi ambienti on-premise.

Come mostrato nella figura 7, un caso d'uso tipico per questa architettura è quando esistono ambienti di produzione e sviluppo separati che non comunicano tra loro, ma condividono i server DNS.

Figura 7. Un'architettura ibrida può utilizzare più reti VPC separate.

Per configurare questa architettura:

1. Configura i tuoi server DNS on-premise come autorevoli per corp.example.com.
2. Configura una zona privata (ad esempio prod.gcp.example.com) su Cloud DNS nel progetto host della rete VPC condivisa di produzione e configura tutti i record per le risorse in quella zona.
3. Configura una zona privata (ad esempio dev.gcp.example.com) su Cloud DNS nel progetto host della rete VPC condivisa di sviluppo e configura tutti i record per le risorse in quella zona.
4. Imposta una policy dei server DNS sul progetto host per la rete VPC condivisa di produzione e consenti il forwarding DNS in entrata.
5. Nella rete VPC condivisa di produzione, imposta una zona DNS per inoltrare corp.example.com ai server DNS on-premise.
6. Imposta una zona di peering DNS dalla rete VPC condivisa di sviluppo alla rete VPC condivisa di produzione per prod.gcp.example.com.
7. Imposta una zona di peering DNS dalla rete VPC condivisa di produzione alla rete VPC condivisa di sviluppo per dev.gcp.example.com.
8. Configura il forwarding in entrata delegando la risoluzione di gcp.example.com. agli indirizzi IP virtuali di forwarding in entrata di Cloud DNS sui tuoi server dei nomi on-premise.
9. Assicurati che il firewall consenta il traffico DNS sia sui firewall on-premise sia su quelli Google Cloud .
10. Nelle istanze del router Cloud, aggiungi una route annunciata personalizzata per l'intervallo di indirizzi IP 35.199.192.0/19 nella rete VPC condivisa di produzione all'ambiente on-premise.

Architettura ibrida con una rete VPC hub connessa a reti VPC spoke

Un'altra opzione è utilizzare Cloud Interconnect o Cloud VPN per connettere l'infrastruttura on-premise a una rete VPC hub. Come mostrato nella figura 8, puoi utilizzare il peering di rete VPC per eseguire il peering di una rete VPC con diverse reti VPC spoke. Ogni rete VPC spoke ospita le sue zone private su Cloud DNS. Le route personalizzate sul peering di rete VPC, insieme all'annuncio delle route personalizzate sul router Cloud, consentono lo scambio completo di route e la connettività tra l'ambiente on-premise e tutte le reti VPC spoke. Il peering DNS viene eseguito in parallelo con le connessioni di peering di rete VPC per consentire la risoluzione dei nomi tra gli ambienti.

Il seguente diagramma mostra questa architettura.

Figura 8. Un'architettura ibrida può utilizzare una rete VPC hub connessa alle reti VPC spoke.

Per configurare questa architettura:

1. Configura i tuoi server DNS on-premise come autorevoli per corp.example.com.
2. Configura una zona privata (ad esempio projectX.gcp.example.com) su Cloud DNS per ogni rete VPC spoke e configura tutti i record per le risorse in quella zona.
3. Imposta una policy dei server DNS sul progetto hub per la rete VPC condivisa di produzione per consentire il forwarding DNS in entrata.
4. Nella rete VPC hub, crea una zona DNS privata per corp.example.com e configura il forwarding in uscita ai server DNS on-premise.
5. Imposta una zona di peering DNS dalla rete VPC hub a ogni rete VPC spoke per projectX.gcp.example.com.
6. Imposta una zona di peering DNS da ogni rete VPC spoke alla rete VPC hub per example.com.
7. Configura il forwarding a gcp.example.com sui tuoi server DNS on-premise in modo che puntino a un indirizzo IP dell'agente di inoltro in entrata nella rete VPC hub.
8. Assicurati che il firewall consenta il traffico DNS sia sui firewall on-premise sia su quelli Google Cloud .
9. Nelle istanze del router Cloud, aggiungi una route annunciata personalizzata per l'intervallo di indirizzi IP 35.199.192.0/19 nella rete VPC hub all'ambiente on-premise.
10. (Facoltativo) Se utilizzi anche i nomi DNS interni generati automaticamente, esegui il peering di ogni zona del progetto spoke (ad esempio spoke-project-x.internal) con il progetto hub e inoltra tutte le query per .internal da on-premise.

Nota: quando utilizzi Cloud VPN anziché il peering di rete VPC tra gli ambientiGoogle Cloud con questa architettura, assicurati che nel progetto hub sia presente una VM o un tunnel VPN in ogni regione utilizzata nei progetti spoke. In questo modo, tutte le VM possono fare query sui record tramite il peering DNS.

DNS pubblico multi-provider con Cloud DNS

Trattandosi di un componente fondamentale per il networking delle applicazioni, un DNS affidabile è essenziale per garantire che le tue applicazioni o i tuoi servizi siano disponibili per gli utenti. Puoi migliorare la disponibilità e la resilienza delle tue applicazioni e dei tuoi servizi configurando più provider DNS. Quando sono configurati più provider DNS, la tua applicazione o il tuo servizio può essere disponibile per gli utenti anche in caso di interruzione di uno dei provider DNS. Con una configurazione DNS multi-provider puoi anche semplificare il deployment e la migrazione delle applicazioni ibride con dipendenze tra ambienti on-premise e cloud.

Google Cloud offre una soluzione open source basata su octoDNS per aiutarti a configurare e gestire un ambiente con più provider DNS. La soluzione DNS multi-provider sfrutta Cloud DNS come uno dei tuoi provider DNS in una configurazione attiva/attiva (consigliata) o attiva/passiva per garantire un'architettura DNS ad alta affidabilità. Dopo aver eseguito il deployment della soluzione, octoDNS esegue una sincronizzazione una tantum e continua tra le zone DNS attuali e le zone DNS gestite ospitate in Cloud DNS. Quando i singoli record DNS vengono aggiornati, le modifiche vengono propagate alle zone DNS corrispondenti ospitate in Cloud DNS senza bisogno di apportare modifiche alle pipeline CI/CD.

Importante: per ottenere una configurazione attiva-attiva e l'affidabilità, devi aggiornare i record NS presso il tuo registrar in modo da includere i server dei nomi Cloud DNS.

• Per configurare Cloud DNS in una configurazione DNS pubblico multi-provider, consulta multi-provider-dns-with-clouddns.

Passaggi successivi

• Per trovare soluzioni ai problemi comuni che potresti riscontrare durante l'utilizzo di Cloud DNS, consulta la pagina Risoluzione dei problemi.
• Per trovare indicazioni su come realizzare e implementare una configurazione ibrida che utilizza Google Cloud, consulta la guida alle soluzioni Modelli e procedure per ambienti ibridi e multi-cloud.
• Per ulteriori architetture di riferimento, diagrammi e best practice, esplora Cloud Architecture Center.