Questo documento fornisce le best practice per zone private, forwarding DNS e 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 piattaforma on-premise e da una o più piattaforme cloud, i record DNS
spesso è necessario accedere alle risorse interne in diversi 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 comprendere il sistemi e servizi diversi disponibili in Google Cloud risoluzione e nomi di dominio:
- Il DNS interno è un servizio che esegue automaticamente crea nomi DNS per macchine virtuali e bilanciatori del carico interni 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.
- Il DNS pubblico è un servizio che non fa parte di Google Cloud e che funge da piattaforma resolver DNS 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 la registrazione del dominio tramite un'API.
Identifica stakeholder, strumenti e 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 di accesso dei record DNS di Google Cloud: Utilizza l'inoltro condizionale per accedere ai record DNS da on-premise.
- Acquisisci familiarità con il software DNS attuale e identifica il dominio utilizzati privatamente all'interno della tua organizzazione.
- Identificare contatti del team di networking che possano assicurarsi che il traffico I server Cloud DNS sono instradati correttamente.
- Acquisisci familiarità con la tua strategia di connettività ibrida e di connettività ibrida 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 disgiunti per i server on-premise e per in Google Cloud. Questo pattern utilizza un dominio separato per i vari ambienti, ad esempio
corp.example.com
per i server on-premise egcp.example.com
per tutti 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
eexample.cloud
.Il dominio Google Cloud può essere un sottodominio del dominio che contiene server on-premise. Utilizzo del dominio
example.com
, on-premise potrebbe usarecorp.example.com
, mentre Google Cloud potrebbe usaregcp.corp.example.com
. Si tratta di un modello comune quando la maggior parte delle risorse rimangono on-premise.Il dominio on-premise può essere un sottodominio del dominio che contiene record di Google Cloud. Utilizzo del dominio
example.com
, Google Cloud potrebbe utilizzarecorp.example.com
, mentre on-premise potrebbe utilizzaredc.corp.example.com
. Si tratta di un metodo non comune, ma potrebbe essere utilizzato per applicazioni che dispongono solo di 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 pattern perché rende la gestione dei record in un ambiente ibrido è molto più difficile; è possibile solo quando utilizzi un singolo sistema DNS autorevole.
Il resto della pagina utilizza i seguenti nomi di dominio:
example.com
come nome di dominio per i tuoi record pubblici, indipendentemente da dove in cui vengono ospitati i pod.corp.example.com
come zona ospitata dal tuo server DNS on-premise. Questa zona e ospita i record delle tue risorse on-premise.gcp.example.com
come zona gestita privata di Cloud DNS che ospita per le tue risorse Google Cloud.
La Figura 1 illustra una configurazione del nome di dominio coerente tra rete on-premise e Google Cloud.
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:
- Risoluzione DNS autoritativa per il tuo ambiente Google Cloud privato viene eseguita da Cloud DNS.
- La risoluzione DNS autoritativa per le risorse on-premise è ospitata da account esistenti Server DNS on-premise.
La figura 2 mostra questa disposizione.
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:
- Apporti 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 trovare difficile integrare ambienti altamente flessibili, come di 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.
Sposta tutta la risoluzione DNS in Cloud DNS
Un altro approccio è la migrazione a Cloud DNS come servizio autorevole per la risoluzione di tutti i domini. Puoi quindi utilizzare zone private e DNS in entrata il forwarding per eseguire la migrazione degli ambienti on-premise esistenti come risoluzione dei nomi di dominio a Cloud DNS.
Questo approccio offre 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 dall'ambiente 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 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. Pubblica coprono i record pubblici dell'organizzazione, come i record DNS per il e non sono altrettanto pertinenti in una configurazione ibrida.
Utilizza l'automazione per gestire le zone private nel progetto host del VPC condiviso
Se utilizzi reti VPC condiviso 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 servizio utilizzando l'associazione tra progetti.
La figura 3 mostra come sono ospitate le zone private in una rete VPC condiviso.
Se vuoi che i team impostino i propri record DNS, ti consigliamo di automatizzare Creazione di un 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 Ruolo di Amministratore DNS nel progetto host possono eseguire automaticamente il deployment delle modifiche dopo che sono state approvato.
Imposta 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 usare le funzionalità di base ruoli perché potrebbero concedere l'accesso oltre a quelle richieste dall'utente. Cloud DNS offre ruoli e autorizzazioni che ti consentono per concedere l'accesso in lettura e scrittura specifico al 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 forwarding 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. Tu offrono più opzioni per la configurazione dell'inoltro DNS. La sezione che segue un elenco di best practice per la configurazione del DNS ibrido. Queste best practice sono illustrate nel Architetture di riferimento per DNS ibrido.
Usa le zone di forwarding per eseguire query sui server on-premise
Per assicurarti di poter eseguire query sui record DNS nel tuo ambiente on-premise, configura zona di inoltro per il dominio che utilizzi on-premise per la tua azienda (ad esempio corp.example.com). È preferibile questo approccio rispetto all'utilizzo di una 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 viene mostrato in Architetture di riferimento per DNS 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.
Utilizza i criteri del server DNS per consentire query da on-premise
consentire agli host on-premise di eseguire query sui record DNS ospitati in Zone private di Cloud DNS (ad esempio gcp.example.com), creando un DNS del server utilizzando l'inoltro DNS in entrata. L'inoltro DNS in entrata consente al sistema di interrogare tutte le zone private nonché indirizzi IP DNS interni e zone in 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 sia filtrato in nessun punto all'interno del rete VPC o ambiente on-premise eseguendo queste operazioni:
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 le dimensioni della richiesta o della risposta.Assicurati che il server DNS non blocchi le query. Se la tua rete on-premise Il server DNS accetta richieste solo da indirizzi IP specifici, assicurati che è incluso l'intervallo di indirizzi IP
35.199.192.0/19
.Assicurati che il traffico possa passare da on-premise al tuo IP di inoltro . Nelle istanze del router Cloud, aggiungi un route per l'intervallo di indirizzi IP
35.199.192.0/19
nel tuo VPC la rete Google all'ambiente on-premise.
Usa l'inoltro condizionale per accedere ai record DNS da on-premise
Con Cloud DNS, per accedere a record privati ospitati sui server DNS aziendali. on-premise, puoi usare solo zone di inoltro. Tuttavia, a seconda del server DNS software utilizzato, potresti avere a disposizione 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. Se utilizzi l'inoltro condizionale, il server DNS aziendale inoltra le richieste per zone o sottodomini specifici al di inoltro degli indirizzi IP su Google Cloud. Consigliamo questo approccio perché è la meno complessa e consente di monitorare centralmente tutti richieste sui server DNS aziendali.
Delega. 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 zona. Cloud DNS non supporta i trasferimenti di zone, 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 l'inoltro 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 da qualsiasi rete VPC hanno lo stesso
Intervallo di indirizzi IP 35.199.192.0/19
come origine. Pertanto, le risposte non possono essere
correttamente, a meno che tu non abbia ambienti on-premise separati.
Ti consigliamo di designare una singola rete VPC su cui eseguire query e i server dei nomi on-premise, utilizzando l'inoltro in uscita. Quindi, aggiungiamo Le reti VPC possono eseguire query sui server dei nomi on-premise scegliendo come target alla rete VPC designata con una zona di peering DNS. Le sue query verrà quindi inoltrato ai server dei nomi on-premise in base ordine di risoluzione dei nomi del sulla rete VPC designata. Questa configurazione viene mostrata Architetture di riferimento per DNS ibrido.
Differenze tra peering DNS e peering di rete VPC
Peering di rete VPC non è uguale a Peering DNS. Il peering di rete VPC consente alle istanze di macchine virtuali (VM) in più progetti per raggiungersi, ma la risoluzione dei nomi rimane invariata. 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 a diversi ambienti Google Cloud, indipendentemente dal fatto che Le reti VPC sono interconnesse.
Anche il peering di rete VPC e il peering DNS sono impostati 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 in modo unidirezionale le richieste DNS e non richiede
una relazione bidirezionale tra reti VPC. R
Una rete VPC denominata rete consumer DNS esegue
Cerca una zona di peering Cloud DNS in un altro VPC
denominata rete del producer DNS. Utenti con
Autorizzazione IAM dns.networks.targetWithPeeringZone
in
può stabilire il peering DNS tra consumer e
delle reti dei produttori. 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 tutti e .internal
in un progetto hub per renderle accessibili dalla rete on-premise.
.internal
zone in un hub.In caso di problemi, segui la guida per la 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 Zone private di Cloud DNS in un ambiente ibrido. In ogni caso sia le risorse on-premise e i record e le zone delle risorse Google Cloud gestite 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 condiviso: utilizza una singola rete VPC connessa o da on-premise ambienti cloud-native.
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 condiviso
Il caso d'uso più comune è una singola rete VPC condivisa connessa dell'ambiente on-premise, come mostrato nella Figura 6.
Per configurare questa architettura:
- Configura i tuoi server DNS on-premise come autoritativi per
corp.example.com
. - 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. - Imposta un criterio del server DNS sul progetto host per il VPC condiviso per consentire l'inoltro DNS in entrata.
- 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. - Configura l'inoltro a
gcp.example.com
sui tuoi server DNS on-premise che punta a un indirizzo IP di forwarding in entrata nella rete VPC condiviso. - Assicurati che il traffico DNS sia consentito sul firewall on-premise.
- Nelle istanze del router Cloud, aggiungi una route annunciata personalizzata 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. 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.
Per configurare questa architettura:
- Configura i tuoi server DNS on-premise come autoritativi per
corp.example.com
. - Configura una zona privata (ad esempio
prod.gcp.example.com
) su Cloud DNS nel progetto host del VPC condiviso di produzione rete e configurare tutti i record per le risorse in quella zona. - Configura una zona privata (ad esempio
dev.gcp.example.com
) su Cloud DNS nel progetto host del VPC condiviso di sviluppo rete e configurare tutti i record per le risorse in quella zona. - Imposta un criterio del server DNS sul progetto host per il VPC condiviso di produzione rete e consentire l'inoltro DNS in entrata.
- Nella rete VPC condiviso di produzione, imposta una zona DNS per l'inoltro
corp.example.com
ai server DNS on-premise. - Imposta una zona di peering DNS dalla rete VPC condiviso di sviluppo alla
rete VPC condiviso di produzione per
prod.gcp.example.com
. - Imposta una zona di peering DNS dalla rete VPC condiviso di produzione all'account
rete VPC condiviso di sviluppo per
dev.gcp.example.com
. - Configura l'inoltro in entrata delega la risoluzione di
gcp.example.com.
agli indirizzi IP virtuali di forwarding in entrata di Cloud DNS sul tuo e i server dei nomi on-premise. - Assicurati che il firewall consenta il traffico DNS sia on-premise firewall di Google Cloud.
- Nelle istanze del router Cloud, aggiungi una route annunciata personalizzata
Intervallo di indirizzi IP
35.199.192.0/19
nel VPC condiviso di produzione la rete Google 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 connettersi dall'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.
Per configurare questa architettura:
- Configura i tuoi server DNS on-premise come autoritativi per
corp.example.com
. - 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. - Imposta un criterio del server DNS sul progetto hub per la produzione Rete VPC condiviso per consentire il forwarding DNS in entrata.
- Nella rete VPC dell'hub, crea una zona DNS privata per
corp.example.com
e configura l'inoltro in uscita al DNS on-premise server web. - Imposta una zona di peering DNS dalla rete VPC dell'hub su ogni spoke
Rete VPC per
projectX.gcp.example.com
. - Imposta una zona di peering DNS da ogni rete VPC spoke all'hub
Rete VPC per
example.com
. - Configura l'inoltro a
gcp.example.com
sui tuoi server DNS on-premise per punta a un indirizzo IP del server di forwarding in entrata nella rete VPC dell'hub. - Assicurati che il firewall consenta il traffico DNS sia on-premise firewall di Google Cloud.
- Nelle istanze del router Cloud, aggiungi una route annunciata personalizzata
Intervallo di indirizzi IP
35.199.192.0/19
nella rete VPC dell'hub da per l'ambiente on-premise. - (Facoltativo) Se utilizzi anche i nomi DNS interni generati automaticamente,
esegui il peering di ciascuna zona del progetto spoke (ad esempio,
spoke-project-x.internal
) con il progetto hub e inoltra tutte le query per.internal
da on-premise.
DNS pubblico multifornitore tramite Cloud DNS
Essendo un componente fondamentale del networking delle applicazioni, un DNS affidabile è fondamentale per assicurarti che le applicazioni o i 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. Il DNS multi-provider sfrutta Cloud DNS come uno dei tuoi provider DNS in una attiva/attiva (consigliata) o attiva-passiva per garantire un'elevata architettura DNS disponibile. Dopo aver eseguito il deployment della soluzione, octoDNS esegue una sincronizzazione una tantum e continua tra le zone DNS attuali di 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.
- Per configurare Cloud DNS in una configurazione DNS pubblico multi-provider, vedi multi-provider-dns-with-clouddns.
Passaggi successivi
- Per trovare soluzioni a problemi comuni che potresti riscontrare durante l'utilizzo Cloud DNS, consulta Risoluzione dei problemi.
- Per trovare indicazioni su come approcciare e implementare una configurazione ibrida che utilizza Google Cloud, consulta Pattern e pratiche ibridi e multi-cloud soluzioni di Google Cloud.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.