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 Cloud DNS consentono di configurare server dei nomi di destinazione per zone private specifiche. 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, che si trova nella tua rete VPC o in una rete on-premise connessa alla tua 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 Supporta il routing standard Supporto del routing privato 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 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 forwarding vietato, con 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 nella zona di forwarding, utilizzando Cloud VPN o Cloud Interconnect. Solo indirizzi IP RFC 1918, traffico 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 forwarding vietato: 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 da 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, 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 DNS pubblici di Google

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

  • 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 dell'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 a internet.

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

Per accedere a una destinazione di inoltro 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 alla destinazione dell'inoltro:

Per indicazioni aggiuntive sui requisiti di rete per i target di Tipo 1 e Tipo 2, consulta i requisiti di rete di destinazione per l'inoltro.

Indirizzi IP di destinazione di 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 forwarding.

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 dell'inoltro.

Per elaborare una richiesta, Cloud DNS prima prova una query DNS contattando la destinazione di forwarding con il ranking più alto. Se il server non risponde, Cloud DNS ripete la richiesta al successivo target di forwarding con 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 forwarding:

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

Usare le zone di inoltro

Le VM in una rete VPC possono utilizzare una zona di forwarding di 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 di metadati della VM 169.254.169.254 come server dei nomi.

Zone di inoltro sovrapposte

Poiché le zone di forwarding 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 all'ordine di risoluzione dei nomi, utilizzando la zona con il suffisso più lungo. Per ulteriori informazioni, consulta la sezione Zone sovrapposte.

Memorizzazione nella cache e zone di inoltro

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

  • 60 secondi
  • La durata (TTL) del record

Quando tutte le destinazioni di forwarding per 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 un target 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 forwarding le cui destinazioni di forwarding si trovano nella rete on-premise a cui è connesso vpc-net-a. Hai autorizzato vpc-net-b a utilizzare questa zona di forwarding.

La risoluzione di un record in una zona gestita dalle destinazioni di forwarding non riesce in questo scenario, anche se è disponibile 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 metadati della VM 169.254.169.254 per trovare un record definito nella zona di forwarding. Questa query non riesce (previsto) perché Cloud DNS non supporta il routing transitivo verso le destinazioni di forwarding. Per utilizzare una zona di forwarding, una VM deve essere configurata in modo da utilizzare il proprio server di metadati.

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

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

  1. Creare 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 le cui destinazioni 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 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 per eseguire 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 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 fossero 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.

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 del producer DNS:

  • Zone private gestite di Cloud DNS autorizzate per l'utilizzo dalla rete del produttore DNS.
  • Zone di inoltro gestite di Cloud DNS autorizzate per l'utilizzo 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 producer 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 i 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 consumatore DNS devono essere reti VPC.
  • Sebbene le reti di produttori e consumatori 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 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 (di cui la rete al centro è l'hop transitivo). Ad esempio, puoi creare una zona di peering in vpc-net-a che ha come target vpc-net-b e quindi 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 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, vedi Inoltro delle query dalle VM in una rete VPC consumer a una rete VPC di producer non funzionante.

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

Zone di ricerca inversa gestita

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 nelle zone private

Per eseguire ricerche inverse con i record PTR personalizzati per gli indirizzi RFC 1918, devi creare una zona privata di Cloud DNS che sia almeno specifica di una delle seguenti zone di esempio. Questa è una conseguenza della corrispondenza più lunga del suffisso 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., ... 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 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 almeno tanto specifica 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 tuo record sostituisce quello generato automaticamente: 1.1.1.10.in-addr.arpa. -> test.example.domain.

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

Zone sovrapposte

Due zone si sovrappongono tra loro 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 la sovrapposizione gcp.example.com perché dev.gcp.example.com è un sottodominio di gcp.example.com.

Regole per la sovrapposizione di zone

Cloud DNS applica le seguenti regole per la sovrapposizione delle zone:

  • Non sono consentite zone pubbliche sovrapposte sugli stessi server dei nomi Cloud DNS. Quando crei zone che si sovrappongono, Cloud DNS tenta di inserirle 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 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 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 dei suffissi più lunga per determinare l'origine su cui eseguire la 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. Nel determinare la zona su cui eseguire la query per un determinato record, Cloud DNS prova a trovare una zona che corrisponda il più possibile al 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 prima di trovare un record in una zona privata (o zona di forwarding 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'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 avervi autorizzato l'accesso 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 per myapp.example.com. (vedi il 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 relativa alla 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. NXDOMAIN viene restituito se non è stato definito alcun record per myapp.gcp.example.com nella zona privata gcp.example.com, anche se è stato definito un record per myapp.gcp.example.com 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 Suddividi Horizon

Puoi utilizzare una combinazione di zone pubbliche e private in una configurazione DNS a 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 Split Horizon è 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 diviso:

  • Hai creato una zona pubblica gcp.example.com e hai configurato il suo registrar 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 nella seguente 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 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 un 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 include progetti di servizio che assumono la proprietà di un'applicazione o di un servizio di 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 una configurazione di questo tipo, può essere più semplice 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 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 ogni progetto di servizio di creare e gestire le proprie zone DNS, ma di associarlo alla rete condivisa di proprietà del progetto host. Questo consente una migliore autonomia e un confine 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 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 qualsiasi è facilmente disponibile. Qualsiasi VM nella rete VPC condiviso può risolvere le zone associate.
  • Non esiste un limite di hop transitivo. Puoi gestirlo in un design hub e 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 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 cluster.

Il servizio Cloud DNS predefinito è di natura globale e i nomi DNS sono visibili a livello globale all'interno della rete VPC. Questa configurazione espone il 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 si trova all'interno della zona Google Cloud. Le zone private di Cloud DNS a livello di zona non sono interessate da interruzioni globali. Eventuali interruzioni a livello di zona di Google Cloud interessano solo la zona Google Cloud specifica e le zone Cloud DNS all'interno della zona Google Cloud. Tieni presente che qualsiasi risorsa creata in un servizio a livello di zona è visibile solo per 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.

Supporto Cloud DNS a livello di zona

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

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

1 Cloud DNS a livello di zona supporta solo zone di forwarding con ambito 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 Cloud DNS e i criteri di risposta a livello di zona funziona allo stesso modo delle controparti globali.

Passaggi successivi