Panoramica delle zone DNS

Cloud DNS supporta diversi tipi di zone pubbliche e private. Questo documento fornisce dettagli sui diversi tipi di zone e su quando puoi utilizzare l'uno o l'altro.

Zone di inoltro

Le zone di inoltro Cloud DNS ti consentono di configurare i server dei nomi di destinazione per zone private specifiche. L'utilizzo di una zona di inoltro è un modo per implementare l'inoltro DNS in uscita dalla tua rete VPC.

Una zona di inoltro Cloud DNS è un tipo speciale di zona privata Cloud DNS. Anziché creare record all'interno della zona, specifica un insieme di destinazioni di inoltro. Ogni target di forwarding è un nome di dominio completo (FQDN) o un indirizzo IP di un server DNS, che si trova nella tua rete VPC o in una rete on-premise connessa alla tua rete VPC tramite Cloud VPN o Cloud Interconnect.

Target di forwarding e metodi di routing

Cloud DNS supporta quattro tipi di destinazioni e offre metodi di routing standard o privati per la connettività.

Target di forwarding Descrizione Supporto del routing standard Il routing privato supporta Origine delle richieste
Tipo 1 Un indirizzo IP interno di una VM Google Cloud o di un bilanciatore del carico di rete passthrough interno nella stessa rete VPC autorizzata a utilizzare la zona di forwarding. Solo indirizzi IP RFC 1918: il traffico viene sempre instradato tramite una rete VPC autorizzata. Qualsiasi indirizzo IP interno, ad esempio un indirizzo privato RFC 1918, un indirizzo IP privato non RFC 1918 o un indirizzo IP esterno riutilizzato privatamente, ad eccezione di un indirizzo IP di destinazione di inoltro vietato: il traffico viene sempre instradato tramite una rete VPC autorizzata. 35.199.192.0/19
Tipo 2 Un indirizzo IP di un sistema on-premise, connesso alla rete VPC autorizzata a eseguire query sulla zona di forwarding, utilizzando Cloud VPN o Cloud Interconnect. Solo indirizzi IP RFC 1918: il traffico viene sempre instradato tramite una rete VPC autorizzata. Qualsiasi indirizzo IP interno, ad esempio un indirizzo privato RFC 1918, un indirizzo IP privato non RFC 1918 o un indirizzo IP esterno riutilizzato privatamente, ad eccezione di un indirizzo IP di destinazione di inoltro vietato: il traffico viene sempre instradato tramite una rete VPC autorizzata. 35.199.192.0/19
Tipo 3 Un indirizzo IP esterno di un server dei nomi DNS accessibile a internet o l'indirizzo IP esterno di una risorsa Google Cloud , ad esempio l'indirizzo IP esterno di una VM in un'altra rete VPC. Solo indirizzi IP esterni instradabili su internet: il traffico viene sempre instradato a internet o all'indirizzo IP esterno di una risorsa Google Cloud . Il routing privato non è supportato. Assicurati che non sia selezionato. Intervalli di origine di Google Public DNS
Tipo 4 Un nome di dominio completo di un server dei nomi di destinazione che può essere risolto in indirizzi IPv4 e IPv6 tramite l' ordine di risoluzione della rete VPC. A seconda della rete della destinazione di inoltro risolta, il traffico viene instradato in uno dei due modi seguenti:
  • Indirizzi IP RFC 1918: il traffico viene sempre instradato tramite una rete VPC autorizzata.
  • Indirizzi IP esterni instradabili su internet: il traffico viene sempre instradato a internet o all'indirizzo IP esterno di una risorsa Google Cloud .

A seconda della rete della destinazione di inoltro risolta, il traffico viene instradato tramite qualsiasi indirizzo IP interno, ad esempio un indirizzo privato RFC 1918, un indirizzo IP privato non RFC 1918 o un indirizzo IP esterno riutilizzato privatamente, ad eccezione di un indirizzo IP di destinazione di inoltro vietato: il traffico viene sempre instradato tramite una rete VPC autorizzata.

Se il server dei nomi DNS è stato risolto in un indirizzo IP esterno accessibile a internet o all'indirizzo IP esterno, il routing privato non è supportato.

Quando aggiungi la destinazione di inoltro alla zona di inoltro, puoi scegliere uno dei due metodi di routing seguenti:

  • Routing standard:esegue il routing del traffico tramite una rete VPC autorizzata o su internet in base al fatto che la destinazione di forwarding sia un indirizzo IP RFC 1918. Se il target di forwarding è un indirizzo IP RFC 1918, Cloud DNS classifica il target come di tipo 1 o 2 e instrada le richieste tramite una rete VPC autorizzata. Se la destinazione non è un indirizzo IP RFC 1918, Cloud DNS la classifica come tipo 3 e prevede che sia accessibile a internet.

  • Routing privato:esegue sempre il routing del traffico tramite una rete VPC autorizzata, indipendentemente dall'indirizzo IP di destinazione (RFC 1918 o meno). Di conseguenza, sono supportati solo i target di tipo 1 e 2.

Se utilizzi un FQDN per la destinazione di inoltro, il metodo di routing deve corrispondere al tipo di rete. Quando il server dei nomi del tuo dominio viene risolto in un indirizzo IP pubblico, devi utilizzare il routing standard.

Per accedere a una destinazione di forwarding di tipo 1 o di tipo 2, Cloud DNS utilizza le route nella rete VPC autorizzata in cui si trova il client DNS. Queste route definiscono un percorso sicuro verso la destinazione di inoltro:

Per ulteriori indicazioni sui requisiti di rete per i target di tipo 1 e 2, consulta Requisiti di rete dei target di inoltro.

Per accedere a una destinazione di forwarding di tipo 4, Cloud DNS risolve prima il nome di dominio, quindi utilizza il metodo di routing della rete di origine. Ad esempio, se subdomain.example.com viene risolto in un indirizzo IP di un sistema on-premise connesso alla rete VPC autorizzata a eseguire query sulla zona di inoltro tramite Cloud VPN, utilizza le stesse regole di routing di una destinazione di inoltro di tipo 2.

Quando utilizzi un FQDN come target di forwarding, puoi utilizzarne solo uno. La destinazione di inoltro può essere risolta in un massimo di 50 indirizzi IP.

Indirizzi IP di destinazione dell'inoltro vietati

Non puoi utilizzare i seguenti indirizzi IP per le destinazioni di inoltro di Cloud DNS:

  • 169.254.0.0/16
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 224.0.0.0/4
  • 240.0.0.0/4
  • ::1/128
  • ::/128
  • 2001:db8::/32
  • fe80::/10
  • fec0::/10
  • ff00::/8

Ordine di selezione del target di forwarding

Cloud DNS ti consente di configurare un elenco di destinazioni di inoltro per una zona di inoltro.

Quando configuri due o più target di forwarding, Cloud DNS utilizza un algoritmo interno per selezionare un target di forwarding. Questo algoritmo classifica ogni destinazione di inoltro.

Quando utilizzi un FQDN come target di forwarding, Cloud DNS risolve il nome di dominio in un insieme di massimo 50 indirizzi IP e poi applica lo stesso algoritmo a questi indirizzi IP.

Per elaborare una richiesta, Cloud DNS tenta prima una query DNS contattando la destinazione di inoltro con il ranking più alto. Se il server non risponde, Cloud DNS ripete la richiesta al successivo target di inoltro con il ranking più alto. Se nessuna destinazione di inoltro risponde, Cloud DNS sintetizza una risposta SERVFAIL.

L'algoritmo di ranking è automatico e i seguenti fattori aumentano il ranking di una destinazione di inoltro:

  • Maggiore è il numero di risposte DNS riuscite elaborate dalla destinazione di inoltro. Le risposte DNS riuscite includono le risposte NXDOMAIN.
  • Minore è la latenza (tempo di round trip) per la comunicazione con la destinazione di inoltro.

Utilizzare le zone di inoltro

Le VM in una rete VPC possono utilizzare una zona di inoltro Cloud DNS nei seguenti casi:

  • La rete VPC è stata autorizzata a utilizzare la zona di inoltro Cloud DNS. Per utilizzare la zona di inoltro, puoi autorizzare più reti VPC nello stesso progetto o in più progetti, a condizione che le reti VPC si trovino nella stessa organizzazione.

  • Il sistema operativo guest di ogni VM nella rete VPC utilizza il server metadati della VM 169.254.169.254 come server dei nomi.

Se utilizzi un nome di dominio completo come server dei nomi di destinazione, esamina i seguenti elementi:

  • Puoi avere un solo target di inoltro.
  • La risoluzione della destinazione FQDN tramite un'altra zona di forwarding non è supportata.
  • Non puoi utilizzare un FQDN come server dei nomi alternativo nei criteri del server.
  • Una destinazione FQDN può essere risolta in un massimo di 50 indirizzi IP associati. Gli indirizzi risolti oltre 50 vengono troncati.

Zone di inoltro sovrapposte

Poiché le zone di inoltro Cloud DNS sono un tipo di zona privata gestita Cloud DNS, puoi creare più zone che si sovrappongono. Le VM configurate come descritto in precedenza risolvono un record in base all'ordine di risoluzione dei nomi, utilizzando la zona con il suffisso più lungo. Per ulteriori informazioni, vedi Zone sovrapposte.

Zone di memorizzazione nella cache e di inoltro

Cloud DNS memorizza nella cache le risposte alle query inviate alle zone di inoltro di Cloud DNS. Cloud DNS gestisce una cache delle risposte delle destinazioni di inoltro raggiungibili per il periodo di tempo più breve tra i seguenti:

  • 60 secondi
  • La durata del durata (TTL) del record

Quando tutti i target di inoltro per una zona di inoltro diventano irraggiungibili, Cloud DNS mantiene la cache dei record richiesti in precedenza in quella zona per la durata del TTL di ogni record.

Quando utilizzare il peering

Cloud DNS non può utilizzare il routing transitivo per connettersi a una destinazione di inoltro. Per illustrare una configurazione non valida, considera lo scenario seguente:

  • Hai utilizzato Cloud VPN o Cloud Interconnect per connettere una rete on-premise a una rete VPC denominata vpc-net-a.

  • Hai utilizzato il peering di rete VPC per connettere la rete VPC vpc-net-a a vpc-net-b. Hai configurato vpc-net-a per esportare le route personalizzate e vpc-net-b per importarle.

  • Hai creato una zona di inoltro i cui target di inoltro si trovano nella rete on-premise a cui è connesso vpc-net-a. Hai autorizzato vpc-net-b a utilizzare questa zona di inoltro.

La risoluzione di un record in una zona gestita dalle destinazioni di inoltro non riesce in questo scenario, anche se esiste una connettività da vpc-net-b alla tua rete on-premise. Per dimostrare questo errore, esegui i seguenti test da una VM in vpc-net-b:

  • Esegui query sul server dei metadati della VM 169.254.169.254 per un record definito nella zona di inoltro. Questa query non va a buon fine (come previsto) perché Cloud DNS non supporta il routing transitivo alle destinazioni di inoltro. Per utilizzare una zona di inoltro, una VM deve essere configurata per utilizzare il proprio server di metadati.

  • Esegui una query sulla destinazione di forwarding direttamente per lo stesso record. Anche se Cloud DNS non utilizza questo percorso, questa query dimostra che la connettività transitiva ha esito positivo.

Puoi utilizzare una zona di peering Cloud DNS per risolvere questo scenario non valido:

  1. Crea una zona di peering Cloud DNS autorizzata per vpc-net-b che ha come target vpc-net-a.
  2. Crea una zona di inoltro autorizzata per vpc-net-a le cui destinazioni di inoltro sono server dei nomi on-premise.

Puoi eseguire questi passaggi in qualsiasi ordine. Dopo aver completato questi passaggi, le istanze Compute Engine sia in vpc-net-a che in vpc-net-b possono eseguire query sui target di inoltro on-premise.

Per informazioni su come creare zone di inoltro, vedi Creare una zona di inoltro.

Zone di peering

Una zona di peering è una zona privata Cloud DNS che consente di inviare richieste DNS tra zone Cloud DNS in reti VPC diverse. Ad esempio, un fornitore di software come servizio (SaaS) può concedere ai clienti l'accesso ai propri record DNS gestiti in Cloud DNS.

Per fornire il peering DNS, devi creare una zona di peering privato Cloud DNS e configurarla per eseguire ricerche DNS in una rete VPC in cui sono disponibili i record per lo spazio dei nomi della zona. La rete VPC in cui la zona di peering DNS esegue le ricerche è chiamata rete del produttore DNS.

La zona di peering è visibile solo alle reti VPC selezionate durante la configurazione della zona. La rete VPC autorizzata a utilizzare la zona di peering è denominata rete consumer DNS.

Una volta autorizzate le risorse Google Cloud nella rete consumer DNS, possono eseguire ricerche di record nello spazio dei nomi della zona di peering come se si trovassero nella rete producer DNS. Le ricerche di record nello spazio dei nomi della zona di peering seguono l'ordine di risoluzione dei nomi della rete del produttore DNS.

Pertanto,le risorse Google Cloud nella rete consumer DNS possono cercare record nello spazio dei nomi della zona dalle seguenti origini disponibili nella rete producer DNS:

  • Zone private gestite di Cloud DNS autorizzate per l'utilizzo da parte della rete del produttore DNS.
  • Zone di forwarding gestite di Cloud DNS autorizzate per l'utilizzo da parte della rete di produttori DNS.
  • Nomi DNS interni di Compute Engine nella rete del produttore DNS.
  • Un server dei nomi alternativo, se è stato configurato un criterio del server in uscita nella rete del produttore DNS.

Con il peering DNS, una rete (rete consumer DNS) può inoltrare le richieste DNS a un'altra rete (rete producer DNS), che esegue le ricerche DNS.

Limitazioni e punti chiave del peering DNS

Tieni presente quanto segue quando configuri il peering DNS:

  • Il peering DNS è una relazione unidirezionale. Consente alle risorse Google Cloud nella rete consumer DNS di cercare i record nello spazio dei nomi della zona di peering come se le risorse Google Cloud si trovassero nella rete producer DNS.
  • Le reti producer e consumer DNS devono essere reti VPC.
  • Sebbene le reti producer e consumer DNS facciano in genere parte della stessa organizzazione, è supportato anche il peering DNS tra organizzazioni.
  • Il peering DNS e il peering di rete VPC sono servizi diversi. Il peering di rete VPC non condivide automaticamente le informazioni DNS. Il peering DNS può essere utilizzato con il peering di rete VPC, ma il peering di rete VPC non è obbligatorio per il peering DNS.
  • Il peering DNS transitivo è supportato, ma solo tramite un singolo hop transitivo. In altre parole, non possono essere coinvolte più di tre reti VPC (con la rete intermedia che funge da hop transitivo). Ad esempio, puoi creare una zona di peering in vpc-net-a che ha come target vpc-net-b e poi creare una zona di peering in vpc-net-b che ha come target vpc-net-c.
  • Se utilizzi il peering DNS per scegliere come target una zona di inoltro mentre il routing dinamico globale è disattivato nella rete VPC del produttore, la rete VPC di destinazione con la zona di inoltro deve contenere una VM, un collegamento VLAN o un tunnel Cloud VPN che si trova nella stessa regione della VM di origine che utilizza la zona di peering DNS. Per informazioni dettagliate su questa limitazione, vedi Il forwarding delle query dalle VM in una rete VPC consumer a una rete VPC producer non funziona.

Per istruzioni su come creare una zona di peering, consulta Creazione di una zona di peering.

Zone di ricerca inversa gestite

Una zona di ricerca inversa gestita è una zona privata con un attributo speciale che indica a Cloud DNS di eseguire una ricerca PTR sui dati DNS di Compute Engine.

Record PTR per indirizzi RFC 1918 in zone private

Per eseguire ricerche inverse con record PTR personalizzati per indirizzi RFC 1918, devi creare una zona privata Cloud DNS specifica almeno quanto una delle seguenti zone di esempio. Ciò è una conseguenza della corrispondenza del suffisso più lungo descritta in Ordine di risoluzione dei nomi.

Ecco alcuni esempi di zone:

  • 10.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 16.172.in-addr.arpa., 17.172.in-addr.arpa., ... tramite 31.172.in-addr.arpa.

Se crei una zona privata Cloud DNS per gli indirizzi RFC 1918, i record PTR personalizzati che crei per le VM in quella zona vengono sostituiti dai record PTR creati automaticamente dal DNS interno. Questo perché i record PTR DNS interni vengono creati nell'elenco precedente di zone più specifiche.

Ad esempio, supponiamo di creare una zona privata gestita per in-addr.arpa. con il seguente record PTR per una VM il cui indirizzo IP è 10.1.1.1:

1.1.1.10.in-addr.arpa. -> test.example.domain

In questo esempio, il record PTR nella zona privata Cloud DNS per in-addr.arpa. viene ignorato. Qualsiasi query PTR per 1.1.1.10.in-addr.arpa. riceve risposta dalla zona DNS interna 10.in-addr.arpa. più specifica.

Per eseguire l'override dei record PTR DNS interni creati automaticamente per le VM, assicurati di creare i record PTR personalizzati in una zona privata specifica almeno quanto una delle zone presentate in questa sezione. Ad esempio, se crei il seguente record PTR in una zona privata per 10.in-addr.arpa., il record sostituisce quello generato automaticamente: 1.1.1.10.in-addr.arpa. -> test.example.domain.

Se devi eseguire l'override solo di una parte di un blocco di rete, puoi creare zone private Cloud DNS di ricerca inversa più specifiche. Ad esempio, una zona privata per 5.10.in-addr.arpa. può essere utilizzata per contenere record PTR che sostituiscono qualsiasi record PTR DNS interno creato automaticamente per le VM con indirizzi IP nell'intervallo di indirizzi 10.5.0.0/16.

Per istruzioni su come creare una zona di ricerca inversa gestita, consulta Creare una zona di ricerca inversa gestita.

Zone sovrapposte

Due zone si sovrappongono quando il nome di dominio di origine di una zona è identico a quello dell'origine dell'altra zona o è un sottodominio. Ad esempio:

  • Una zona per gcp.example.com e un'altra zona per gcp.example.com si sovrappongono perché i nomi di dominio sono identici.
  • Una zona per dev.gcp.example.com e una zona per gcp.example.com si sovrappongono perché dev.gcp.example.com è un sottodominio di gcp.example.com.

Regole per le zone sovrapposte

Cloud DNS applica le seguenti regole per le zone sovrapposte: * Le zone pubbliche sovrapposte non sono consentite sugli stessi server dei nomi Cloud DNS. Quando crei zone sovrapposte, Cloud DNS tenta di inserirle su server dei nomi diversi. Se non è possibile, Cloud DNS non riesce a creare la zona sovrapposta.

  • Una zona privata può sovrapporsi a qualsiasi zona pubblica.

  • Le zone private con ambito per reti VPC diverse possono sovrapporsi. Ad esempio, due reti VPC possono avere ciascuna una VM di database denominata database.gcp.example.com in una zona gcp.example.com. Le query per database.gcp.example.com ricevono risposte diverse a seconda dei record di zona definiti nella zona autorizzata per ogni rete VPC.

  • Due zone private autorizzate ad essere accessibili dalla stessa rete VPC non possono avere origini identiche, a meno che una zona non sia un sottodominio dell'altra. Il server dei metadati utilizza la corrispondenza del suffisso più lungo per determinare quale origine interrogare per i record in una determinata zona.

Esempi di risoluzione delle query

Google Cloud risolve le zone Cloud DNS come descritto in Ordine di risoluzione dei nomi. Quando determina la zona da interrogare per un determinato record, Cloud DNS tenta di trovare una zona che corrisponda il più possibile al record richiesto (corrispondenza del suffisso più lungo).

A meno che tu non abbia specificato un server dei nomi alternativo in un criterio del server in uscita, Google Cloud il primo tentativo di trovare un record in una zona privata (o in una zona di inoltro o di peering) autorizzata per la tua rete VPC prima di cercare il record in una zona pubblica. I seguenti esempi illustrano l'ordine utilizzato dal server dei metadati durante l'interrogazione dei record DNS. Per ciascuno di questi esempi, supponiamo di aver creato due zone private, gcp.example.com e dev.gcp.example.com, e di aver autorizzato l'accesso da parte della stessa rete VPC. Google Cloud gestisce le query DNS dalle VM in una rete VPC nel seguente modo:

  • Il server dei metadati utilizza i nameserver pubblici per risolvere un record per myapp.example.com. (nota il punto finale) perché non esiste una zona privata per example.com che sia stata autorizzata per la rete VPC. Utilizza dig da una VM di Compute Engine per eseguire query sul server dei nomi predefinito della VM:

    dig myapp.example.com.

    Per i dettagli, vedi Eseguire query per il nome DNS utilizzando il server dei metadati.

  • Il server dei metadati risolve il record myapp.gcp.example.com utilizzando la zona privata autorizzata gcp.example.com perché gcp.example.com è il suffisso comune più lungo tra il nome del record richiesto e le zone private autorizzate disponibili. NXDOMAIN viene restituito se non è presente alcun record per myapp.gcp.example.com definito nella zona privata gcp.example.com, anche se è presente un record per myapp.gcp.example.com definito in una zona pubblica.

  • Analogamente, le query per myapp.dev.gcp.example.com vengono risolte in base ai record nella zona privata autorizzata dev.gcp.example.com. NXDOMAIN viene restituito se non esiste un record per myapp.dev.gcp.example.com nella zona dev.gcp.example.com, anche se esiste un record per myapp.dev.gcp.example.com in un'altra zona privata o pubblica.

  • Le query per myapp.prod.gcp.example.com vengono risolte in base ai record nella zona privata gcp.example.com perché gcp.example.com è il suffisso comune più lungo tra il record DNS richiesto e le zone private disponibili.

Esempio di DNS split horizon

Puoi utilizzare una combinazione di zone pubbliche e private in una configurazione DNS split horizon. Le zone private ti consentono di definire risposte diverse a una query per lo stesso record quando la query ha origine da una VM all'interno di una rete VPC autorizzata. Il DNS split horizon è utile quando devi fornire record diversi per le stesse query DNS a seconda della rete VPC di origine.

Considera il seguente esempio di split horizon:

  • Hai creato una zona pubblica, gcp.example.com, e hai configurato il suo registrar per utilizzare i server dei nomi di Cloud DNS.
  • Hai creato una zona privata, gcp.example.com, e hai autorizzato la tua rete VPC ad accedere a questa zona.

Nella zona privata, hai creato un singolo record come mostrato nella tabella seguente.

Registra Tipo TTL (secondi) Dati
myrecord1.gcp.example.com A 5 10.128.1.35

Nella zona pubblica hai creato due record.

Registra Tipo TTL (secondi) Dati
myrecord1.gcp.example.com A 5 104.198.6.142
myrecord2.gcp.example.com A 50 104.198.7.145

Le seguenti query vengono risolte come descritto:

  • Una query per myrecord1.gcp.example.com da una VM nella tua rete VPC restituisce 10.128.1.35.
  • Una query per myrecord1.gcp.example.com da internet restituisce 104.198.6.142.
  • Una query per myrecord2.gcp.example.com da una VM nella tua rete VPC restituisce un errore NXDOMAIN perché non esiste alcun record per myrecord2.gcp.example.com nella zona privata gcp.example.com.
  • Una query per myrecord2.gcp.example.com da internet restituisce 104.198.7.145.

Associazione tra progetti

Il binding tra progetti consente di mantenere la proprietà dello spazio dei nomi DNS del progetto di servizio indipendente dalla proprietà dello spazio dei nomi DNS dell'intera rete VPC.

Una configurazione tipica di VPC condiviso prevede progetti di servizio che acquisiscono la proprietà di un'applicazione o di servizi di macchine virtuali (VM), mentre il progetto host acquisisce la proprietà della rete VPC e dell'infrastruttura di rete. Spesso, uno spazio dei nomi DNS viene creato dallo spazio dei nomi della rete VPC per corrispondere alle risorse del progetto di servizio. Per una configurazione di questo tipo, può essere più facile delegare l'amministrazione dello spazio dei nomi DNS di ogni progetto di servizio agli amministratori di ogni progetto di servizio (che spesso sono reparti o attività diversi). Il binding tra progetti consente di separare la proprietà dello spazio dei nomi DNS del progetto di servizio dalla proprietà dello spazio dei nomi DNS dell'intera rete VPC.

La figura seguente mostra una tipica configurazione VPC condiviso con peering DNS.

Una configurazione di VPC condiviso con peering DNS.
Configurazione di un VPC condiviso con peering DNS (fai clic per ingrandire)

La figura seguente mostra una configurazione che utilizza il binding tra progetti. Cloud DNS consente a ogni progetto di servizio di creare e possedere le proprie zone DNS, ma di associarle comunque alla rete condivisa di proprietà del progetto host. Ciò consente una maggiore autonomia e un limite di autorizzazione più preciso per l'amministrazione delle zone DNS.

Una configurazione con associazione tra progetti.
Una configurazione con binding tra progetti (fai clic per ingrandire)

L'associazione tra progetti fornisce quanto segue:

  • Gli amministratori e gli utenti dei progetti di servizio possono creare e gestire le proprie zone DNS.
  • Non è necessario creare una rete VPC segnaposto.
  • Gli amministratori del progetto host non devono gestire il progetto di servizio.
  • I ruoli IAM si applicano ancora a livello di progetto.
  • Tutte le zone DNS sono associate direttamente alla rete VPC condiviso.
  • La risoluzione DNS any-to-any è facilmente disponibile. Qualsiasi VM nella rete VPC condiviso può risolvere le zone associate.
  • Non esiste un limite di hop transitivi. Puoi gestirlo in una struttura hub and spoke.

Per istruzioni su come creare una zona con l'associazione tra progetti abilitata, consulta Creazione di una zona di associazione tra progetti.

Zone Cloud DNS di zona

Cloud DNS di zona ti consente di creare zone DNS private con ambito limitato a una Google Cloud zona. Le zone Cloud DNS zonali vengono create per GKE quando scegli un ambito cluster.

Il servizio Cloud DNS predefinito è globale e i nomi DNS sono visibili a livello globale all'interno della rete VPC. Questa configurazione espone il tuo servizio a interruzioni globali. Cloud DNS zonale è un nuovo servizio Cloud DNS privato che esiste all'interno di ogni zona Google Cloud . Il dominio in errore è contenuto in quella zona Google Cloud . Le zone private Cloud DNS a livello di zona non sono interessate quando si verificano interruzioni globali. Eventuali interruzioni Google Cloud zonali interessano solo quella Google Cloud zona specifica e le zone Cloud DNS all'interno di quella Google Cloud zona. Tieni presente che qualsiasi risorsa creata in un servizio zonale è visibile solo a quella Google Cloud zona.

Per scoprire come configurare una zona con ambito cluster Cloud DNS zonale, consulta Configurare una zona con ambito cluster GKE zonale.

Supporto di Cloud DNS di zona

La tabella seguente elenca le risorse e le funzionalità di Cloud DNS supportate dai servizi Cloud DNS zonali.

Risorsa o funzionalità Disponibile su Cloud DNS globale Disponibile su Cloud DNS di zona
Zone pubbliche gestite
Zone private gestite (ambito di rete o VPC)
Zone private gestite (ambito GKE)
Zone di inoltro1
Zone di peering
Zone di ricerca inversa gestite
Creare modifiche o gestire record2
Zone di Service Directory
Norme
Policy di risposta (ambito di rete)
Policy di risposta (ambito del cluster GKE)
Regole del criterio di risposta

1Cloud DNS zonale supporta solo le zone di forwarding con ambito limitato a un cluster GKE.

2Il controller GKE sovrascrive le modifiche ai record al riavvio.

Fatturazione delle zone Cloud DNS zonali

La fatturazione per le zone Cloud DNS e le norme di risposta a livello di zona funziona allo stesso modo delle controparti globali.

Passaggi successivi