Panoramica delle zone DNS

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

Zone di inoltro

Le zone di forwarding di Cloud DNS 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 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 destinazione per il reindirizzamento. Ogni destinazione di inoltro è un indirizzo IP di un server DNS, situato nella rete VPC o in una rete on-premise collegata alla rete VPC tramite Cloud VPN o Cloud Interconnect.

Target di forwarding e metodi di routing

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

Destinazione di forwarding Descrizione Supporto del routing standard Supporto per il routing privato Origine delle richieste
Tipo 1 Un indirizzo IP interno di una VM Google Cloud o di un Network Load Balancer passthrough interno nella stessa rete VPC autorizzata a utilizzare la zona di inoltro. Solo indirizzi IP RFC 1918: traffico sempre instradato una rete VPC autorizzata. Qualsiasi indirizzo IP interno, ad esempio un indirizzo privato RFC 1918, un indirizzo non RFC indirizzi IP privati 1918 o indirizzi IP esterni riutilizzati privatamente, ad eccezione di Per un indirizzo IP di destinazione di forwarding vietato : traffico sempre instradato tramite un VPC autorizzato in ogni rete. 35.199.192.0/19
Tipo 2 L'indirizzo IP di un sistema on-premise, connesso Rete VPC autorizzata a eseguire query sulla zona di inoltro utilizzando Cloud VPN o Cloud Interconnect. Solo indirizzi IP RFC 1918: traffico sempre instradato una rete VPC autorizzata. Qualsiasi indirizzo IP interno, ad esempio un indirizzo privato RFC 1918, un indirizzo non RFC indirizzi IP privati 1918 o indirizzi IP esterni riutilizzati privatamente, ad eccezione di Per un indirizzo IP di destinazione di forwarding vietato — traffico sempre instradato tramite un VPC autorizzato in ogni rete. 35.199.192.0/19
Tipo 3 Un indirizzo IP esterno di un server 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 a verso internet o all'indirizzo IP esterno di una risorsa Google Cloud. Il routing privato non è supportato. Assicurati che il routing privato non sia selezionato. Intervalli di origine DNS pubblico di Google

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

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

  • Routing privato:instrada sempre il traffico attraverso una rete Rete VPC, 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 forwarding di tipo Type 1 o Type 2, Cloud DNS utilizza nella rete VPC autorizzata in cui si trova individuarlo. Queste route definiscono un percorso sicuro per la destinazione di inoltro:

Per ulteriori indicazioni sui requisiti di rete per i target di tipo 1 e tipo 2, consulta i requisiti della rete di destinazione per il forwarding.

Indirizzi IP di destinazione dell'inoltro vietati

Non puoi utilizzare i seguenti indirizzi IP come destinazione per il 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 inoltro

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

Quando configuri due o più destinazioni di inoltro, Cloud DNS utilizza un algoritmo interno per selezionare una destinazione di inoltro. Questo algoritmo assegna un ranking a ogni destinazione di inoltro.

Per elaborare una richiesta, Cloud DNS prova prima una query DNS contattando la destinazione di inoltro con il la classificazione. Se il server non risponde, Cloud DNS ripete la richiesta al successivo target di inoltro con il ranking più alto. In caso contrario risposta target di forwarding, Cloud DNS sintetizza un SERVFAIL la risposta corretta.

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 target di forwarding. Risposte DNS riuscite includono le risposte di NXDOMAIN.
  • Minore è la latenza (tempo di andata e ritorno) 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 all'interno della stessa organizzazione.

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

Zone di inoltro sovrapposte

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

Zone di memorizzazione nella cache e di inoltro

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

  • 60 secondi
  • La durata (TTL) del record

Quando tutti i target di inoltro per una zona di inoltro diventano non raggiungibili, Cloud DNS mantiene 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 un forwarding target. Per illustrare una configurazione non valida, considera quanto segue: :

  • Hai utilizzato Cloud VPN o Cloud Interconnect per connettere un da 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 servita dalle destinazioni di inoltro non riesce in questo anche se è presente connettività da vpc-net-b alla tua rete on-premise in ogni rete. Per dimostrare questo errore, esegui i seguenti test da un VM in vpc-net-b:

  • Esegui una query sul server di metadati 169.254.169.254 della VM per un record definito nella zona di inoltro. Questa query ha esito negativo (previsto) perché Cloud DNS non supporta il routing transitivo verso le destinazioni di forwarding. Per utilizzare una zona di inoltro, una VM deve essere configurata per utilizzare il proprio server di metadati.

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

Per risolvere questo problema puoi utilizzare una zona di peering di Cloud DNS 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 sia in vpc-net-b possono eseguire query sui target di inoltro on-premise.

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

Zone di peering

Il peering DNS ti consente di inviare richieste per i record provenienti dall'ambito di 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 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 che selezionate durante la configurazione della zona. La rete VPC autorizzata a utilizzare la zona di peering è chiamata rete consumer DNS.

Dopo che le risorse Google Cloud nella rete del consumatore DNS sono state autorizzate, possono eseguire ricerche di record nello spazio dei nomi della zona di peering come se si trovassero nella rete del produttore DNS. Esegue ricerche di record nella zona di peering segue l'ordine di risoluzione dei nomi della rete del producer DNS.

Di conseguenza, le risorse Google Cloud nella rete consumer DNS possono record nello spazio dei nomi della zona dalle seguenti origini disponibili nel DNS rete di produttori:

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

Limitazioni e punti chiave del peering DNS

Tieni presente quanto segue durante la configurazione del peering DNS:

  • Il peering DNS è una relazione unidirezionale. Consente alle risorse Google Cloud nella rete del consumatore DNS di cercare record nello spazio dei nomi della zona di peering come se le risorse Google Cloud si trovassero nella rete del produttore DNS.
  • Le reti producer e consumer DNS devono essere reti VPC.
  • Sebbene le reti producer e consumer DNS in genere facciano parte della stessa è supportato anche il peering DNS tra organizzazioni.
  • Il peering DNS e il peering di rete VPC sono diversi i servizi di machine learning. 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 più di tre reti VPC (con il (l'hop transitivo) può essere coinvolto. Ad esempio: puoi creare una zona di peering in vpc-net-a che abbia come target vpc-net-b, e quindi crea 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 inoltro, la rete VPC di destinazione con la zona di inoltro 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 per maggiori dettagli su questa limitazione, consulta l'articolo sull'inoltro di query dalle VM in un da una rete VPC a una rete VPC del producer funziona.

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 in Compute Engine Dati DNS.

Record PTR per gli indirizzi RFC 1918 nelle zone private

Per eseguire ricerche in ordine inverso con record PTR personalizzati per gli indirizzi RFC 1918, devi creare una zona privata Cloud DNS almeno specifica quanto una delle seguenti zone di esempio. Questa è una conseguenza della corrispondenza del suffisso più lungo descritta in 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., ... fino a 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, 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

Alle query PTR per 1.1.1.10.in-addr.arpa. viene inviata la risposta 10.in-addr.arpa. zona DNS interna. Il record PTR nella zona privata Cloud DNS per test.example.domain viene ignorato.

Per eseguire l'override del PTR DNS interno creato automaticamente. per le VM, assicurati di creare i record PTR personalizzati in un specifica di almeno 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 tuo record sostituisce quello generato automaticamente: 1.1.1.10.in-addr.arpa. -> test.example.domain.

Se devi sostituire solo una parte di un blocco di rete, puoi creare zone private Cloud DNS inverse più specifiche. Ad esempio, un privato per 5.10.in-addr.arpa. può essere utilizzata per conservare record PTR che eseguono l'override di qualsiasi record PTR DNS interni creati 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 l'articolo Creare una zona gestita gestita.

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. Per esempio:

  • Una zona per gcp.example.com e un'altra zona per gcp.example.com di sovrapposizione 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 sullo stesso nome Cloud DNS server web. Quando crei zone sovrapposte, Cloud DNS tenta di metterle 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 per reti VPC diverse possono sovrapporsi tra loro. Ad esempio, due reti VPC possono avere ciascuna una VM 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 ogni rete VPC.

  • Due zone private che sono state 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ù lungo per determinare l'origine per cui eseguire query sui 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. Nel determinare la zona su cui eseguire query per un determinato record, Cloud DNS cerca di trovare una zona che corrisponda al maggior numero possibile di dati del record richiesto (corrispondenza del suffisso più lungo).

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

Gli esempi seguenti illustrano l'ordine utilizzato dal server dei metadati quando esegue query sui record DNS. Per ognuno di questi esempi, supponiamo di aver creato due zone private, gcp.example.com e dev.gcp.example.com e con autorizzazioni e accedervi dalla stessa rete VPC. Google Cloud gestisce le query DNS dalle VM in una rete VPC nel seguente modo:

  • Il server dei metadati utilizza server dei nomi pubblici per risolvere un record relativo a myapp.example.com. (nota il punto finale) perché non esiste un privato zona per example.com che è stata autorizzata per il VPC in ogni rete. Usa l'elemento dig di una VM di Compute Engine per eseguire query sull'impostazione predefinita della VM server dei nomi:

    dig myapp.example.com.

    Per maggiori dettagli, consulta la sezione Eseguire una query per il nome DNS utilizzando il server dei metadati.

  • Il server dei metadati risolve il record myapp.gcp.example.com utilizzando la gcp.example.com zona privata autorizzata perché gcp.example.com è il sufisso comune più lungo tra il nome del record richiesto e le gcp.example.com zone private autorizzate disponibili. NXDOMAIN viene restituito se non esiste un 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.

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

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

Esempio di DNS a livello orizzontale suddiviso

Puoi utilizzare una combinazione di zone pubbliche e private in un DNS ad orizzonte diviso configurazione. Le zone private ti 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 a 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 ne hai configurato la per utilizzare i server dei nomi 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 di seguito tabella.

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 nel tuo VPC la rete restituisce 10.128.1.35.
  • Una query su myrecord1.gcp.example.com da internet restituisce 104.198.6.142.
  • Una query per myrecord2.gcp.example.com da una VM nella 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.

Associatione tra progetti

L'associazione tra progetti ti consente di mantenere la proprietà del Spazio dei nomi DNS del progetto di servizio indipendente dalla proprietà del DNS dell'intera rete VPC.

Una tipica configurazione di un VPC condiviso contiene progetti di servizio che assumono la proprietà di un per l'applicazione o i servizi di una macchina virtuale (VM), mentre il progetto host la proprietà della rete VPC e dell'infrastruttura di rete. Spesso, viene creato uno spazio dei nomi DNS dallo spazio dei nomi che corrispondano 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 (spesso reparti o attività diversi). L'associazione tra progetti ti consente di separare la proprietà del Spazio dei nomi DNS del progetto di servizio dalla proprietà dello spazio dei nomi DNS di dell'intera rete VPC.

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

Una configurazione di VPC condiviso con peering DNS.
Una configurazione di 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 confine delle autorizzazioni più preciso per la gestione delle zone DNS.

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

L'associazione tra progetti offre quanto segue:

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

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

Zone Cloud DNS di zona

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

Il servizio Cloud DNS predefinito è di natura globale e i nomi DNS sono visibili a livello globale nella tua rete VPC. Questa configurazione espone il tuo servizio a interruzioni globali. Cloud DNS di zona è un nuovo servizio Cloud DNS privato che esiste all'interno di ogni zona Google Cloud. Il dominio in errore è contenuto nella zona Google Cloud. Le zone private Cloud DNS zonali non sono interessate in caso di interruzioni globali. Qualsiasi ambiente Google Cloud le interruzioni interessano solo quella specifica zona Google Cloud zone Cloud DNS all'interno di quella zona Google Cloud. Tieni presente che qualsiasi risorsa creata in un servizio di zona è visibile solo a quel determinato servizio Google Cloud zona di destinazione.

Per scoprire come configurare una zona Cloud DNS basata su cluster di zona, consulta Configurare una zona basata su cluster GKE di zona.

Supporto di Cloud DNS zonale

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

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
Creare modifiche o gestire i record2
Zone Service Directory
Criteri
Criteri di risposta (a livello di rete)
Criteri di risposta (con ambito cluster GKE)
Regole del criterio di risposta

1Cloud DNS zonale supporta solo le zone di inoltro limitate a un cluster GKE.

2Il 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 allo stesso modo. rispetto alle controparti globali.

Passaggi successivi