Panoramica delle zone DNS

Cloud DNS supporta diversi tipi di server pubblici e private. Questa pagina fornisce dettagli sui diversi tipi di zona e su quando puoi utilizzare uno o e 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'utilizzo di una zona di inoltro è un modo per implementare l'inoltro DNS in uscita dalla rete VPC.

Una zona di forwarding di Cloud DNS è un tipo speciale di Cloud DNS in una zona privata. Anziché creare record all'interno della zona, puoi specificare un insieme target di inoltro. Ogni destinazione di forwarding è un indirizzo IP di un server DNS, che si trovano nella tua rete VPC o in una rete on-premise connesso alla tua rete VPC da Cloud VPN e 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 Il routing standard supporta Il routing privato supporta Origine delle richieste
Tipo 1 Un indirizzo IP interno di un alla VM Google Cloud bilanciatore del carico di rete passthrough interno nel la stessa rete VPC autorizzata a utilizzare l'inoltro zona di destinazione. 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 un 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 nome DNS accessibile a internet o all'indirizzo IP esterno di un 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 sia non selezionato. Intervalli di origine DNS pubblico di Google

Quando aggiungi il metodo di routing, puoi scegliere uno dei due seguenti metodi target di inoltro alla zona di inoltro:

  • Routing standard:instrada il traffico attraverso un VPC autorizzato rete o su internet a seconda che la destinazione di inoltro è un indirizzo IP RFC 1918. Se la destinazione di inoltro è un indirizzo IP RFC 1918, Cloud DNS classifica la destinazione come Tipo 1 o Tipo 2. e instrada le richieste attraverso 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 alla destinazione di forwarding:

Per ulteriori indicazioni sui requisiti di rete per il Tipo 1 e il Tipo 2, target, consulta la rete di destinazione dell'inoltro di archiviazione dei dati.

Indirizzi IP di destinazione dell'inoltro vietati

Non puoi utilizzare i seguenti indirizzi IP per il forwarding Cloud DNS target:

  • 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 ti consente di configurare un elenco di destinazioni di forwarding per un zona di inoltro.

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

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. alla successiva destinazione di forwarding con il ranking più alto. In caso contrario risposta target di forwarding, Cloud DNS sintetizza un SERVFAIL risposta.

L'algoritmo di ranking è automatico e i seguenti fattori aumentano la classifica di una destinazione 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 round trip) per la comunicazione con target di forwarding.

Usa zone di inoltro

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

  • La rete VPC è stata autorizzata a utilizzare zona di forwarding di Cloud DNS. Puoi autorizzare più reti VPC nello stesso progetto per utilizzare la zona di forwarding.
  • Il sistema operativo guest di ogni VM nella rete VPC utilizza il server 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 una zona privata gestita, 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 la sezione Zone sovrapposte.

Zone per memorizzazione nella cache e inoltro

Cloud DNS memorizza nella cache le risposte per le query inviate a Cloud DNS zone di inoltro. Cloud DNS gestisce una cache delle risposte target di inoltro raggiungibili nei seguenti intervalli di tempo più brevi:

  • 60 secondi
  • La durata (TTL) del record

Quando tutti i target di inoltro di una zona di inoltro 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 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 Da vpc-net-a a vpc-net-b. Hai configurato vpc-net-a per esportare i dati personalizzati route 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 per utilizzare la 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 metadati 169.254.169.254 della VM per ottenere un record definita nella zona di inoltro. 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 relativo 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 di Compute Engine in vpc-net-a e vpc-net-b possono eseguire query le destinazioni di forwarding on-premise.

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

Zone di peering

Il peering DNS consente di inviare richieste per i record provenienti dal 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 per eseguire ricerche DNS in una rete VPC in cui disponibili record per lo spazio dei nomi di quella zona. Il VPC in cui la zona di peering DNS esegue le ricerche è denominata producer DNS; Google Cloud.

La zona di peering è visibile solo alle reti VPC che selezionate durante la configurazione della zona. La rete VPC l'autorizzazione 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 erano nella rete del producer 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 di Cloud DNS autorizzate a essere utilizzate dal DNS più produttiva della tua rete di produttori.
  • Zone di forwarding gestite di Cloud DNS autorizzate a essere utilizzate dal DNS più produttiva della tua rete di produttori.
  • 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 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 per cercare record nello spazio dei nomi della zona di peering come se le risorse Google Cloud fossero nella rete del producer 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, 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 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 e poi 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 con la zona di forwarding deve contenere una VM, da un collegamento VLAN o da un tunnel Cloud VPN che si trovano 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 inverse con i record PTR personalizzati per RFC 1918 indirizzi IP, devi creare una zona privata di Cloud DNS che sia almeno altrettanto specifica come una delle zone di esempio seguenti. Questa è una conseguenza del corrispondenza del suffisso più lunga descritta in Nome ordine di risoluzione.

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., ... alla 31.172.in-addr.arpa.

Se crei una zona privata di Cloud DNS per gli indirizzi RFC 1918, I record PTR che crei per le VM in quella zona vengono sostituiti dal Record PTR creati dal DNS interno automaticamente. Ciò è dovuto al fatto che i record PTR del DNS interni vengono creati l'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 nel tuo Cloud DNS la zona privata per test.example.domain viene ignorata.

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 record sostituisce quello generato automaticamente uno: 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 per le zone private di 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 e mettili 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 una con l'altra. Ad esempio, due reti VPC possono avere ciascuna VM di database denominata database.gcp.example.com in una zona gcp.example.com. Le query per database.gcp.example.com ricevono risposte diverse a seconda ai record di zona definiti nella zona autorizzata per rete VPC.

  • Due zone private autorizzate ad essere accessibili dallo stesso La rete VPC non può avere origini identiche a meno che una zona non sia un sottodominio dell'altro. Il server di metadati utilizza la corrispondenza del suffisso più lunga con determinare quale origine interrogare per i record in una determinata zona.

Esempi di risoluzione delle query

Google Cloud risolve le zone Cloud DNS come descritto in Ordine di risoluzione dei nomi. 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.

I seguenti esempi illustrano l'ordine utilizzato dal server di metadati quando per eseguire 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, vedi Esegui una query per il nome DNS utilizzando la proprietà server metadati.

  • Il server di metadati risolve il record myapp.gcp.example.com utilizzando il metodo zona privata autorizzata gcp.example.com perché gcp.example.com è suffisso comune più lungo tra il nome del record richiesto e quello disponibile in zone private autorizzate. NXDOMAIN viene restituito se non esistono 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 un pubblico di controllo.

  • Allo stesso modo, le query per myapp.dev.gcp.example.com vengono risolte in base ai dati registrati 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 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 con orizzonte di suddivisione

Puoi utilizzare una combinazione di zone pubbliche e private in un DNS ad orizzonte diviso configurazione. Le zone private consentono di definire risposte diverse a una per lo stesso record quando la query proviene da una VM all'interno di rete VPC autorizzata. Il DNS Split Horizon è utile ogni volta che devono fornire record diversi per le stesse query DNS a seconda dalla 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 il rete VPC per accedere a questa zona.

Nella zona privata, hai creato un singolo record come mostrato di seguito .

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 per myrecord1.gcp.example.com da internet restituisce 104.198.6.142.
  • Una query per myrecord2.gcp.example.com da una VM nel tuo VPC restituisce un errore NXDOMAIN perché non esiste nessun 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 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 all'account amministratori di ogni progetto di servizio (spesso sono reparti diversi o attività commerciali). 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 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 possedere le zone DNS, ma che sia ancora associato alla rete condivisa di proprietà del progetto host. Ciò consente una migliore autonomia e un confine più preciso delle autorizzazioni per Amministrazione della zona 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 il proprio DNS diverse.
  • 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 nel La 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 Crea una zona di associazione tra progetti.

Zone Cloud DNS di zona

Cloud DNS a livello di zona consente di creare zone DNS private con ambito in una zona Google Cloud. Vengono create zone Cloud DNS di zona per GKE quando scegli nell'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 all'interno della zona Google Cloud. Zone private Cloud DNS di zona non subiscano 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 di zona con ambito cluster Cloud DNS, vedi Configura 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 che sono supportate dai servizi Cloud DNS a livello di 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 livello di cluster GKE.

2 Il controller GKE sovrascrive qualsiasi modifica apportata a i 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