Panoramica delle zone DNS

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

Zone di inoltro

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

Una zona di forwarding di Cloud DNS è un tipo speciale di zona privata di Cloud DNS. Anziché creare record all'interno della zona, puoi specificare un insieme di destinazioni di inoltro. Ogni destinazione di forwarding è un indirizzo IP di un server DNS, posizionato nella tua rete VPC o in una rete on-premise connessa alla rete VPC da Cloud VPN o Cloud Interconnect.

Target di forwarding e metodi di routing

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

Destinazione di forwarding Descrizione Il routing standard supporta Il routing privato supporta Origine delle richieste
Tipo 1 Un indirizzo IP interno di una VM Google Cloud o un bilanciatore del carico di rete passthrough interno nella stessa rete VPC autorizzata a utilizzare la zona di forwarding. Solo indirizzi IP RFC 1918: traffico sempre instradato attraverso 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 forwarding vietato, il traffico sempre instradato attraverso 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: traffico sempre instradato attraverso 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 forwarding vietato: il traffico viene sempre instradato attraverso 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 con routing a internet; traffico sempre instradato verso internet o verso l'indirizzo IP esterno di una risorsa Google Cloud. Il routing privato non è supportato. Assicurati che non sia selezionato. Intervalli di origine DNS pubblico di Google

Puoi scegliere uno dei due seguenti metodi di routing quando aggiungi la destinazione di inoltro alla zona di inoltro:

  • Routing standard:instrada il traffico attraverso una rete VPC autorizzata o su internet a seconda che la destinazione di inoltro sia un indirizzo IP RFC 1918. Se la destinazione di inoltro è un indirizzo IP RFC 1918, Cloud DNS classifica la destinazione come target di Tipo 1 o Tipo 2 e instrada le richieste attraverso una rete VPC autorizzata. Se la destinazione non è un indirizzo IP RFC 1918, Cloud DNS classifica la destinazione come Tipo 3 e si aspetta che la destinazione sia accessibile da internet.

  • Routing privato:instrada sempre il traffico attraverso una rete VPC autorizzata, indipendentemente dall'indirizzo IP di destinazione (RFC 1918 o meno). Di conseguenza, sono supportate solo le destinazioni di tipo Tipo 1 e Tipo 2.

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

Per ulteriori indicazioni sui requisiti di rete per i target di tipo Tipo 1 e Tipo 2, consulta la pagina relativa ai requisiti di rete di destinazione dell'inoltro.

Indirizzi IP di destinazione dell'inoltro vietati

Non puoi utilizzare i seguenti indirizzi IP per i target di forwarding 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 della destinazione di forwarding

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

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

Per elaborare una richiesta, Cloud DNS prova innanzitutto a eseguire una query DNS contattando la destinazione di forwarding con il ranking più elevato. Se il server non risponde, Cloud DNS ripete la richiesta alla successiva destinazione di forwarding 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 un target 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.

Usa zone di inoltro

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

  • La rete VPC è stata autorizzata a usare la zona di forwarding di Cloud DNS. Puoi autorizzare più reti VPC nello stesso progetto a usare la zona di inoltro.
  • Il sistema operativo guest di ogni VM nella rete VPC utilizza il server di metadati della VM 169.254.169.254 come server dei nomi.

Zone di inoltro sovrapposte

Poiché le zone di forwarding di Cloud DNS sono un tipo di zona privata gestita di 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, consulta la sezione Zone sovrapposte.

Zone per memorizzazione nella cache e inoltro

Cloud DNS memorizza nella cache le risposte per le query inviate alle zone di forwarding di Cloud DNS. Cloud DNS gestisce una cache delle risposte da destinazioni di forwarding raggiungibili per intervalli di tempo più brevi dei seguenti:

  • 60 secondi
  • La durata (TTL) del record

Quando tutte le destinazioni di forwarding di una zona di forwarding diventano irraggiungibili, Cloud DNS conserva la cache dei record richiesti in precedenza in quella zona per la durata del TTL di ciascun record.

Quando utilizzare il peering

Cloud DNS non può utilizzare il routing transitivo per connettersi a una destinazione di forwarding. 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 le cui destinazioni di inoltro si trovano nella rete on-premise a cui è connesso vpc-net-a. Hai autorizzato vpc-net-b a utilizzare la zona di inoltro.

La risoluzione di un record in una zona gestita dalle destinazioni di forwarding ha esito negativo in questo scenario, anche se è presente 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 una query sul server di metadati della VM 169.254.169.254 per un record definito nella zona di forwarding. Questa query non va a buon fine (previsto) perché Cloud DNS non supporta il routing transitivo alle destinazioni di forwarding. Per utilizzare una zona di forwarding, una VM deve essere configurata in modo da utilizzare il relativo server di metadati.

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

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

  1. Crea una zona di peering Cloud DNS autorizzata per vpc-net-b che abbia 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 di Compute Engine in vpc-net-a e vpc-net-b possono eseguire query sulle destinazioni di forwarding on-premise.

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

Zone di peering

Il peering DNS consente di inviare richieste per i record provenienti dallo spazio dei nomi di una zona a un'altra rete VPC. Ad esempio, un provider SaaS può concedere a un cliente SaaS l'accesso ai record DNS che gestisce.

Per fornire il peering DNS, devi creare una zona di peering Cloud DNS e configurarla in modo che esegua ricerche DNS in una rete VPC in cui sono disponibili i record per lo spazio dei nomi di quella zona. La rete VPC in cui la zona di peering DNS esegue le ricerche è denominata rete del producer 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 del producer DNS. Le ricerche di record nello spazio dei nomi della zona di peering seguono l'ordine di risoluzione dei nomi della rete del producer DNS.

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

  • Zone private gestite di Cloud DNS autorizzate all'uso dalla rete del producer DNS.
  • Zone di forwarding gestite di Cloud DNS autorizzate a essere utilizzate dalla rete del producer DNS.
  • Nomi DNS interni di Compute Engine nella rete del producer DNS.
  • Un server dei nomi alternativo, se nella rete del producer DNS è stato configurato un criterio del server in uscita.

Limitazioni e punti chiave del peering DNS

Quando configuri il peering DNS, tieni presente quanto segue:

  • Il peering DNS è una relazione unidirezionale. Consente alle risorse Google Cloud nella rete consumer DNS di cercare record nello spazio dei nomi della zona di peering come se le risorse Google Cloud si trovassero nella rete del producer DNS.
  • Le reti producer e consumer DNS devono essere reti VPC.
  • Sebbene le reti di producer e consumer DNS in genere facciano 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 DNS può essere utilizzato con il peering di rete VPC, ma il peering di rete VPC non è necessario per il peering DNS.
  • Il peering DNS transitivo è supportato, ma solo attraverso un singolo hop transitivo. In altre parole, non possono essere coinvolte più di tre reti VPC (la rete al centro è l'hop transitivo). Ad esempio, puoi creare una zona di peering in vpc-net-a che abbia come target vpc-net-b e quindi creare una zona di peering in vpc-net-b che abbia come target vpc-net-c.
  • Se utilizzi il peering DNS per scegliere come target una zona di forwarding, la rete VPC di destinazione con la zona di forwarding deve contenere una VM, un collegamento VLAN o un tunnel Cloud VPN situato nella stessa regione della VM di origine che utilizza la zona di peering DNS. Per maggiori dettagli su questa limitazione, consulta Inoltro di query dalle VM in una rete VPC consumer a una rete VPC del produttore non funzionante.

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

Zone di ricerca inversa gestite

Una zona gestita di ricerca inversa è 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 gli indirizzi RFC 1918 nelle zone private

Per eseguire ricerche inverse con record PTR personalizzati per gli indirizzi RFC 1918, devi creare una zona privata di Cloud DNS specifica almeno quanto una delle zone di esempio seguenti. Questa è la conseguenza della corrispondenza del suffisso più lunga descritta nell'articolo Ordine di risoluzione dei nomi.

Ecco di seguito alcune zone di esempio:

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

Se crei una zona privata di 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 delle zone più specifiche.

Ad esempio, supponi 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

Le query PTR per 1.1.1.10.in-addr.arpa. ricevono risposta dalla zona DNS interna 10.in-addr.arpa. più specifica. Il record PTR nella zona privata di Cloud DNS per test.example.domain viene ignorato.

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 che sia 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 solo l'override di una parte di un blocco di rete, puoi creare zone private Cloud DNS inverse più specifiche. Ad esempio, è possibile utilizzare una zona privata per 5.10.in-addr.arpa. per conservare i record PTR che eseguono l'override di 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 gestita di ricerca inversa, consulta Creare una zona gestita di ricerca inversa.

Zone sovrapposte

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

  • Una zona per gcp.example.com e un'altra 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 zone sovrapposte

Cloud DNS applica le seguenti regole per le zone sovrapposte:

  • Non sono consentite zone pubbliche sovrapposte sugli stessi server dei nomi Cloud DNS. Quando crei zone sovrapposte, Cloud DNS tenta di collocarle su server dei nomi diversi. Se ciò 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 di reti VPC diverse possono sovrapporsi tra loro. Ad esempio, due reti VPC possono avere ciascuna una VM del database denominata database.gcp.example.com in una zona gcp.example.com. Le query per database.gcp.example.com ricevono risposte diverse in base ai record di zona definiti nella zona autorizzata per ciascuna 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 di metadati utilizza la corrispondenza del suffisso più lunga per determinare l'origine su cui eseguire query 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. Durante la determinazione della zona su cui eseguire query per un determinato record, Cloud DNS prova a trovare una zona che corrisponda alla maggior parte del record richiesto (corrispondenza del suffisso più lunga).

A meno che tu non abbia specificato un server dei nomi alternativo in un criterio del server in uscita, Google Cloud tenta innanzitutto di trovare un record in una zona privata (o in una zona di inoltro o in una zona di peering) autorizzata per la tua rete VPC prima di cercarlo in una zona pubblica.

I seguenti esempi illustrano l'ordine utilizzato dal server di metadati durante l'esecuzione di query sui record DNS. Per ognuno di questi esempi, supponi di aver creato due zone private, gcp.example.com e dev.gcp.example.com, e di aver autorizzato l'accesso a queste zone dalla stessa rete VPC. Google Cloud gestisce le query DNS dalle VM in una rete VPC nel modo seguente:

  • Il server dei metadati utilizza i server dei nomi 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. Usa dig da una VM di Compute Engine per eseguire query sul server dei nomi predefinito della VM:

    dig myapp.example.com.

    Per maggiori dettagli, consulta Query per il nome DNS utilizzando il server di metadati.

  • Il server di 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. Viene restituito NXDOMAIN se non è presente alcun record per myapp.gcp.example.com definito nella zona privata gcp.example.com, anche se esiste un record per myapp.gcp.example.com definito in una zona pubblica.

  • Allo stesso modo, 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 è presente alcun 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 con orizzonte di suddivisione

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

Considera il seguente esempio di orizzonte di suddivisione:

  • Hai creato una zona pubblica, gcp.example.com, e hai configurato il suo registrar per l'utilizzo dei 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 illustrato nella tabella seguente.

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

Nella zona pubblica hai creato due record.

Record 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 è presente 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

L'associazione 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 tipica configurazione di un VPC condiviso contiene progetti di servizio che prendono la proprietà di un'applicazione o di servizi per una macchina virtuale (VM), mentre il progetto host assume 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 questa configurazione, può essere più semplice delegare l'amministrazione dello spazio dei nomi DNS di ogni progetto di servizio agli amministratori di ciascun progetto di servizio (che sono spesso reparti o aziende diversi). L'associazione 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 di un VPC condiviso con peering DNS.

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

La figura seguente mostra una configurazione che utilizza l'associazione tra progetti. Cloud DNS consente a ciascun progetto di servizio di creare e possedere le proprie zone DNS, ma di rimanere comunque associato alla rete condivisa di proprietà del progetto host. Ciò consente una migliore autonomia e un confine di autorizzazioni più preciso per l'amministrazione delle zone DNS.

Una configurazione con associazione tra progetti.
Una configurazione con associazione 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 continuano a essere applicati a livello di progetto.
  • Tutte le zone DNS sono direttamente associate alla rete VPC condiviso.
  • La risoluzione DNS da qualsiasi a scelta è immediatamente disponibile. Qualsiasi VM nella rete VPC condiviso può risolvere le zone associate.
  • Non è previsto alcun limite di hop transitivo. Puoi gestirlo in un design hub and spoke.

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

Zone Cloud DNS di zona

Cloud DNS a livello di zona consente di creare zone DNS private che hanno come ambito solo una zona Google Cloud. Le zone Cloud DNS di zona vengono create per GKE quando scegli un ambito cluster.

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

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

Assistenza Cloud DNS a livello di zona

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

Risorsa o caratteristica Disponibile su Cloud DNS globale Disponibile su Cloud DNS a livello di zona
Zone pubbliche gestite
Zone private gestite (con ambito di rete o VPC)
Zone private gestite (con ambito GKE)
Zone di inoltro1
Zone di peering
Zone di ricerca inversa gestite
Creazione di modifiche o gestione dei record2
Zone Service Directory
Criteri
Criteri di risposta (ambito rete)
Criteri di risposta (con ambito cluster GKE)
Regole del criterio di risposta

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

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

Fatturazione per le zone Cloud DNS a livello di zona

La fatturazione per le zone e i criteri di risposta Cloud DNS a livello di zona funziona come per le controparti globali.

Passaggi successivi