Panoramica delle zone DNS

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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

Zone di inoltro

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

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

Target di inoltro e metodi di routing

Cloud DNS supporta tre tipi di target e offre metodi standard o privati per instradare il traffico verso di essi.

Target di inoltro Descrizione Routing standard supportato Supporta il routing privato Origine delle richieste
Tipo 1 Un indirizzo IP interno di una VM Google Cloud o un bilanciatore del carico TCP/UDP 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, inclusi indirizzi IP privati non RFC 1918 e indirizzi IP pubblici riutilizzati privatamente, traffico 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, inclusi indirizzi IP privati non RFC 1918 e indirizzi IP pubblici riutilizzati privatamente, traffico 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 oppure l'indirizzo IP esterno di una risorsa di Google Cloud, ad esempio l'indirizzo IP esterno di una VM in un'altra rete VPC. Solo indirizzi IP esterni instradabili a Internet: il traffico è sempre instradato a 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 di Google Public DNS

Cloud DNS non consente di definire indirizzi IP che appartengono ai seguenti intervalli come server DNS di destinazione:

  • 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

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

  • Routing standard: instrada il traffico attraverso una rete VPC autorizzata o su Internet, a seconda che il target di forwarding sia un indirizzo IP RFC 1918. Se il target di forwarding è un indirizzo IP RFC 1918, Cloud DNS classifica il target come target di Tipo 1 o Tipo 2 e instrada le richieste tramite una rete VPC autorizzata. Se il target non è un indirizzo IP RFC 1918, Cloud DNS classifica il target come Tipo 3 e prevede che il target sia accessibile a 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 supportati solo i target Tipo 1 e Tipo 2.

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

Per ulteriori indicazioni sui requisiti di rete per i target di Tipo 1 e Tipo 2, consulta l'articolo Inoltrare i requisiti di rete di destinazione.

Ordine di selezione della destinazione di inoltro

Cloud DNS consente di configurare un elenco di server dei nomi alternativi per un criterio del server in uscita e un elenco di target di inoltro per una zona di inoltro.

Nel caso di più destinazioni di inoltro, Cloud DNS utilizza un algoritmo interno per selezionare una destinazione di inoltro. Questo algoritmo classifica ogni destinazione di inoltro.

Per elaborare una richiesta, Cloud DNS prova innanzitutto una query DNS contattando il target di inoltro con il ranking più elevato. Se il server non risponde, Cloud DNS ripete la richiesta al successivo target di inoltro con il ranking più alto. Se nessun target 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 elaborate dal target di inoltro. Le risposte DNS riuscite includono risposte NXDOMAIN.
  • Consente di ridurre la latenza (tempo di round trip) per comunicare con la destinazione di inoltro.

Utilizzare le 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 utilizzare la zona di forwarding Cloud DNS. Puoi autorizzare più reti VPC nello stesso progetto a utilizzare la zona di forwarding.
  • Il sistema operativo guest di ogni VM nella rete VPC utilizza il server dei metadati della VM 169.254.169.254 come server dei nomi.

Sovrapposizione delle zone di inoltro

Poiché le zone di inoltro 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 saperne di più, consulta la sezione Sovrapposizione delle zone.

Memorizzazione nella cache e zone di inoltro

Cloud DNS memorizza nella cache le risposte alle query inviate alle zone di inoltro di Cloud DNS. Cloud DNS conserva una cache di risposte provenienti dalle destinazioni di inoltro raggiungibili per il periodo più breve dei seguenti intervalli di tempo:

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

Quando tutti i target di inoltro per una zona di forwarding diventano non raggiungibili, Cloud DNS conserva la cache dei record richiesti in precedenza in quella zona per la durata di ogni TTL dei 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 il seguente scenario:

  • 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 i percorsi personalizzati e vpc-net-b per importarli.

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

La risoluzione di un record in una zona gestita dai target di forwarding non riesce in questo scenario, anche se è presente una connettività da vpc-net-b alla rete on-premise. Per dimostrare questo errore, esegui i seguenti test da una VM in vpc-net-b:

  • Interroga il server dei 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 transitorio verso le destinazioni di inoltro. Per utilizzare una zona di forwarding, una VM deve essere configurata in modo da utilizzare il proprio server di metadati.

  • Interroga direttamente il target di inoltro per lo stesso record. Sebbene Cloud DNS non utilizzi 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 abbia come target vpc-net-a.
  2. Crea una zona di forwarding autorizzata per vpc-net-a i cui target di forwarding 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 sui target di forwarding on-premise.

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

Zone di peering

Il peering DNS consente di inviare richieste per i record provenienti da uno 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 per eseguire ricerche DNS in una rete VPC dove 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 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 DNS consumer network.

Una volta autorizzate le risorse Google Cloud nella rete consumer DNS, queste ultime possono eseguire ricerche nei record nello spazio dei nomi della zona di peering come se fossero nella rete producer DNS. Le ricerche di record nella zona 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 i record nello spazio dei nomi della zona dalle seguenti origini disponibili nella rete produttore DNS:

  • Zone private gestite di Cloud DNS autorizzate dall'uso dalla rete del produttore DNS.
  • Zone di forwarding gestite di Cloud DNS autorizzate dall'uso dalla rete del produttore 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.

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 fossero nella rete producer DNS.
  • Le reti producer e consumer devono essere reti VPC.
  • Sebbene le reti DNS producer e consumer in genere facciano parte della stessa organizzazione, è supportato anche il peering DNS cross-organization.
  • 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 è richiesto 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 (con la rete al centro dell'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 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 i dettagli su questa limitazione, consulta Inoltro delle query dalle VM in una rete VPC consumer a una rete VPC producer non funzionante.

Per creare una zona di peering, devi disporre del ruolo IAM Peer DNS per il progetto che contiene la rete producer DNS.

Per istruzioni su come creare una zona di peering, consulta Creare 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 nei 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 che sia almeno specifica come una delle seguenti zone di esempio. Si tratta di una conseguenza della corrispondenza di suffisso più lunga descritta nell'ordine di risoluzione dei nomi.

Le zone di esempio includono:

  • 10.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 16.172.in-addr.arpa., 17.172.in-addr.arpa., ... fino al giorno 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 che il DNS interno crea automaticamente. Questo perché i record PTR DNS interni vengono creati nell'elenco precedente di zone più specifiche.

Supponi, ad esempio, di aver creato 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 più specifica di 10.in-addr.arpa.. Il record PTR nella zona privata Cloud DNS per test.example.domain viene ignorato.

Per sostituire i record PTR DNS creati automaticamente per le VM, assicurati di creare i record PTR personalizzati in una zona privata almeno specifica di 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 solo eseguire l'override di una parte di un blocco di rete, puoi creare zone private Cloud DNS più specifiche e inverse. Ad esempio, una zona privata per 5.10.in-addr.arpa. può essere utilizzata per conservare i record PTR che sostituiscono eventuali record interni PTR DNS che vengono creati 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 l'una con l'altra quando il nome di 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 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 posizionarle su server dei nomi diversi. Se ciò non è possibile, Cloud DNS non riesce a creare la zona che si sovrappone.

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

  • Le zone private con ambito per diverse reti VPC possono sovrapporsi tra loro. Ad esempio, due reti VPC possono ciascuna avere 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 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 dei suffissi più lunga per determinare l'origine da cui eseguire la query per i record in una determinata zona.

Esempi di risoluzione delle query

Google Cloud risolve le zone di Cloud DNS come descritto in Ordine di risoluzione dei nomi. Quando determina la zona in cui eseguire una query per un determinato record, Cloud DNS cerca di trovare una zona che corrisponda al maggior numero possibile di record richiesti (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 prova prima a trovare un record in una zona privata (o una zona di forwarding o una zona di peering) autorizzata per la rete VPC prima di cercare il record in una zona pubblica.

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

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

    dig myapp.example.com.
    

    Per maggiori dettagli, consulta la pagina Query per il nome DNS utilizzando il server dei 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. NXDOMAIN viene restituito se non sono presenti record per myapp.gcp.example.com definiti nella zona privata gcp.example.com, anche se c'è 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 sono presenti record per myapp.dev.gcp.example.com nella zona dev.gcp.example.com, anche se c'è 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 dell'orizzonte diviso

Puoi utilizzare una combinazione di zone pubbliche e private in una configurazione DNS dell'orizzonte suddiviso. Le zone private 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 dell'orizzonte diviso è utile quando devi fornire record diversi per le stesse query DNS, a seconda della rete VPC di origine.

Considera il seguente esempio di orizzonte suddiviso:

  • Hai creato una zona pubblica, gcp.example.com, e hai configurato il 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 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 query seguenti 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 indipendentemente dalla proprietà dello spazio dei nomi DNS dell'intera rete VPC.

In una configurazione VPC condivisa tipica sono presenti progetti di servizio che acquisiscono la proprietà di un'applicazione o di un servizio VM (VM), mentre il progetto host assume la proprietà della rete VPC e dell'infrastruttura di rete. Spesso lo spazio dei nomi DNS viene creato dallo spazio dei nomi della rete VPC per assicurare la corrispondenza con le risorse del progetto di servizio. Per una configurazione del genere, può essere più facile 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 attività 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 configurazione tipica di VPC condiviso con peering DNS.

Una configurazione VPC condivisa con peering DNS.
Una configurazione VPC condivisa con peering DNS (fai clic per ingrandire)

La figura seguente mostra una configurazione che utilizza un'associazione tra progetti. Cloud DNS consente a ogni progetto di servizio di creare e possedere le zone DNS, ma di mantenere comunque l'associazione alla rete condivisa di proprietà del progetto host. Ciò consente una migliore autonomia e un limite di autorizzazione 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 di progetti 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.
  • È disponibile una qualsiasi risoluzione DNS dedicata. Qualsiasi VM nella rete VPC condiviso può risolvere le zone associate.
  • Non esiste un limite di hop transitorio. Puoi gestirlo in un design hub e spoke.

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

Zone DNS di zona a livello di zona

Cloud DNS a livello di zona consente di creare zone DNS private con ambito solo a una zona Google Cloud. Le zone Cloud DNS di zona 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 rete VPC. Oltre a garantire una facile configurazione, espone anche il 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 di errore è contenuto in quella zona Google Cloud. Le zone private di Cloud DNS a livello di zona non sono interessate dal verificarsi di interruzioni globali. Le eventuali interruzioni di zona di Google Cloud influiscono solo su quella zona Google Cloud e le zone Cloud DNS specifiche all'interno di quella zona Google Cloud. Tieni presente che qualsiasi risorsa creata in un servizio a livello di zona è visibile solo a tale zona Google Cloud.

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

Supporto di Cloud DNS a livello di zona

La tabella seguente mostra l'elenco delle risorse e delle funzionalità di Cloud DNS supportate dal servizio Cloud DNS di zona.

Risorsa o funzionalità 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 di Service Directory
Criteri
Criteri di risposta (con ambito di rete)
Criteri di risposta (ambito cluster GKE)
Regole del criterio di risposta

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

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

Fatturazione per le zone Cloud DNS a livello di zona

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

Passaggi successivi