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.

È più facile per le persone e le applicazioni utilizzare il DNS (Domain Name System) per indirizzare applicazioni e servizi perché un nome è più facile da ricordare e più flessibile rispetto all'utilizzo degli 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. Tradizionalmente, i record DNS on-premise vengono amministrati manualmente utilizzando un server DNS autoritario, ad esempio BIND in ambienti UNIX/Linux o Active Directory in ambienti Microsoft Windows.

Questo documento descrive le best practice per l'inoltro delle richieste DNS private tra gli ambienti per assicurarsi che i servizi possano essere indirizzati sia dagli ambienti on-premise sia da Google Cloud.

Principi generali

Scopri i concetti 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 gestione delle zone DNS con bassa latenza e alta disponibilità. Può fungere da server DNS autorevole per le zone private visibili solo all'interno della tua rete.
  • Managed Service for Microsoft Active Directory è un servizio altamente disponibile e con protezione avanzata che esegue Microsoft Active Directory, incluso un controller di dominio.

Identifica gli stakeholder, gli strumenti e i processi

Quando pensi di creare una strategia per il DNS in un ambiente ibrido, è importante acquisire familiarità con la tua 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 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 Cloud DNS sia indirizzato correttamente.
  • Acquisisci familiarità con la tua strategia di connettività ibrida e con i modelli e le best practice per ambienti ibridi e multi-cloud.

Best practice per le zone private Cloud DNS

Le zone private ospitano record DNS visibili solo all'interno della tua organizzazione.

Utilizzare l'automazione per gestire le zone private nel progetto host 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 servizi 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 vengono 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 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 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 pull dei 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

Utilizza il principio di sicurezza del privilegio minimo per concedere il diritto di modificare i record DNS solo a chi nella tua organizzazione deve eseguire questa operazione. 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.

Best practice per le zone di inoltro DNS e i criteri del 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 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 relativa alle 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 esterni vengono comunque risolti senza un hop aggiuntivo tramite un server 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 tutto il traffico DNS deve essere monitorato o filtrato on-premise e se il registro DNS privato non soddisfa 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 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 è mostrato nelle Architetture di riferimento per DNS in un ambiente 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 inoltri le query da Cloud DNS. Cloud DNS invia query dall'intervallo di indirizzi IP35.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 fluire dalla rete on-premise agli indirizzi 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 tramite 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 della zona che utilizzi on-premise, puoi anche delegare questo sottodominio al nome del server Google Cloud impostando le 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 trasmetta queste richieste.

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

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

Non utilizzare il reindirizzamento in uscita ai server DNS on-premise da più reti VPC perché crea problemi con il traffico di ritorno. Google Cloud accetta le risposte dei tuoi 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 lo stesso 35.199.192.0/19 intervallo di indirizzi IP come origine. Pertanto, le risposte non possono essere indirizzate correttamente, a meno che non disponi di ambienti on-premise distinti.

Figura 4. Si verifica un problema quando più VPC inoltrano il traffico al di fuori delle loro reti.
Figura 4. Problema relativo alla presenza di più reti VPC che eseguono il reindirizzamento 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 è illustrata nella sezione 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 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 continuano a seguire il proprio ordine di risoluzione.

Al contrario, tramite il peering DNS, puoi consentire l'inoltro delle richieste per determinate zone 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 è quindi automaticamente bidirezionale.

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. Per configurare il peering DNS da una rete VPC consumer, devi disporre del 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 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 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 in un ambiente 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. È possibile eseguire query su tutti i record sia da host on-premise sia da Google Cloud.

Utilizza l'architettura di riferimento che si mappa al design della rete VPC:

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

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

  • Architettura ibrida che utilizza 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 di Google Cloud tramite uno o più tunnel Cloud VPN o connessioni Dedicated Interconnect o Partner Interconnect. Non è rilevante il metodo di connessione utilizzato per ogni rete VPC.

Architettura ibrida che utilizza una singola rete VPC condiviso

Il caso d'uso più comune è un'unica 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 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 configura tutti i record per le risorse in quella zona.
  3. Imposta un criterio del server DNS nel progetto host per la rete VPC condiviso per consentire l'inoltro DNS in entrata.
  4. Imposta una zona di inoltro DNS che inoltri corp.example.com ai server DNS on-premise. La rete VPC condivisa deve essere autorizzata a eseguire query sulla 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 condiviso.
  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 nel tuo ambiente Google Cloud non sono collegate 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 hai ambienti di produzione e di sviluppo separati che non comunicano tra loro, 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 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 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) su Cloud DNS nel progetto host della rete VPC condiviso 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 da inoltrarecorp.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 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 sui firewall on-premise sia su quelli 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 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 показано показано nella figura 8, puoi utilizzare il peering di rete VPC per eseguire il peering di una rete VPC con più reti VPC spoke. Ogni rete VPC spoke ospita le proprie zone private su Cloud DNS. Le route personalizzate nel peering di rete VPC, insieme all'annuncio della route personalizzata sul router Cloud, consentono lo scambio completo delle route e la connettività tra la rete 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 una rete VPC hub collegata a reti VPC spoke utilizzando 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 autoritativi 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 un criterio del server DNS nel 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 percorp.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 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.

Passaggi successivi