Best practice per Cloud DNS

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

Sia per gli esseri umani che per le applicazioni è più facile utilizzare il DNS (Domain Name System) per gestire applicazioni e servizi perché è più facile e più flessibile rispetto all'uso di indirizzi IP. In un ambiente ibrido costituito da una o più piattaforme cloud on-premise, spesso è necessario accedere ai record DNS per le risorse interne in più ambienti. In genere, I record DNS on-premise vengono amministrati manualmente utilizzando un DNS autoritativo come BIND in ambienti UNIX/Linux o Active Directory in Ambienti Microsoft Windows.

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

Principi generali

Scopri i concetti del DNS su Google Cloud

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

  • 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 bassa latenza e gestione delle zone DNS ad alta disponibilità. Può fungere da server DNS autorevole per le zone pubbliche visibili su Internet o per le zone private sono visibili solo all'interno della tua rete.
  • Managed Service for Microsoft Active Directory è una protetto e a disponibilità elevata che esegue Microsoft Active Directory, incluso un controller di dominio.
  • Public DNS è un servizio Google che non fa parte di Google Cloud e agisce come resolver DNS aperto e ricorsivo.
  • Cloud Domains è un registrar di domini per l'acquisto, trasferire e gestire i domini all'interno di Google Cloud. Cloud Domains ti consente di interagire con il sistema di registrazione dei domini tramite un'API.

Identifica gli stakeholder, gli strumenti e i processi

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

  • Identifica e contatta l'amministratore del DNS aziendale della tua organizzazione server web. Chiedi al cliente informazioni sulle configurazioni richieste per mappare la tua configurazione on-premise a un'architettura adatta in Google Cloud. Per informazioni sui metodi per accedere ai record DNS di Google Cloud, consulta Utilizzare il forwarding condizionale per accedere ai record DNS 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 rete che possono assicurarsi che il traffico verso i server DNS di Cloud sia indirizzato correttamente.
  • Acquisisci familiarità con la tua strategia di connettività ibrida e con i modelli e le pratiche per ambienti ibridi e multi-cloud.

Crea uno standard di denominazione semplice e coerente

Crea uno standard di denominazione 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). La posizione in cui le zone pubbliche sono ospitate è irrilevante agli scopi di questo documento perché l'ambito è la migrazione delle zone private.

Per denominare le risorse aziendali on-premise, puoi scegliere tra le seguenti opzioni pattern:

  • Puoi avere nomi di dominio incoerenti per i server on-premise e per Google Cloud. Questo pattern 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 pubblico, ciascuna di queste 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 i server on-premise. Utilizzo del dominio example.com, on-premise potrebbe usare corp.example.com, mentre Google Cloud potrebbe usare gcp.corp.example.com. Si tratta di un modello comune quando la maggior parte delle risorse rimangono on-premise.

  • Puoi avere il dominio on-premise come sottodominio del dominio che contiene i record di Google Cloud. Utilizzo del dominio example.com, Google Cloud potrebbe utilizzare corp.example.com, mentre on-premise potrebbe utilizzare dc.corp.example.com. Si tratta di un pattern insolito, ma potrebbe essere utilizzato per le organizzazioni digitali con un'impronta on-premise ridotta.

  • Puoi utilizzare lo stesso dominio per Google Cloud e per on-premise. In questo caso, sia Google Cloud che on-premise utilizzano risorse che utilizzano il dominio corp.example.com. Evita questo modello perché complica notevolmente la gestione dei record in un ambiente ibrido. È possibile solo se utilizzi un unico sistema DNS autorevole.

Il resto di questa pagina utilizza i seguenti nomi di dominio:

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

La Figura 1 mostra una configurazione del nome di dominio coerente sia sulla rete on-premise sia su Google Cloud.

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

Per denominare le risorse all'interno della tua rete Virtual Private Cloud (VPC), puoi: segui linee guida come quelle indicate 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 località diverse. Puoi:

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

Consigliamo l'approccio ibrido, quindi questo documento si concentra su questo approccio. Tuttavia, per completezza, il presente documento descrive brevemente l'alternativa approcci.

Utilizza un approccio ibrido con due sistemi DNS autorevoli

Consigliamo di utilizzare un approccio ibrido con due sistemi DNS autorevoli. In 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 da server DNS on-premise esistenti.

La Figura 2 mostra questa disposizione.

Figura 2. Un'architettura DNS ibrida che utilizza sia Cloud DNS e server DNS on-premise per fornire una risoluzione DNS autoritativa.
Figura 2. un'architettura DNS ibrida che utilizza Cloud DNS e i server DNS on-premise offrono risoluzione DNS.

Lo scenario mostrato nella figura 2 è il caso d'uso preferito. I seguenti dettagli verranno trattati più avanti in questa pagina:

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

Questo approccio offre i seguenti vantaggi:

  • Apporta meno modifiche ai processi aziendali.
  • Puoi continuare a usare gli strumenti esistenti.
  • Puoi utilizzare le liste bloccate per filtrare singole richieste DNS on-premise.

Tuttavia, presenta i seguenti svantaggi:

  • Le richieste DNS da Google Cloud hanno una latenza più elevata.
  • Il tuo sistema si basa sulla connettività agli ambienti on-premise per DNS operazioni aziendali.
  • 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 di Google Cloud dei nomi delle istanze.

Spostare tutta la risoluzione DNS in Cloud DNS

Un altro approccio consiste nell'eseguire la migrazione a Cloud DNS come servizio autorevole per tutta la risoluzione dei domini. Puoi 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 mantenere un servizio DNS ad alta disponibilità on-premise.
  • Il tuo sistema può utilizzare Cloud DNS per sfruttare la configurazione la registrazione e il monitoraggio.

Tuttavia, presenta i seguenti svantaggi:

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

Best practice per le zone private 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. Pubblica coprono i record pubblici dell'organizzazione, come i record DNS per il e non sono altrettanto pertinenti in una configurazione ibrida.

Utilizzare l'automazione per gestire le zone private nel progetto host 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 servizi possono accedere automaticamente ai record nelle zone private collegate 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 vengono ospitate in una rete VPC condivisa.

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

Se vuoi che i team impostino 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 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 configurazione DNS in un repository di codice come Cloud Source Repositories sotto forma di Terraform oppure Cloud Deployment Manager e accettano le richieste di pull dai team.

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

Impostare i ruoli IAM utilizzando il principio del privilegio minimo

Applicare il principio di sicurezza di almeno privilegio di dare il diritto di modificare i record DNS solo in quelli della tua organizzazione che devono eseguire questa attività. Evita di utilizzare i ruoli di base perché potrebbero consentire l'accesso a risorse oltre a quelle richieste dall'utente. Cloud DNS offre ruoli e autorizzazioni che ti consentono di assegnare accesso in lettura e scrittura specifico per il DNS.

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

Best practice per le zone di inoltro DNS e i criteri del server

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

Utilizzare le zone di inoltro per eseguire query sui server on-premise

Per assicurarti di poter eseguire query sui record DNS nel tuo ambiente on-premise, configura una zona di inoltro per il dominio che utilizzi on-premise per le tue risorse aziendali (ad esempio corp.example.com). Questo approccio è preferibile all'utilizzo di un criterio DNS che attiva 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 hop aggiuntivo tramite dei nomi on-premise.

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

Utilizza server dei nomi alternativi solo se è necessario che tutto il traffico DNS monitorati o filtrati on-premise e, se il logging del DNS privato non è in grado di soddisfare i tuoi requisiti.

Utilizzare i criteri del server DNS per consentire le query 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 il forwarding DNS in entrata. Il forwarding 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 con peering.

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

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

Assicurati che il traffico DNS non venga filtrato all'interno della rete VPC o dell'ambiente on-premise seguendo questa procedura:

  • Assicurati che il firewall on-premise superi le query Cloud DNS. Cloud DNS invia query dall'indirizzo IP intervallo 35.199.192.0/19. Il DNS utilizza la porta UDP 53 o la porta TCP 53, a seconda delle dimensioni 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 l'intervallo di indirizzi IP 35.199.192.0/19 sia incluso.

  • Assicurati che il traffico possa passare da on-premise al tuo IP di inoltro . Nelle istanze Cloud Router, aggiungi all'ambiente on-premise una route annunciata personalizzata per l'intervallo di indirizzi IP 35.199.192.0/19 nella rete VPC.

Utilizzare il forwarding condizionale per accedere ai record DNS dall'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 del server DNS utilizzato, potresti avere più opzioni per accedere ai record DNS in Google Cloud da on-premise. In ogni caso, l'accesso ai record avviene mediante l'inoltro DNS in entrata:

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

  • Delegazione. Se la tua zona privata su Google Cloud è un sottodominio di per la zona che utilizzi on-premise, puoi anche delegare questo sottodominio Server dei nomi Google Cloud impostando le voci NS all'interno della tua zona. Quando questa configurazione, i client possono comunicare con gli indirizzi IP direttamente in Google Cloud, quindi assicurati che il firewall superi questi richieste.

  • Trasferimenti tra zone. Cloud DNS non supporta i trasferimenti di zona, quindi non può utilizzare i trasferimenti di zona per sincronizzare i record DNS con i server on-premise Server DNS.

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

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

Figura 4. Un problema si verifica quando più forwarding VPC al di fuori delle loro reti.
Figura 4. Problema di avere più VPC che utilizzano l'inoltro in uscita.

Ti consigliamo di designare una singola rete VPC per eseguire query sui server DNS on-premise utilizzando il inoltro in uscita. In seguito, altre reti VPC possono eseguire query sui server dei nomi on-premise prendendo come target la rete VPC designata con una zona di peering DNS. Le relative query vengono quindi inoltrate ai server dei nomi on-premise in base all'ordine di risoluzione dei nomi della rete VPC designata. Questa configurazione viene mostrata Architetture di riferimento per DNS ibrido.

Differenza tra il peering DNS e il peering di rete VPC

Peering di rete VPC non è uguale a Peering DNS. Il peering di reti VPC consente alle istanze di macchine virtuali (VM) di più progetti di comunicare tra loro, ma non modifica la risoluzione dei nomi. Le risorse in ogni rete VPC seguono comunque la propria risoluzione ordine.

Al contrario, con il peering DNS, puoi consentire l'inoltro delle richieste di 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.

Anche il peering di rete VPC e il peering DNS vengono 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 è automaticamente bidirezionali.

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

Se usi nomi generati automaticamente, usa il peering DNS per le zone interne

Se utilizzi i nomi generati automaticamente per le VM che il DNS interno crea il servizio, puoi usare il peering DNS per inoltrare 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.
Figura 5. Il peering DNS viene utilizzato per organizzare .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 devi configurare 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 sia i record e le zone delle risorse Google Cloud vengono gestiti all'interno dell'ambiente. Tutti i record sono disponibili per eseguire query da host on-premise e Google Cloud.

Utilizza l'architettura di riferimento che mappa al tuo VPC progettazione della rete:

  • Architettura ibrida che utilizza una singola rete VPC condivisa: utilizza una singola rete VPC connessa a o da ambienti on-premise.

  • Architettura ibrida che utilizza più reti VPC separate: Connette più reti VPC ad ambienti on-premise attraverso tunnel VPN o collegamenti VLAN diversi e condivide lo stesso DNS dell'infrastruttura 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ù spoke indipendenti reti VPC.

In ogni caso, l'ambiente on-premise è connesso a Google Cloud reti VPC da uno o più tunnel Cloud VPN Connessioni Dedicated Interconnect o Partner Interconnect. Non è pertinente il metodo di connessione utilizzato per ogni VPC in ogni rete.

Architettura ibrida che utilizza una singola rete VPC condivisa

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

Immagine 6. Un'architettura ibrida utilizza una singola rete VPC condivisa per connettersi a una rete on-premise.
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 server DNS on-premise come autoritativi per corp.example.com.
  2. Configura una zona privata autorevole (ad esempio gcp.example.com) su Cloud DNS nel progetto host della rete VPC condiviso e configurare tutti i record per le risorse in quella zona.
  3. Imposta un criterio del server DNS nel progetto host per la rete VPC condivisa per consentire l'inoltro DNS in entrata.
  4. Imposta una zona di inoltro DNS che inoltra corp.example.com all'infrastruttura on-premise Server DNS. La rete VPC condivisa deve essere autorizzata a eseguire query nella zona di inoltro.
  5. Configura l'inoltro a gcp.example.com sui tuoi server DNS on-premise, facendo riferimento a un indirizzo IP di inoltro in entrata nella rete VPC condivisa.
  6. Assicurati che il traffico DNS sia consentito nel firewall on-premise.
  7. Nelle istanze Cloud Router, aggiungi un route annunciato personalizzato per l'intervallo35.199.192.0/19 all'ambiente on-premise.

Architettura ibrida che utilizza più reti VPC separate

Un'altra opzione per le architetture ibride è avere più reti VPC separate. Queste reti VPC Gli ambienti Google Cloud non sono connessi tra loro peering di rete VPC. Tutte le reti VPC utilizzano tramite i tunnel Cloud VPN Collegamenti VLAN per connetterti agli ambienti on-premise.

Come mostrato nella Figura 7, un caso d'uso tipico di questa architettura è quando avere ambienti di produzione e di sviluppo separati che non comunicano ma condividono i 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 tuoi server DNS on-premise come autoritativi 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 un criterio del server DNS nel progetto host per la rete VPC condiviso di produzione e consenti l'inoltro DNS in entrata.
  5. Nella rete VPC condiviso di produzione, imposta una zona DNS per l'inoltro 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. ai relativi indirizzi IP virtuali di Cloud DNS sui server dei nomi on-premise.
  9. Assicurati che il firewall consenta il traffico DNS sia on-premise firewall di Google Cloud.
  10. Nelle istanze Cloud Router, 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 che utilizza una rete VPC hub connessa a reti VPC spoke

Un'altra opzione è utilizzare Cloud Interconnect o Cloud VPN per connettere la tua infrastruttura on-premise a una rete VPC hub. Come come mostrato nella Figura 8, puoi utilizzare il peering di rete VPC per eseguire il peering Rete VPC con diverse reti VPC spoke. Ogni rete VPC spoke ospita le proprie zone private in Cloud DNS. Route personalizzate sul peering di rete VPC, insieme a route personalizzata sul router Cloud, consentire lo scambio di route complete connettività tra le 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 seguente diagramma mostra questa architettura.

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

Per configurare questa architettura:

  1. Configura i server DNS on-premise come autoritativi per corp.example.com.
  2. Configura una zona privata (ad esempio projectX.gcp.example.com) su Cloud DNS per ciascuna rete VPC spoke e configurare record per le risorse in quella zona.
  3. Imposta un criterio del server DNS nel progetto hub per la rete VPC condivisa di produzione per consentire l'inoltro DNS in entrata.
  4. Nella rete VPC dell'hub, crea una zona DNS privata percorp.example.com e configura il forwarding in uscita ai server DNS on-premise.
  5. Imposta una zona di peering DNS dalla rete VPC dell'hub su ogni spoke Rete VPC per projectX.gcp.example.com.
  6. Imposta una zona di peering DNS da ogni rete VPC spoke all'hub Rete VPC per example.com.
  7. Configura l'inoltro a gcp.example.com sui tuoi server DNS on-premise in modo che rimandi a un indirizzo IP del forwarder in entrata nella rete VPC dell'hub.
  8. Assicurati che il firewall consenta il traffico DNS sia sui firewall on-premise sia su quelli di Google Cloud.
  9. Nelle istanze di router Cloud, aggiungi una route annunciata personalizzata per l'intervallo di indirizzi 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 relative a .internal dall'on-premise.

DNS pubblico multifornitore tramite Cloud DNS

In qualità di componente di base della rete di applicazioni, un DNS affidabile è fondamentale per garantire che le tue applicazioni o i tuoi servizi siano disponibili per gli utenti. Tu possono migliorare la disponibilità e la resilienza delle tue applicazioni e dei tuoi servizi per configurare più provider DNS. Quando sono configurati più provider DNS, la tua applicazione o il tuo servizio possa essere disponibile per i tuoi utenti anche se c'è un'interruzione del servizio presso uno dei provider DNS. Puoi anche semplificare il deployment migrazione di applicazioni ibride con dipendenze tra on-premise ambienti 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 sfrutta Cloud DNS come uno dei tuoi provider DNS in una configurazione attiva-attiva (consigliata) o attiva-passiva per garantire un'architettura DNS altamente disponibile. Dopo aver implementato la soluzione, octoDNS esegue una sincronizzazione una tantum e continuativa tra le zone DNS attuali e le zone DNS gestite ospitate in Cloud DNS. Quando i singoli record DNS vengono aggiornato, le modifiche vengono propagate alle zone DNS corrispondenti ospitate Cloud DNS senza richiedere modifiche alle pipeline CI/CD.

Passaggi successivi