Best practice per Cloud DNS

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

Sia per le persone che per le applicazioni, è più facile utilizzare il DNS (Domain Name System) per gestire applicazioni e servizi, in quanto l'uso di un nome è più facile da ricordare e più flessibile rispetto all'uso di indirizzi IP. In un ambiente ibrido costituito da ambienti on-premise e da una o più piattaforme cloud, spesso è necessario accedere ai record DNS per le risorse interne in più ambienti. Tradizionalmente, i record DNS on-premise vengono amministrati manualmente utilizzando un server DNS autorevole, come BIND in ambienti UNIX/Linux o Active Directory negli ambienti Microsoft Windows.

Questo articolo descrive le best practice per l'inoltro di richieste DNS private tra gli ambienti per assicurarti che i servizi possano essere gestiti da ambienti on-premise e all'interno di Google Cloud.

Principi generali

Scopri i concetti di base del 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 le macchine virtuali e i bilanciatori del carico interni su Compute Engine.
  • Cloud DNS è un servizio che fornisce servizi per le zone DNS a bassa latenza e ad alta disponibilità. Può fungere da server DNS autorevole per le zone pubbliche visibili su internet o per le zone private visibili solo all'interno della rete.
  • Managed Service for Microsoft Active Directory è un servizio protetto e a disponibilità elevata che esegue Microsoft Active Directory, tra cui un controller di dominio.
  • Public DNS (DNS pubblico) è un servizio Google che non fa parte di Google Cloud e che agisce come un resolver DNS aperto e ricorsivo.
  • Cloud Domains è un registrar di domini per l'acquisto, il trasferimento e la gestione di domini in Google Cloud. Cloud Domains ti consente di interagire con il sistema di registrazione dei domini tramite un'API.

Identificare gli stakeholder, gli strumenti e i 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 DNS di Google Cloud, consulta Utilizzare l'inoltro condizionale per accedere ai record DNS dall'ambiente on-premise.
  • Acquisisci familiarità con il software DNS attuale e identifica i nomi di dominio utilizzati privatamente all'interno della tua organizzazione.
  • Identificare i contatti del team di networking che possono garantire che il traffico verso i server Cloud DNS sia instradato correttamente.
  • Acquisisci familiarità con la strategia di connettività ibrida e con pratiche e pattern di ambienti ibridi e multi-cloud.

Creare uno standard di denominazione semplice e coerente

Crea uno standard di denominazione che sia coerente in tutta l'organizzazione, ma semplice da ricordare. Ad esempio, supponiamo che la tua organizzazione utilizzi example.com come nome di dominio di secondo livello e il dominio per le risorse pubbliche (ad esempio www.example.com). Il luogo in cui sono ospitate le zone pubbliche non è pertinente agli scopi di questo documento, perché l'ambito è la migrazione di zone private.

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

  • Puoi avere nomi di dominio separati per i server on-premise e per Google Cloud. Questo pattern utilizza un dominio separato per i tuoi diversi ambienti, ad esempio corp.example.com per i server on-premise e gcp.example.com per tutte le risorse su Google Cloud. Se usi altri ambienti cloud pubblico, ciascuno può avere un sottodominio separato. Questo è il pattern preferito, perché è facile inoltrare le richieste tra gli ambienti.

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

  • Puoi avere il dominio Google Cloud come sottodominio del dominio che contiene server on-premise. Con il dominio example.com, l'ambiente on-premise potrebbe utilizzare corp.example.com e Google Cloud potrebbe usare gcp.corp.example.com. Si tratta di un modello comune quando la maggior parte delle risorse rimane on-premise.

  • Il dominio on-premise può essere un sottodominio del dominio che contiene i record di Google Cloud. Con il dominio example.com, Google Cloud potrebbe utilizzare corp.example.com e l'ambiente on-premise potrebbe usare dc.corp.example.com. Si tratta di un pattern insolito, ma potrebbe essere utilizzato per le organizzazioni digitali con un impatto minimo on-premise.

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

Il resto della pagina utilizza i seguenti nomi di dominio:

  • example.com come nome di dominio per i tuoi registri 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 gestita privata di Cloud DNS che ospita record per le tue risorse Google Cloud.

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

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

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

Scegli dove viene eseguita la risoluzione DNS

In un ambiente ibrido, la risoluzione DNS può essere eseguita in località diverse. Ecco cosa puoi fare:

  • Utilizza un approccio ibrido con due sistemi DNS autorevoli.
  • Mantieni la risoluzione DNS on-premise.
  • Sposta tutte le risoluzioni DNS in Cloud DNS.

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

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

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

La Figura 2 mostra questa disposizione.

Figura 2. Un'architettura DNS ibrida che utilizza sia Cloud DNS che server DNS on-premise per fornire una risoluzione DNS autorevole.
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. Di seguito sono riportati i dettagli riportati di seguito in questa pagina:

  • Come configurare l'inoltro tra ambienti utilizzando le zone private e l'inoltro DNS.
  • Come configurare i firewall e il 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 tuo server DNS on-premise esistente per l'hosting autorevole di tutti i nomi di dominio interni. In questo caso, puoi utilizzare un server dei nomi alternativo per inoltrare tutte le richieste da Google Cloud attraverso l'inoltro DNS in uscita.

Questo approccio presenta i seguenti vantaggi:

  • Apporta meno modifiche ai processi aziendali.
  • Puoi continuare a utilizzare gli strumenti esistenti.
  • Puoi utilizzare gli elenchi di negazione per filtrare singole richieste DNS on-premise.

Tuttavia, presenta i seguenti svantaggi:

  • Le richieste DNS di Google Cloud hanno una latenza maggiore.
  • Il sistema si basa sulla connettività ad ambienti on-premise per le operazioni DNS.
  • Potrebbe essere difficile 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 tutte le risoluzioni DNS in Cloud DNS

Un altro approccio è eseguire la migrazione a Cloud DNS come servizio autorevole per tutte le risoluzioni dei domini. Puoi quindi utilizzare le zone private e l'inoltro 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 disponibilità on-premise.
  • Il tuo sistema può utilizzare Cloud DNS per sfruttare logging e monitoraggio centralizzati.

Tuttavia, presenta i seguenti svantaggi:

  • Le richieste DNS da on-premise hanno una latenza maggiore.
  • Il sistema richiede 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 dell'organizzazione. Le zone pubbliche su Cloud DNS non sono trattate in questo documento. Le zone pubbliche coprono i record pubblici dell'organizzazione, ad esempio 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 condiviso'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 condiviso. In alternativa, puoi configurare la zona in un progetto di servizio utilizzando l'associazione tra progetti.

La Figura 3 mostra come le zone private sono ospitate in una rete VPC condiviso.

Figura 3. Zone private ospitate in una rete VPC condiviso (fai clic per ingrandire).
Figura 3. Questa configurazione mostra come le zone private sono collegate a un VPC condiviso.

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

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

In entrambi i casi, un account di servizio con il ruolo IAM Amministratore DNS nel progetto host può eseguire automaticamente il deployment delle modifiche dopo che sono state approvate.

Impostazione dei 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 eseguire questa attività. Evita di utilizzare i ruoli di base perché potrebbero concedere l'accesso a risorse diverse da quelle richieste dall'utente. Cloud DNS offre ruoli e autorizzazioni che ti consentono di concedere l'accesso in lettura e scrittura specifico per 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 inoltro DNS e i criteri dei server

Cloud DNS offre zone di inoltro DNS e criteri dei server DNS per consentire le ricerche di nomi DNS tra l'ambiente on-premise e Google Cloud. Hai a disposizione più opzioni per configurare l'inoltro DNS. La seguente sezione elenca le best practice per la configurazione del DNS ibrido. Queste best practice sono illustrate nella sezione Architetture di riferimento per DNS ibridi.

usa le zone di forwarding per eseguire query sui server on-premise

Per assicurarti di eseguire 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 rispetto all'utilizzo di un criterio DNS che abilita un server dei nomi alternativo. Mantiene l'accesso ai nomi DNS interni di Compute Engine e gli indirizzi IP pubblici vengono comunque risolti senza un ulteriore hop tramite un server dei nomi on-premise.

Il flusso di traffico che utilizza questa configurazione è mostrato nella sezione Architetture di riferimento per il DNS ibrido.

Utilizza server dei nomi alternativi solo se tutto il traffico DNS deve essere monitorato o filtrato on-premise e se il logging DNS privato non è in grado di soddisfare i tuoi requisiti.

Utilizza i criteri del server DNS per consentire le query da on-premise

Per consentire agli host on-premise di eseguire query sui record DNS ospitati nelle zone private di Cloud DNS (ad esempio gcp.example.com), crea un criterio del server DNS utilizzando l'inoltro DNS in entrata. L'inoltro DNS in entrata consente al sistema di eseguire 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 nella sezione Architetture di riferimento per il DNS ibrido.

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

Assicurati che il traffico DNS non sia filtrato all'interno della rete VPC o dell'ambiente on-premise seguendo questi passaggi:

  • Assicurati che il firewall on-premise passi le query 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 TCP 53, a seconda delle dimensioni della richiesta o della risposta.

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

  • Assicurati che il traffico possa fluire da on-premise ai tuoi indirizzi IP di inoltro. Nelle istanze del router Cloud, aggiungi un annuncio di route personalizzato per l'intervallo IP 35.199.192.0/19 nella tua rete VPC all'ambiente on-premise.

Utilizza l'inoltro condizionale per accedere ai record DNS dall'ambiente on-premise

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

  • Inoltro condizionale. Con l'inoltro condizionale, il server DNS aziendale inoltra le richieste per zone o sottodomini specifici agli indirizzi IP di inoltro su Google Cloud. Ti 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 nomi di Google Cloud impostando voci NS all'interno della tua zona. Quando utilizzi questa configurazione, i client possono comunicare direttamente con gli indirizzi IP di inoltro su Google Cloud, quindi assicurati che il firewall superi queste richieste.

  • Trasferimenti di zona. Cloud DNS non supporta i trasferimenti di zona, quindi non puoi utilizzare i trasferimenti di zona per sincronizzare i record DNS con i server DNS on-premise.

Utilizza il peering DNS per evitare l'inoltro in uscita da più reti VPC

Non utilizzare l'inoltro in uscita ai server DNS on-premise da più reti VPC perché crea problemi con il traffico di ritorno. Google Cloud accetta le risposte dai tuoi server DNS solo se vengono instradate alla rete VPC da cui ha avuto origine la query. Tuttavia, le query da qualsiasi rete VPC hanno lo stesso intervallo IP 35.199.192.0/19 dell'origine. Di conseguenza, le risposte non possono essere indirizzate in modo corretto, a meno che tu non abbia ambienti separati on-premise.

Figura 4. Si verifica un problema quando più traffico di forwarding VPC si trova al di fuori delle loro reti.
Figura 4. Problema con più reti VPC che eseguono l'inoltro in uscita.

Ti consigliamo di designare una singola rete VPC per eseguire query sui server dei nomi on-premise utilizzando l'inoltro in uscita. Quindi, altre reti VPC possono eseguire query sui server dei nomi on-premise scegliendo come target la rete VPC designata con una zona di peering DNS. Le query verranno quindi inoltrate ai server dei nomi on-premise in base all'ordine di risoluzione dei nomi della rete VPC designata. Questa configurazione è mostrata nella sezione Architetture di riferimento per DNS ibridi.

Comprendi la differenza tra peering DNS e peering di rete VPC

Il peering di rete VPC non corrisponde al peering DNS. Il peering di rete VPC consente alle istanze di macchine virtuali (VM) di più progetti di raggiungersi l'una con l'altra, ma non modifica la risoluzione dei nomi. Le risorse in ogni rete VPC seguono comunque il proprio ordine di risoluzione.

Al contrario, tramite il peering DNS, puoi consentire l'inoltro delle richieste per zone specifiche a un'altra rete VPC. Ciò consente di inoltrare le richieste a diversi ambienti Google Cloud, indipendentemente dal fatto che le reti VPC siano interconnesse.

Anche il peering di rete VPC e il peering DNS sono configurati 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 è quindi automaticamente bidirezionale.

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

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 rete on-premise.

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

In caso di problemi, 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 ibrido

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

Utilizza l'architettura di riferimento che corrisponde alla progettazione della tua rete VPC:

  • Architettura ibrida che utilizza un'unica rete VPC condiviso: utilizza una singola rete VPC connessa da o verso ambienti on-premise.

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

  • Architettura ibrida mediante 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. Non è pertinente quale metodo di connessione viene utilizzato per ogni rete VPC.

Architettura ibrida che utilizza un'unica rete VPC condiviso

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

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

Per configurare questa architettura:

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

Architettura ibrida che utilizza più reti VPC separate

Un'altra opzione per le architetture ibride è quella di avere più reti VPC separate. Queste reti VPC nell'ambiente Google Cloud non sono connesse tra loro tramite il peering di rete VPC. Tutte le reti VPC utilizzano tunnel Cloud VPN o collegamenti VLAN separati per connettersi agli ambienti on-premise.

Come mostrato nella Figura 7, un caso d'uso tipico di questa architettura si verifica quando si dispone di ambienti di produzione e sviluppo separati che non comunicano tra loro, ma condividono server DNS.

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

Per configurare questa architettura:

  1. Configura i server DNS on-premise come autorevoli per corp.example.com.
  2. Configura una zona privata (ad esempio prod.gcp.example.com) in Cloud DNS nel progetto host della rete VPC condiviso di produzione e configura tutti i record per le risorse in quella zona.
  3. Configura una zona privata (ad esempio dev.gcp.example.com) in Cloud DNS nel progetto host della rete VPC condiviso di sviluppo e imposta tutti i record per le risorse in quella zona.
  4. Impostare un criterio del server DNS sul progetto host per la rete VPC condiviso di produzione e consentire l'inoltro DNS in entrata.
  5. Nella rete VPC condiviso 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 condiviso di sviluppo alla rete VPC condiviso di produzione per prod.gcp.example.com.
  7. Imposta una zona di peering DNS dalla rete VPC condiviso di produzione alla rete VPC condiviso di sviluppo per dev.gcp.example.com.
  8. Configura l'inoltro in entrata delega 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 che su quelli di Google Cloud.
  10. Nelle istanze del router Cloud, aggiungi un annuncio di route personalizzato per l'intervallo IP 35.199.192.0/19 nella rete VPC condiviso di produzione all'ambiente on-premise.

Architettura ibrida che utilizza 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 proprie zone private in Cloud DNS. Le route personalizzate sul peering di rete VPC, insieme alla pubblicità di route personalizzate sul router Cloud, consentono lo scambio completo di route e la connettività tra reti VPC 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 diagramma seguente mostra questa architettura.

Immagine 8. Un'architettura ibrida può utilizzare una rete VPC hub connessa a reti VPC spoke mediante il peering di rete VPC.
Figura 8. Un'architettura ibrida può utilizzare una rete VPC hub connessa a reti VPC spoke.

Per configurare questa architettura:

  1. Configura i server DNS on-premise come autorevoli per corp.example.com.
  2. Configura una zona privata (ad esempio projectX.gcp.example.com) in Cloud DNS per ogni rete VPC spoke e configura tutti i record per le risorse in quella zona.
  3. Impostare un criterio del server DNS sul progetto hub per la rete VPC condiviso di produzione per consentire l'inoltro DNS in entrata.
  4. Nella rete VPC dell'hub, crea una zona DNS privata per corp.example.com e configura l'inoltro in uscita ai server DNS on-premise.
  5. Imposta una zona di peering DNS dalla rete VPC dell'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 dell'hub per example.com.
  7. Configura l'inoltro a gcp.example.com sui tuoi server DNS on-premise in modo che puntino a un indirizzo IP dell'inoltro in entrata nella rete VPC dell'hub.
  8. Assicurati che il firewall consenta il traffico DNS sia sui firewall on-premise che su quelli di Google Cloud.
  9. Nelle istanze del router Cloud, aggiungi un annuncio di route personalizzato per l'intervallo IP 35.199.192.0/19 nella rete VPC dell'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 dall'ambiente on-premise.

DNS pubblico multi-provider utilizzando Cloud DNS

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

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 utilizza Cloud DNS come uno dei tuoi provider DNS in una configurazione attivo-attivo (consigliato) o attivo-passivo per garantire un'architettura DNS ad alta disponibilità. Dopo che hai eseguito il deployment della soluzione, octoDNS esegue una sincronizzazione una tantum e continua tra le tue attuali zone DNS 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 richiedere alcuna modifica alle pipeline CI/CD.

Passaggi successivi