Panoramica delle zone DNS

Cloud DNS supporta diversi tipi di zonepubbliche e private. Questo documento fornisce dettagli sui diversi tipi di zone e su quando puoi utilizzare uno o l'altro.

Zone di inoltro

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

Una zona di inoltro Cloud DNS è un tipo speciale di zona privata Cloud DNS. Anziché creare record all'interno della zona, specifica un insieme di destinazione per il reindirizzamento. Ogni destinazione di inoltro è un indirizzo IP di un server DNS, situato nella rete VPC o in una rete on-premise connessa alla rete VPC tramite Cloud VPN o Cloud Interconnect.

Destinazioni di inoltro e metodi di routing

Cloud DNS supporta tre tipi di target e offre metodi di routing standard o privati per la connettività.

Destinazione forwarding Descrizione Supporto del routing standard Supporto per il routing privato Origine delle richieste
Tipo 1 Un indirizzo IP interno di una VM Google Cloud o di un Network Load Balancer passthrough interno nella stessa rete VPC autorizzata a utilizzare la zona di inoltro. Solo indirizzi IP RFC 1918: il traffico viene 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, tranne per un indirizzo IP di destinazione per inoltro vietato: il traffico viene sempre inoltrato 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 inoltro, 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, ad esempio un indirizzo privato RFC 1918, un indirizzo IP privato non RFC 1918 o un indirizzo IP esterno riutilizzato privatamente, tranne per un indirizzo IP di destinazione per il reindirizzamento vietato: il traffico viene sempre instradato tramite una rete VPC autorizzata. 35.199.192.0/19
Tipo 3 Un indirizzo IP esterno di un server DNS di nome 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 viene sempre instradato su internet o sull'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

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

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

  • Routing privato:instrada sempre il traffico tramite una rete VPC autorizzata, indipendentemente dall'indirizzo IP di 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 tipo 2, Cloud DNS utilizza i percorsi nella rete VPC autorizzata in cui si trova il client DNS. Queste route definiscono un percorso sicuro per la destinazione di inoltro:

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

Indirizzi IP di destinazione per l'inoltro vietato

Non puoi utilizzare i seguenti indirizzi IP per i destinatari del forwarding di Cloud DNS:

  • 169.254.0.0/16
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 224.0.0.0/4
  • 240.0.0.0/4
  • ::1/128
  • ::/128
  • 2001:db8::/32
  • fe80::/10
  • fec0::/10
  • ff00::/8

Ordine di selezione della destinazione inoltro

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

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

Per elaborare una richiesta, Cloud DNS tenta prima una query DNS contattando la destinazione di inoltro con il ranking più alto. Se il server non risponde, Cloud DNS ripete la richiesta al successivo target di inoltro con il ranking più alto. Se nessun destinazione 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 riuscite elaborate dalla destinazione del inoltro. Le risposte DNS riuscite includono le risposte NXDOMAIN.
  • Minore è la latenza (tempo di round trip) per la comunicazione con il destinazione di inoltro.

Utilizzare le zone di inoltro

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

  • La rete VPC è stata autorizzata a utilizzare la zona di inoltro Cloud DNS. Per utilizzare la zona di inoltro, puoi autorizzare più reti VPC nello stesso progetto o in più progetti, a condizione che le reti VPC si trovino all'interno della stessa organizzazione.

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

Zone di inoltro sovrapposte

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

Zone di memorizzazione nella cache e di inoltro

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

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

Quando tutti i target di inoltro per una zona di inoltro diventano non raggiungibili, Cloud DNS mantiene la cache dei record richiesti in precedenza in quella zona per la durata del TTL di ciascun record.

Quando utilizzare il peering

Cloud DNS non può utilizzare il routing transitivo per connettersi a un destinazione di inoltro. 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 le route personalizzate e vpc-net-b per importarle.

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

In questo scenario, la risoluzione di un record in una zona servita dai target di inoltro non va a buon fine, anche se è presente connettività da vpc-net-b alla rete on-premise. Per dimostrare questo errore, esegui i seguenti test da una VM in vpc-net-b:

  • Esegui una query sul server di metadati 169.254.169.254 della VM per un record definito nella zona di inoltro. Questa query non va a buon fine (come previsto) perché Cloud DNS non supporta il routing transitivo ai target di inoltro. Per utilizzare una zona di inoltro, una VM deve essere configurata per utilizzare il proprio server di metadati.

  • Esegui una query direttamente sul target di inoltro per lo stesso record. Anche se Cloud DNS non utilizza questo percorso, questa query dimostra che la connettività transitiva è riuscita.

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 ha come target vpc-net-a.
  2. Crea una zona di inoltro autorizzata per vpc-net-a i cui target di inoltro sono server dei nomi on-premise.

Puoi eseguire questi passaggi in qualsiasi ordine. Dopo aver completato questi passaggi, le istanze Compute Engine sia in vpc-net-a sia in vpc-net-b possono eseguire query sui target di inoltro on-premise.

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

Zone di peering

Una zona di peering è una zona privata Cloud DNS che ti consente di inviare richieste DNS tra zone Cloud DNS in reti VPC diverse. Ad esempio, un fornitore di software as a service (SaaS) può dare ai propri clienti l'accesso ai propri record DNS gestiti in Cloud DNS.

Per fornire il peering DNS, devi creare una zona di peering privato Cloud DNS e configurarla per eseguire ricerche DNS in una rete VPC in cui sono disponibili i record per lo spazio dei nomi della zona. La rete VPC in cui la zona di peering DNS esegue le ricerche è chiamata rete del produttore DNS.

La zona di peering è visibile solo alle reti VPC selezionate durante la configurazione della zona. La rete VPC autorizzata a utilizzare la zona di peering è chiamata rete di consumo DNS.

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

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

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

Con il peering DNS, puoi fare in modo che una rete (rete di consumo DNS) inoltri le richieste DNS a un'altra rete (rete di produzione DNS), che poi esegue le ricerche DNS.

Limitazioni e punti chiave del peering DNS

Tieni presente quanto segue durante la configurazione del peering DNS:

  • Il peering DNS è una relazione unidirezionale. Consente alle risorse Google Cloud nella rete del consumatore DNS di cercare record nello spazio dei nomi della zona di peering come se le risorse Google Cloud si trovassero nella rete del produttore DNS.
  • Le reti producer e consumer DNS devono essere reti VPC.
  • Sebbene le reti di produttori e consumatori DNS siano 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 di rete VPC non condivide automaticamente le informazioni DNS. 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 tramite un singolo hop transitivo. In altre parole, non possono essere coinvolte più di tre reti VPC (con la rete al centro che rappresenta il salto 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 ha come target vpc-net-c.
  • Se utilizzi il peering DNS per scegliere come target una zona di inoltro, la rete VPC di destinazione con la zona di inoltro deve contenere una VM, un collegamento VLAN o un tunnel Cloud VPN situato nella stessa regione della VM di origine che utilizza la zona di peering DNS. Per dettagli su questa limitazione, consulta Il forwarding delle query dalle VM in una rete VPC consumer a una rete VPC producer non funziona.

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 ordina a Cloud DNS di eseguire una ricerca PTR in base ai dati DNS di Compute Engine.

Record PTR per gli indirizzi RFC 1918 nelle zone private

Per eseguire ricerche in ordine inverso con record PTR personalizzati per gli indirizzi RFC 1918, devi creare una zona privata Cloud DNS almeno specifica quanto una delle seguenti zone di esempio. Questa è una conseguenza della corrispondenza del suffisso più lungo descritta in Ordine di risoluzione dei nomi.

Ecco 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 di zone più specifiche.

Ad esempio, supponiamo 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 una risposta dalla zona DNS interna più specifica10.in-addr.arpa.. Il record PTR nella zona privata 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 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 sostituisce quello generato automaticamente: 1.1.1.10.in-addr.arpa. -> test.example.domain.

Se devi sostituire solo una parte di un blocco di rete, puoi creare zone private Cloud DNS inverse più specifiche. Ad esempio, una zona privata per 5.10.in-addr.arpa. può essere utilizzata per contenere 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 quando il nome di dominio di origine di una zona è identico a quello dell'altra o è un sottodominio dell'origine dell'altra zona. Ad esempio:

  • Una zona per gcp.example.com e un'altra 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 metterle 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 database denominata database.gcp.example.com in una zona gcp.example.com. Le query per database.gcp.example.com ricevono risposte diverse in base ai record di zona definiti nella zona autorizzata per ogni rete VPC.

  • Due zone private che sono state autorizzate ad essere accessibili dalla stessa rete VPC non possono avere origini identiche, a meno che una zona non sia un sottodominio dell'altra. Il server di metadati utilizza la corrispondenza del suffisso più lungo per determinare l'origine per cui eseguire query sui record in una determinata zona.

Esempi di risoluzione delle query

Google Cloud risolve le zone Cloud DNS come descritto in Ordine di risoluzione dei nomi. Quando determina la zona per cui eseguire una query per un determinato record, Cloud DNS tenta di trovare una zona che corrisponda al maggior numero possibile di record richiesti (corrispondenza del suffisso più lungo).

A meno che non tu abbia specificato un server DNS alternativo in un criterio del server in uscita, Google Cloud tenta prima di trovare un record in una zona privata (o in una zona di inoltro o di peering) autorizzata per la tua rete VPC prima di cercare il record in una zona pubblica. Gli esempi riportati di seguito illustrano l'ordine utilizzato dal server dei metadati per eseguire 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 aver autorizzato l'accesso da una stessa rete VPC. Google Cloud gestisci le query DNS dalle VM in una rete VPC nel seguente modo:

  • Il server dei metadati utilizza i server DNS pubblici per risolvere un record permyapp.example.com. (nota il punto finale) perché non esiste una zona privata per example.com che sia stata autorizzata per la rete VPC. Utilizza dig da una VM Compute Engine per eseguire query sul nome predefinito della VM server:

    dig myapp.example.com.

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

  • Il server dei metadati risolve il record myapp.gcp.example.com utilizzando la gcp.example.com zona privata autorizzata perché gcp.example.com è il sufisso comune più lungo tra il nome del record richiesto e le gcp.example.com zone private autorizzate disponibili. NXDOMAIN viene restituito se non esiste un record per myapp.gcp.example.com definito nella zona privata gcp.example.com, anche se esiste un record per myapp.gcp.example.com definito in una zona pubblica.

  • Analogamente, le query per myapp.dev.gcp.example.com vengono risolte in base ai record nella zona privata autorizzata dev.gcp.example.com. 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 a orizzonte diviso

Puoi utilizzare una combinazione di zone pubbliche e private in una configurazione DNS con orizzonte diviso. Le zone private ti consentono di definire risposte diverse a una query per lo stesso record quando la query proviene da una VM all'interno di una rete VPC autorizzata. Il DNS a orizzonte diviso è utile ogni volta che devi fornire record diversi per le stesse query DNS a seconda della rete VPC di origine.

Considera il seguente esempio di orizzonte 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 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 seguenti query vengono risolte come descritto:

  • Una query per myrecord1.gcp.example.com da una VM nella rete VPC restituisce 10.128.1.35.
  • Una query su myrecord1.gcp.example.com da internet restituisce 104.198.6.142.
  • Una query per myrecord2.gcp.example.com da una VM nella rete VPC restituisce un errore NXDOMAIN perché non esiste alcun record per myrecord2.gcp.example.com nella zona privata gcp.example.com.
  • Una query su myrecord2.gcp.example.com da internet restituisce 104.198.7.145.

Associatione tra progetti

Il vincolo tra progetti ti 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.

Una configurazione tipica di VPC condiviso prevede progetti di servizio che acquisiscono la proprietà di un'applicazione o di servizi di macchine virtuali (VM), mentre il progetto host acquisisce la proprietà della rete e dell'infrastruttura di rete del VPC. Spesso viene creato uno spazio dei nomi DNS dallo spazio dei nomi della rete VPC in modo che corrisponda alle risorse del progetto di servizio. Per una configurazione di questo tipo, può essere più facile delegare l'amministrazione dello spazio dei nomi DNS di ogni progetto di servizio agli amministratori di ogni progetto di servizio (spesso reparti o attività diversi). Il vincolo tra progetti ti 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 VPC condiviso con peering DNS.

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

La figura seguente mostra una configurazione che utilizza il binding tra progetti. Cloud DNS consente a ogni progetto di servizio di creare e possedere le proprie zone DNS, ma di associarle comunque alla rete condivisa di proprietà del progetto host. Ciò consente una maggiore autonomia e un confine delle autorizzazioni più preciso per la gestione delle zone DNS.

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

L'associazione tra progetti offre quanto segue:

  • Gli amministratori e gli utenti dei progetti di servizi 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 si applicano comunque a livello di progetto.
  • Tutte le zone DNS sono associate direttamente alla rete VPC condiviso.
  • La risoluzione DNS any-to-any è immediatamente disponibile. Qualsiasi VM nella rete VPC condiviso può risolvere le zone associate.
  • Non è previsto un limite di hop transitivi. Puoi gestirlo in un design hub and spoke.

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

Zone Cloud DNS zonali

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

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

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

Supporto di Cloud DNS zonale

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

Risorsa o funzionalità Disponibile su Cloud DNS globale Disponibile su Cloud DNS zonale
Zone pubbliche gestite
Zone private gestite (a livello di rete o VPC)
Zone private gestite (a livello di 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 (a livello di rete)
Criteri di risposta (a livello di cluster GKE)
Regole del criterio di risposta

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

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

Fatturazione per le zone Cloud DNS zonali

La fatturazione per le zone Cloud DNS zonali e i relativi criteri di risposta funziona allo stesso modo delle controparti globali.

Passaggi successivi