Panoramica delle zone DNS

Cloud DNS supporta diversi tipi di zone pubbliche e private. In questa pagina vengono fornite informazioni dettagliate sui diversi tipi di zona e su quando puoi utilizzare uno o l'altro.

Zone di inoltro

Le zone di inoltro 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 l'inoltro DNS in uscita dalla rete VPC.

Una zona di inoltro Cloud DNS è un tipo speciale di zona privata di Cloud DNS. Invece di creare record all'interno della zona, devi specificare un set di destinazioni di inoltro. Ogni destinazione di inoltro è 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 eseguire il routing del traffico verso di essi.

Target di inoltro Descrizione Routing standard supportato Routing privato supportato 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 attraverso una rete VPC autorizzata. Qualsiasi indirizzo IP interno, inclusi indirizzi IP privati non RFC 1918 e indirizzi IP pubblici riutilizzati privatamente, il traffico viene sempre instradato attraverso una rete VPC autorizzata. 35.199.192.0/19
Tipo 2 Un indirizzo IP di un sistema on-premise, connesso alla rete VPC autorizzata a eseguire query sulla zona di forwarding, utilizzando Cloud VPN o Cloud Interconnect. Solo indirizzi IP RFC 1918: il traffico viene sempre instradato attraverso una rete VPC autorizzata. Qualsiasi indirizzo IP interno, inclusi indirizzi IP privati non RFC 1918 e indirizzi IP pubblici riutilizzati privatamente, il traffico viene sempre instradato attraverso una rete VPC autorizzata. 35.199.192.0/19
Tipo 3 Un indirizzo IP esterno di un server dei nomi DNS accessibile a Internet o l'indirizzo IP esterno di una risorsa Google Cloud, ad esempio l'indirizzo IP esterno di una VM in un'altra rete VPC. Solo indirizzi IP esterni instradabili su 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 origini DNS pubbliche di Google

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

  • 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

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

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

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

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

Per ulteriori indicazioni sui requisiti di rete per i target di Tipo 1 e Tipo 2, consulta la sezione Inoltrare i requisiti di rete.

Ordine di selezione del target di inoltro

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

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 forwarding.

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

  • Più alto è il numero di risposte DNS elaborate elaborate dalla destinazione di inoltro. Le risposte DNS riuscite includono le risposte NXDOMAIN.
  • Riduci la latenza (tempo di round trip) per comunicare con il target 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 forwarding di 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.

Zone di inoltro sovrapposte

Poiché le zone di inoltro 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 del nome, utilizzando la zona con il suffisso più lungo. Per saperne di più, consulta le zone sovrapposte.

Memorizzazione nella cache e zone di inoltro

Cloud DNS memorizza nella cache le risposte per le query inviate alle zone di inoltro Cloud DNS. Cloud DNS conserva una cache di risposte provenienti dai target di inoltro raggiungibili per gli intervalli di tempo più brevi dei seguenti:

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

Quando tutti i target di inoltro per una zona di forwarding non sono raggiungibili, Cloud DNS conserva la cache dei record richiesti in precedenza per la durata di ciascun 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 inoltro i cui target di inoltro si trovano nella rete on-premise a cui è collegato 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 tua rete on-premise. Per dimostrare che si tratta di un errore, esegui i test riportati di seguito da una VM in vpc-net-b:

  • Esegui una query sul server di metadati della VM 169.254.169.254 per un record definito nella zona di inoltro. Questa query non riesce (aspettativa) perché Cloud DNS non supporta il routing transitorio verso destinazioni di inoltro. Per utilizzare una zona di inoltro, una VM deve essere configurata in modo da utilizzare il suo server di metadati.

  • Interroga direttamente il target di inoltro per lo stesso record. Anche se Cloud DNS non utilizza questo percorso, questa query dimostra che la connettività transitiva ha esito positivo.

Per correggere questo scenario non valido, puoi utilizzare una zona di peering di Cloud DNS:

  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 forwarding autorizzata per vpc-net-a i cui target di inoltro sono server dei nomi on-premise.

Puoi eseguire questa procedura 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 inoltro on-premise.

Per istruzioni su come creare le zone di forwarding, consulta la sezione Creare una zona di forwarding.

Zone di peering

Il peering DNS ti consente di inviare richieste di 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 in cui sono disponibili i record per lo spazio dei nomi di tale zona. La rete VPC in cui la zona di peering DNS esegue ricerche è denominata rete producer DNS.

La zona di peering è visibile solo per le 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, possono eseguire ricerche nei record nello spazio dei nomi della zona di peering come se fossero nella rete producer DNS. Le ricerche di record nello spazio dei nomi della zona di peering seguono l'ordine di risoluzione del nome della rete del produttore DNS.

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

  • Zone private gestite di Cloud DNS autorizzate dall'utilizzo dalla rete del produttore DNS.
  • Zone di forwarding gestite da Cloud DNS autorizzate per essere utilizzate 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 si trovassero nella rete producer DNS.
  • Le reti consumer e di produzione DNS devono essere reti VPC.
  • Sebbene le reti producer e consumer di DNS siano di solito parte della stessa organizzazione, è supportato anche il peering DNS multiorganizzazione.
  • 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 transitorio è supportato, ma solo attraverso un unico hop transitivo. In altre parole, non possono essere coinvolte più di tre reti VPC (con la rete centrale al centro dell'hop transitivo). Ad esempio, puoi creare una zona di peering in vpc-net-a che ha come target vpc-net-b, 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 che si trova nella stessa area geografica della VM di origine che utilizza la zona di peering DNS. Per informazioni dettagliate su questo limite, consulta l'articolo sull'inoltro di query dalle VM in una rete VPC consumer a una rete VPC producer non funzionante.

Per creare una zona di peering, devi avere il ruolo IAM Peer DNS per il progetto contenente la rete del 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 su dati DNS di Compute Engine.

Record PTR per indirizzi RFC 1918 in 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 del suffisso più lunga descritta in 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 vengono creati automaticamente dal DNS interno. 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. rispondono alla zona DNS interna più specifica di 10.in-addr.arpa.. Il record PTR nella zona privata di Cloud DNS per test.example.domain viene ignorato.

Per eseguire l'override dei record PTR interni creati automaticamente per le VM, assicurati di creare i tuoi record PTR personalizzati in una zona privata almeno specifica come 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 ha la precedenza su 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 più zone private Cloud DNS inverse più specifiche. Ad esempio, una zona privata per 5.10.in-addr.arpa. può essere utilizzata per contenere i record PTR che sostituiscono tutti i record PTR DNS interni 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 la sezione Creare una zona di ricerca inversa gestita.

Zone sovrapposte

Due zone sovrapposta 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 l'account gcp.example.com e un'altra zona per l'elemento 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:

  • Non sono consentite zone pubbliche sovrapposte sugli stessi server dei nomi di Cloud DNS. Quando crei zone sovrapposte, Cloud DNS tenta di posizionarle su server dei nomi diversi. Se 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 di metadati utilizza una corrispondenza di suffissi più lunga per determinare quale origine eseguire una 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. Per determinare 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 tenta prima di trovare un record in una zona privata (o una zona di forwarding o zona di peering) autorizzata per la tua rete VPC prima che cerchi il record in una zona pubblica.

I seguenti esempi illustrano l'ordine che il server di metadati utilizza 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 di metadati utilizza server dei nomi pubblici per risolvere un record per myapp.example.com. (nota il punto finale) perché non esiste una zona privata per example.com 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 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. NXDOMAIN viene restituito se non è presente alcun record per myapp.gcp.example.com definito nella zona privata gcp.example.com, anche se esiste un record per myapp.gcp.example.com definito in una zona pubblica.

  • 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 esistono 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 orizzonte diviso

Puoi utilizzare una combinazione di zone pubbliche e private in una configurazione DNS con orizzonte diviso. Le zone private consentono di definire risposte diverse a una query per lo stesso record quando la query 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 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.

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

Nella zona pubblica hai creato due record.

Record Tipo TTL (secondi) Dati
myrecord1.gcp.example.com A 5 104.198.6.142
myrecord2.gcp.example.com A 50 104.198.7.145

Le query seguenti sono state risolte come descritto:

  • Una query per myrecord1.gcp.example.com da una VM nella tua rete VPC restituisce 10.128.1.35.
  • Una query relativa a 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 alcun record per myrecord2.gcp.example.com nella zona privata gcp.example.com.
  • Una query relativa a 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 genere, una configurazione VPC condivisa prevede progetti di servizio che acquisiscono la proprietà di un'applicazione o di un servizio di macchina virtuale (VM), mentre il progetto host diventa proprietario della rete VPC e dell'infrastruttura di rete. Spesso viene creato uno spazio dei nomi DNS dallo spazio dei nomi della rete VPC per farlo corrispondere alle risorse del progetto di servizio. Per una configurazione di questo tipo, può essere più facile delegare l'amministrazione di lo spazio dei nomi DNS di ogni progetto di servizio agli amministratori di ogni 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 di 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 mantenerlo comunque associato alla rete condivisa di proprietà del progetto host. Ciò 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 devi creare una rete VPC segnaposto.
  • Gli amministratori del progetto host non devono gestire il progetto di servizio.
  • I ruoli IAM continuano ad essere applicati a livello di progetto.
  • Tutte le zone DNS sono direttamente associate alla rete VPC condiviso.
  • La risoluzione DNS any-to-any è prontamente disponibile. Qualsiasi VM nella rete VPC condivisa 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 abilitata l'associazione tra progetti, consulta Creare una zona di associazione tra progetti.

Zone DNS di Cloud di zona

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

Il servizio Cloud DNS predefinito è di natura globale e i nomi DNS sono visibili a livello globale nella rete VPC. Questo permette una configurazione facile, ma espone anche il servizio a interruzioni globali. Zona DNS di Cloud è un nuovo servizio Cloud DNS privato che esiste all'interno di ogni zona di Google Cloud. Il dominio in errore è contenuto in quella zona di Google Cloud. Le zone private di Cloud DNS di zona non sono interessate dal verificarsi di interruzioni globali. Le eventuali interruzioni di zona a livello di Google Cloud influiscono solo su quella zona di Google Cloud e su quella di Cloud DNS, all'interno della zona di Google Cloud. Tieni presente che qualsiasi risorsa creata in un servizio di zona è visibile solo a quella zona di Google Cloud.

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

Supporto per Cloud DNS di zona

La tabella riportata di seguito mostra l'elenco delle risorse e delle funzionalità Cloud DNS supportate da Cloud DNS, supportate dai servizi 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 VPC o di rete)
Zone private gestite (con ambito GKE)
Zone di inoltro1
Zone di peering
Zone di ricerca inversa gestite
Crea modifiche o gestisci record2
Zone Service Directory
Criteri
Criteri di risposta (con ambito di rete)
Criteri di risposta (con ambito cluster GKE)
Regole del criterio di risposta

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

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

Fatturazione per le zone Cloud DNS di zona

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

Passaggi successivi