Best practice per Cloud DNS

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

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

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

Principi generali

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

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

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

Identifica stakeholder, strumenti e processi

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

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

Crea uno standard di denominazione coerente

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

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

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

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

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

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

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

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

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

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

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

Scegli dove eseguire la risoluzione DNS

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

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

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

Utilizza un approccio ibrido con due sistemi DNS autorevoli

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

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

La Figura 2 mostra questa configurazione.

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

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

Mantieni la risoluzione DNS on-premise

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

Questo approccio presenta i seguenti vantaggi:

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

Tuttavia, presenta i seguenti svantaggi:

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

Sposta tutta la risoluzione DNS su Cloud DNS

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

Questo approccio presenta i seguenti vantaggi:

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

Tuttavia, presenta i seguenti svantaggi:

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

Best practice per le zone private di Cloud DNS

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

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

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

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

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

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

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

Imposta i ruoli IAM utilizzando il principio del privilegio minimo

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

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

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

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

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

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

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

Utilizza server dei nomi alternativi solo se tutto il traffico DNS deve essere monitorato o filtrato on-premise e se il