Questa pagina fornisce soluzioni per problemi comuni che potresti riscontrare quando utilizzando Cloud DNS per creare zone pubbliche o private, zone di ricerca inversa zone di forwarding e record di risorse.
Zone pubbliche
Questa sezione tratta i problemi relativi alle zone pubbliche.
Impossibile creare una zona pubblica
Se ricevi un errore attempted action failed
, significa che Cloud DNS
L'API non è abilitata nel tuo progetto.
Per abilitare l'API Cloud DNS, segui questi passaggi:
Nella console Google Cloud, vai alla pagina Libreria API.
In Seleziona un progetto recente, seleziona il progetto Google Cloud in cui vuoi abilitare l'API.
Nella pagina Libreria API, utilizza la casella Cerca API e Servizi per cerca
Cloud DNS API
. Viene visualizzata una pagina che descrive l'API.Fai clic su Attiva.
Zone private
Questa sezione illustra i problemi relativi alle zone private.
Problemi nelle zone private nei progetti di servizio del VPC condiviso
Per informazioni importanti sull'uso delle zone private con il VPC condiviso sulle reti, consulta Zone private e VPC condiviso.
Impossibile creare una zona privata, impossibile elencare o creare criteri
Devi disporre del ruolo Amministratore DNS per eseguire varie azioni nelle zone private, ad esempio elencare DNS (Domain Name System) criteri del server o la creazione di una zona privata. Questo ruolo può essere concesso tramite la Strumento IAM (Identity and Access Management).
Le zone private non si risolvono nella stessa rete VPC
Assicurati di eseguire il test da un'istanza VM la cui interfaccia principale si trova sulla stessa rete della zona privata che hai creato
Un'istanza di macchina virtuale (VM) invia tutto il traffico fuori dalla sua interfaccia principale a meno che il traffico non sia destinato a una subnet collegata a una delle o se la VM ha un routing dei criteri configurato. Assicurati che l'interfaccia principale della VM di test sia sulla stessa come zona privata che stai testando.
Determina se la tua VM utilizza:
gcloud compute instances describe VM_NAME \ --zone=GCE_ZONE \ --format="csv[no-heading](networkInterfaces['network'])"
Assicurati che la rete sia nell'elenco delle reti autorizzate a eseguire query su zona privata:
gcloud dns managed-zones describe PRIVATE_ZONE_NAME \ --format="csv(privateVisibilityConfig['networks'])"
Verifica che il nome DNS nella query corrisponda alla tua zona
Google Cloud risolve un record in base
ordine di risoluzione dei nomi, utilizzando la zona con
il suffisso più lungo per decidere quale zona interrogare per un determinato nome DNS. Assicurati che
che il suffisso del record su cui esegui la query corrisponda ad almeno uno
accessibile nella rete VPC. Ad esempio, Google Cloud
cerca prima myapp.dev.gcp.example.lan
in una zona che gestisce
dev.gcp.example.lan
, se accessibile, prima di cercarla in una zona che
serve gcp.example.lan
, se accessibile.
L'output del comando seguente mostra il suffisso DNS per un determinato privato zona:
gcloud dns managed-zones describe PRIVATE_ZONE_NAME \ --format="csv[no-heading](dnsName)"
Query per il nome DNS utilizzando il server di metadati
Utilizza dig
per inviare la query sul nome DNS direttamente a Google Cloud
server di metadati, 169.254.169.254
:
dig DNS_NAME @169.254.169.254
Usa dig
per eseguire query sul server dei nomi predefinito della VM:
dig DNS_NAME
Se l'output dei due comandi dig
produce risposte diverse, controlla la
;; SERVER:
del secondo comando. Il server che risponde deve essere
server di metadati, 169.254.169.254
. Se non lo è, hai configurato
sistema operativo guest di utilizzare un server dei nomi DNS personalizzato al posto di quello predefinito
o il server di metadati di Google Cloud. Le zone private di Cloud DNS richiedono
di usare il server dei metadati per la risoluzione dei nomi. Sia il file Linux guest
ambiente e Windows
ambiente guest
di farlo per te. Se hai importato l'immagine che stai utilizzando per una VM,
e verificare che sia stato installato l'ambiente guest appropriato.
Le zone private non vengono risolte tramite Cloud VPN o Cloud Interconnect
Innanzitutto, assicurati di poter eseguire query e risolvere correttamente il nome DNS da all'interno di un VPC autorizzato Google Cloud.
Verifica la connettività tramite Cloud VPN o Cloud Interconnect
Assicurati che la connettività da un sistema on-premise al tuo VPC operativa è operativa. In particolare, il traffico TCP e UDP sulla porta 53 deve essere in grado di uscire dalla rete on-premise e di essere consegnati rete VPC. Verifica la configurazione dei firewall on-premise e assicurati che il traffico in uscita sia consentito.
Puoi utilizzare qualsiasi protocollo, ad esempio ping
(ICMP), per testare la connettività a un
di esempio nella tua rete VPC
da on-premise. Mentre
Le richieste Cloud DNS non vengono inviate alle VM Google Cloud,
il test della connettività a una VM di esempio ti consente di verificare la connettività tramite
Tunnel Cloud VPN o connessione Cloud Interconnect. Accertati che
configuri una regola firewall di autorizzazione in entrata appropriata per l'esempio
VM Google Cloud perché la possibilità di negare l'accesso in entrata
regola blocca tutto il traffico in entrata
negli altri casi.
Assicurati che l'inoltro in entrata sia abilitato per la rete VPC autorizzata
L'inoltro in entrata deve essere abilitato per ogni rete VPC hai l'autorizzazione per eseguire query sulla zona privata di Cloud DNS. Utilizza quanto segue per elencare tutti i criteri:
gcloud dns policies list
Identifica la rete nella tabella di output e controlla il campo Inoltro. per vedere se l'inoltro è attivato.
Assicurati che la rete autorizzata sia una rete VPC
L'inoltro DNS richiede subnet, che sono disponibili solo per VPC reti, non legacy reti.
gcloud compute networks list \ --format="csv[no-heading](name, SUBNET_MODE)"
Le reti legacy sono identificate nell'output come LEGACY
.
Assicurati che esista un indirizzo di inoltro DNS valido riservato in quella rete
Il comando seguente mostra tutti gli indirizzi IP di forwarding DNS riservati nel tuo progetto.
gcloud compute addresses list \ --filter="purpose=DNS_RESOLVER" \ --format='csv[no-heading](address, subnetwork)'
Puoi aggiungere una clausola AND
al filtro per limitare l'output solo alle
subnet che ti interessa.
Esempio:
--filter="name ~ ^dns-forwarding AND subnetwork ~ SUBNETWORK_NAME"
Se nella rete o nella regione non vedi un indirizzo IP previsto, invia un file un ticket con l'assistenza Google Cloud.
Esegui il comando dig
, puntando la query all'indirizzo trovato nella
precedente. Puoi farlo da una VM nella stessa rete. Questo test verifica
che il server di invio in entrata funziona e che il problema risiede altrove.
dig DNS_NAME @10.150.0.1 # address returned by previous command
Ripeti lo stesso comando dig
da un host on-premise sulla VPN.
Il record CNAME definito in una zona privata non funziona
Cloud DNS insegue solo i record CNAME come descritto in Ricerca di CNAME.
Inverti zone di ricerca
Questa sezione fornisce suggerimenti per la risoluzione dei problemi relativi alle zone di ricerca inversa. Alcuni problemi relativi alle zone private si applicano anche alle zone di ricerca inversa. Per ulteriori Suggerimenti, consulta la sezione per la risoluzione dei problemi relativi alle zone private.
Una VM con indirizzo non RFC 1918 non viene risolta
Riconciliazione della VM con un indirizzo non RFC 1918
Se hai creato una VM durante la versione alpha non RFC 1918 prima È stato avviato il supporto di Cloud DNS. Questa VM potrebbe non essere risolta in modo corretto. Per risolvere il problema, riavvia le VM.
Zone di inoltro
Questa sezione fornisce suggerimenti per la risoluzione dei problemi relativi alle zone di inoltro. Alcuni problemi relativi alle zone private si applicano anche alle zone di forwarding. Per ulteriori Suggerimenti, consulta la sezione per la risoluzione dei problemi relativi alle zone private.
Zone di forwarding (inoltro in uscita) non funzionanti
Innanzitutto, assicurati di poter eseguire query e risolvere correttamente il nome DNS da all'interno di un VPC autorizzato Google Cloud.
Inoltro delle query dalle VM in una rete VPC consumer a una rete VPC del produttore non funzionante
Se utilizzi il peering DNS e vuoi inoltrare le query dalle VM in da una rete VPC consumer a una rete VPC del producer, quindi a uno o più server dei nomi on-premise, assicurati che uno dei sono soddisfatti i seguenti prerequisiti:
La rete VPC del producer ha la sua modalità di routing dinamico impostata su
GLOBAL
La VM nella rete VPC consumer si trova nella stessa regione Tunnel VPN o Cloud Interconnect nel VPC del producer
(Solo VPN classica) La rete VPC del producer ha una route statica configurate per inviare il traffico destinato ai server dei nomi on-premise tramite Tunnel VPN classica. La rete VPC del producer deve inoltre avere una VM Tunnel VPN nella stessa regione della subnet utilizzata dalle VM client.
Ad esempio, supponiamo che VPC1 utilizzi una zona di peering che invia query da
example.com.
a VPC2. Supponi anche che il VPC2 abbia una zona di forwarding privataexample.com.
che inoltra le query a un server dei nomi on-premise utilizzando un Tunnel VPN classica.Affinché una VM situata in
us-east1
in VPC1 possa eseguire query suexample.com.
, VPC2 deve avere una VM situata inus-east1
. Una route statica deve essere configurato anche coprendo gli intervalli CIDR dei server dei nomi on-premise, con l'hop successivo configurato come tunnel VPN classica.
Verifica la connettività tramite Cloud VPN o Cloud Interconnect
Puoi utilizzare qualsiasi protocollo, ad esempio ping
(ICMP), per testare la connettività a un
di esempio nella tua rete VPC
da on-premise. Devi inoltre
tentare di eseguire una query sul server dei nomi on-premise direttamente da un esempio
VM Google Cloud utilizzando uno strumento come dig
:
dig DNS_NAME @192.168.x.x # address of the onprem DNS server
Controlla le regole firewall nella rete VPC
Il firewall di traffico in uscita implicito consente le connessioni in uscita e le risposte stabilite dalle VM nella tua rete VPC, hai creato regole personalizzate per negare il traffico in uscita. Se hai creato un account di rifiuto personalizzato di traffico in uscita, dovrai creare regole di autorizzazione con priorità più elevata che consentano in uscita verso almeno i server dei nomi on-premise.
Controlla il firewall on-premise
Assicurati che il firewall on-premise sia configurato per consentire il traffico in entrata
da e in uscita verso 35.199.192.0/19
.
Controlla i log nel firewall on-premise per cercare le richieste DNS da
35.199.192.0/19
. Per utilizzare un'espressione regex
per effettuare una ricerca, utilizza quanto segue:
"35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*"
Controlla il server dei nomi on-premise
Verifica di non aver configurato ACL nel server dei nomi on-premise
che bloccano le query da 35.199.192.0/19
.
Controlla il server dei nomi on-premise per vedere se riceve pacchetti da
35.199.192.0/19
. Se disponi dell'accesso alla shell, puoi utilizzare uno strumento come
tcpdump
per cercare i pacchetti in entrata e quelli in uscita verso
35.199.192.0/19
:
sudo tcpdump port 53 and tcp -vv
Verifica i percorsi di ritorno
La rete on-premise deve avere una route verso la destinazione 35.199.192.0/19
L'hop successivo è un tunnel VPN o una connessione Interconnect per lo stesso
Rete VPC che ha inviato la richiesta DNS. Questo comportamento viene descritto
in Creazione di zone di inoltro.
Se utilizzi più tunnel VPN per connettere la stessa rete VPC alla rete on-premise, la risposta non deve essere recapitata utilizzando lo stesso tunnel che l'ha inviato. Tuttavia, la risposta deve essere consegnata utilizzando un Tunnel VPN con un hop successivo nella stessa rete VPC da cui ha avuto origine la richiesta.
Se hai connesso più di una rete VPC al tuo on-premise, devi assicurarti che le risposte DNS non vengano inviate al server uno. Google Cloud ignora le risposte DNS inviate al server rete VPC. Per una soluzione consigliata, consulta le nostre Best practice guida.
L'inoltro in uscita a un server dei nomi che utilizza un indirizzo IP non RFC 1918 non riesce
Per impostazione predefinita, Cloud DNS utilizza il routing standard, instrada le query sulla rete internet pubblica quando il server dei nomi di destinazione un indirizzo IP non RFC 1918. Il routing standard non supporta le query di inoltro a server dei nomi con indirizzi non conformi alla RFC 1918 che non sono raggiungibili dal tramite la rete internet pubblica.
Per inoltrare query a un server dei nomi che utilizza un non RFC 1918 tramite la rete VPC, La zona di forwarding o il criterio del server di Cloud DNS per utilizzare il routing privato per il server dei nomi di destinazione.
Per una spiegazione delle differenze tra il routing standard e il routing privato, vedi target di inoltro e metodi di routing.
Questo limite si applica anche se è presente una route VPC per il server dei nomi di destinazione; per gli indirizzi non RFC 1918 non hanno alcun effetto Comportamento di forwarding in uscita di Cloud DNS quando il routing standard è configurato.
L'inoltro in uscita a un NIC secondario non riesce
Assicurati di aver configurato il controller NIC (Network Interface Controller) secondario in modo corretto.
Per istruzioni su come impostare altre NIC, consulta Creazione di NIC di istanze VM con più reti di archiviazione.
Le query in uscita inoltrate ricevono errori SERVFAIL
Se Cloud DNS riceve un errore da tutti i server dei nomi di destinazione o non
quando riceve una risposta da uno dei server dei nomi di destinazione, restituisce un SERVFAIL
.
Per risolvere il problema, verifica che i server dei nomi on-premise siano correttamente configurato. Poi, verifica che i server dei nomi on-premise rispondano alle query dall'intervallo di indirizzi di Cloud DNS descritto in Aprire Google Cloud e i firewall on-premise per consentire traffico entro 4 secondi. Se i server dei nomi on-premise consultano i server dei nomi upstream (ad esempio, a causa della configurazione come resolver per la memorizzazione nella cache), controlla che ci siano non ci sono problemi con i server dei nomi upstream.
Inoltre, se la destinazione di forwarding è un sistema on-premise, che le route configurate per quel percorso possono essere route dinamiche personalizzate o route statiche, con l'importante eccezione che le route statiche personalizzate i tag di rete non sono validi per l'inoltro delle query DNS. Assicurati che il percorso utilizzato per raggiungere il server dei nomi on-premise non specifica un tag di rete.
Record di risorse
Questa sezione fornisce suggerimenti per la risoluzione dei problemi relativi ai record di risorse.
Dati imprevisti durante l'esecuzione di query per set di record di risorse presenti nella zona
Esistono diversi motivi per cui potresti ricevere dati imprevisti quando esegui query set di record di risorse presenti in una zona gestita di Cloud DNS:
Set di record di risorse creati utilizzando la sintassi
@
specificata in RFC 1035 non sono supportati. Cloud DNS interpreta il simbolo@
in questo il record di risorse viene impostato letteralmente; pertanto, nella zonaexample.com.
, Il set di record creato per la query QNAME@
viene interpretato come@.example.com.
anzichéexample.com.
. Per risolvere questo problema, assicurati di creare set di record senza il simbolo@
; tutti i nomi sono relativi all'apice del zona di destinazione.Come tutti i record, i record CNAME con caratteri jolly sono soggetti ai di regole di esistenza descritte in RFC 4592. Ad esempio: supponiamo che tu definisca i seguenti set di record in
example.com.
zona:*.images.example.com. IN CNAME _static.example.com.
srv1.images.example.com. IN A 192.0.2.91
_static.example.com. IN A 192.0.2.92
Una query per
public.srv1.images.example.com.
restituisceNOERROR
con un una sezione di risposte vuota. L'esistenza di un record tra il record CNAME e QNAME impedisce che venga restituito CNAME, ma non esiste nessun record corrisponde esattamente a QNAME, quindi Cloud DNS restituisce una risposta vuota. Questo è un comportamento DNS standard.
La VM Google Cloud mostra record di puntatore errati (PTR)
Quando viene eseguita la migrazione di una VM durante un evento di manutenzione, la logica del record PTR
gestire correttamente alcuni casi limite e ripristinare i record DNS PTR
Nome di dominio completo (FQDN) googleusercontent.com
. Per ripristinare
applica nuovamente il record PTR.
Per maggiori dettagli su come applicare i record PTR su una VM, consulta Creazione di un record PTR per un'istanza VM.
Set di record di risorse Cloud DNS restituiti in ordine casuale
Coerentemente con le pratiche del settore DNS, nome Cloud DNS i server ora randomizzano l'ordine dei set di record di risorse e ignorano ordinato da un server autorevole. Si tratta di un comportamento DNS normale e si applica sia alle zone Cloud DNS pubbliche sia a quelle private.
Tipo di risorsa di zona non supportato
Quando inserisci il flag --location
in un comando gcloud
o in una richiesta API per
una caratteristica che ha come target una zona Cloud DNS diversa, la richiesta viene
rifiutato. Ad esempio, se invii una richiesta di funzionalità solo a livello di zona a un
server, o una richiesta di funzionalità solo globale a un server di zona, il server rifiuta
la richiesta e restituisce un errore _UNSUPPORTED_ZONAL_RESOURCETYPE.
Per un elenco di risorse e funzionalità supportate da Cloud DNS a livello di zona, consulta Supporto di Cloud DNS.
Passaggi successivi
- Per saperne di più sulle funzionalità, consulta la panoramica di Cloud DNS.
- Per risolvere gli errori, vedi Messaggi di errore.
- Per ricevere ulteriore supporto, vedi Assistenza.