Questa pagina fornisce soluzioni per i problemi comuni che potresti riscontrare quando utilizzi Cloud DNS per creare zone pubbliche, zone 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 visualizzi l'errore attempted action failed, significa che l'API Cloud DNS non è abilitata nel tuo progetto.
Per abilitare l'API Cloud DNS:
Nella console Google Cloud , vai alla pagina Libreria API.
Per 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 cercare
Cloud DNS API. Verrà visualizzata una pagina che descrive l'API.Fai clic su Abilita.
Zone private
Questa sezione tratta i problemi relativi alle zone private.
Problemi relativi alle zone private nei progetti di servizio con VPC condiviso
Per informazioni importanti sull'utilizzo di zone private con le reti VPC condivise, consulta Zone private e VPC condiviso.
Impossibile creare una zona privata, elencare o creare policy
Devi avere il ruolo DNS Administrator per eseguire varie azioni sulle zone private, ad esempio elencare le policy del server DNS (Domain Name System) o creare una zona privata. Questo ruolo può essere concesso tramite lo strumento Identity and Access Management (IAM).
Le zone private non vengono risolte nella stessa rete VPC
Innanzitutto, assicurati di eseguire il test dalla stessa rete.
Verifica che l'interfaccia principale della tua istanza VM si trovi 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 altre interfacce o se la VM ha configurato il routing basato su policy. Assicurati che l'interfaccia principale della VM di test si trovi sulla stessa rete della zona privata che stai testando.
Verifica che la VM utilizzi:
gcloud compute instances describe VM_NAME \
--zone=GCE_ZONE \
--format="csv[no-heading](networkInterfaces['network'])"
Assicurati che la rete sia presente nell'elenco delle reti autorizzate a eseguire query sulla tua 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 all'ordine di risoluzione dei nomi, utilizzando la zona con il suffisso più lungo per decidere su quale zona eseguire query per un determinato nome DNS. Assicurati che il suffisso del record su cui stai eseguendo query corrisponda ad almeno una zona privata accessibile nella tua rete VPC. Ad esempio, Google Cloudcerca myapp.dev.gcp.example.lan in una zona che serve dev.gcp.example.lan, se accessibile, prima di cercarlo in una zona che serve gcp.example.lan, se accessibile.
L'output del comando seguente mostra il suffisso DNS per una determinata zona privata:
gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
--format="csv[no-heading](dnsName)"
Esegui una query per il nome DNS utilizzando il server dei metadati
Utilizza dig per inviare la query del nome DNS direttamente al server dei metadati Google Cloud, 169.254.169.254:
dig DNS_NAME @169.254.169.254
Utilizza dig per eseguire una query sul server dei nomi predefinito della VM:
dig DNS_NAME
Se l'output dei due comandi dig produce risposte diverse, controlla la sezione ;; SERVER: del secondo comando. Il server di risposta deve essere il server dei metadati, 169.254.169.254. In caso contrario, hai configurato il sistema operativo guest in modo che utilizzi un server dei nomi DNS personalizzato anziché il server dei metadatiGoogle Cloud predefinito. Le zone private di Cloud DNS richiedono l'utilizzo del server dei metadati per la risoluzione dei nomi. Sia l'ambiente guest Linux sia l'ambiente guest Windows lo fanno per conto tuo. Se hai importato l'immagine che utilizzi per una VM, verifica 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 una rete VPC autorizzata.
Verifica la connettività tramite Cloud VPN o Cloud Interconnect
Assicurati che la connettività da un sistema on-premise alla tua rete VPC sia operativa. In particolare, il traffico TCP e UDP sulla porta 53 deve poter uscire dalla rete on-premise ed essere recapitato alla rete VPC. Verifica la configurazione dei firewall on-premise per assicurarti che questo traffico in uscita sia consentito.
Puoi utilizzare qualsiasi protocollo, ad esempio ping (ICMP), per testare la connettività a una VM di esempio nella tua rete VPC da on-premise. Sebbene le richieste Cloud DNS non vengano inviate alle VM Google Cloud , il test della connettività a una VM di esempio ti consente di verificare la connettività tramite un tunnel Cloud VPN o una connessione Cloud Interconnect. Assicurati di configurare una regola firewall di autorizzazione in entrata appropriata per la VMGoogle Cloud di esempio, perché la regola implicita di negazione in entrata blocca tutto il traffico in entrata.
Assicurati che il forwarding in entrata sia abilitato per la rete VPC autorizzata
Il forwarding in entrata deve essere abilitato per ogni rete VPC autorizzata a eseguire query sulla tua zona privata Cloud DNS. Utilizza il comando seguente per elencare tutte le policy:
gcloud dns policies list
Identifica la rete nella tabella di output e controlla il campo Forwarding per vedere se il forwarding è abilitato.
Assicurati che la rete autorizzata sia una rete VPC
Il forwarding DNS richiede subnet, disponibili solo per le reti VPC, non per le reti legacy.
gcloud compute networks list \
--format="csv[no-heading](name, SUBNET_MODE)"
Le reti legacy vengono identificate nell'output come LEGACY.
Assicurati che nella rete sia prenotato un indirizzo di forwarding DNS valido
Il comando seguente mostra tutti gli indirizzi IP di forwarding DNS prenotati 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 alla sola subnet che ti interessa.
Esempio:
--filter="name ~ ^dns-forwarding AND subnetwork ~ SUBNETWORK_NAME"
Se nella rete o nella regione non vedi un indirizzo IP che ti aspettavi, invia un ticket all'assistenzaGoogle Cloud .
Esegui il comando dig puntando la query all'indirizzo trovato nel comando precedente. Esegui questa operazione da una VM nella stessa rete. Questo test verifica che l'agente di inoltro in entrata funzioni e che il problema si trovi altrove.
dig DNS_NAME @10.150.0.1 # address returned by previous command
Ripeti lo stesso comando dig, ma da un host on-premise tramite la VPN.
Il record CNAME definito in una zona privata non funziona
Cloud DNS ricerca soltanto i record CNAME come descritto in Ricerca del CNAME.
Zone di ricerca inversa
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 altri suggerimenti, consulta la sezione di risoluzione dei problemi relativi alle zone private.
Una VM con indirizzo non RFC 1918 non viene risolta
Se hai un indirizzo non RFC 1918, riconcilia la VM.
Riconcilia la VM con un indirizzo non RFC 1918
Se hai creato una VM durante la fase alpha non RFC 1918 prima del lancio del supporto di Cloud DNS, queste VM potrebbero non venire risolte correttamente. Per risolvere il problema, riavvia le VM.
Zone di forwarding
Questa sezione fornisce suggerimenti per la risoluzione dei problemi relativi alle zone di forwarding. Alcuni problemi relativi alle zone private si applicano anche alle zone di forwarding. Per altri suggerimenti, consulta la sezione di risoluzione dei problemi relativi alle zone private.
Le zone di forwarding (forwarding in uscita) non funzionano
Innanzitutto, assicurati di poter eseguire query e risolvere correttamente il nome DNS da una rete VPC autorizzata.
Il forwarding delle query dalle VM in una rete VPC consumer a una rete VPC producer non funziona
Se utilizzi il peering DNS e vuoi inoltrare query dalle VM in una rete VPC consumer a una rete VPC producer e poi a uno o più server dei nomi on-premise, assicurati che uno dei seguenti prerequisiti sia soddisfatto:
La rete VPC producer ha la modalità di routing dinamico impostata su
GLOBALLa VM nella rete VPC consumer si trova nella stessa regione del tunnel VPN o di Cloud Interconnect nella rete VPC producer
(Solo VPN classica) La rete VPC producer ha una route statica configurata per inviare il traffico destinato ai server dei nomi on-premise tramite il tunnel per VPN classica. La rete VPC producer deve avere anche una VM o un tunnel VPN nella stessa regione della subnet utilizzata dalle VM client.
Ad esempio, supponiamo che VPC1 utilizzi una zona di peering che invia query per
example.com.a VPC2. Supponiamo anche che VPC2 abbia una zona di forwarding privata perexample.com.che inoltra le query a un server dei nomi on-premise utilizzando un tunnel per VPN classica.Affinché una VM che si trova in
us-east1in VPC1 possa eseguire query suexample.com., VPC2 deve avere una VM inus-east1. Deve essere configurata anche una route statica che copra gli intervalli CIDR dei server dei nomi on-premise, con l'hop successivo configurato come tunnel per VPN classica.Verifica la connettività tramite Cloud VPN o Cloud Interconnect
Puoi utilizzare qualsiasi protocollo, ad esempio ping (ICMP), per testare la connettività a una VM di esempio nella tua rete VPC da on-premise. Devi anche tentare di eseguire query sul server dei nomi on-premise direttamente da una VMGoogle Cloud di esempio utilizzando uno strumento come dig:
dig DNS_NAME @192.168.x.x # address of the onprem DNS server
Controlla le regole firewall nella tua rete VPC
La regola firewall implicita di autorizzazione in uscita consente le connessioni in uscita e le risposte stabilite dalle VM nella tua rete VPC, a meno che tu non abbia creato regole personalizzate per negare il traffico in uscita. Se hai creato regole personalizzate di negazione in uscita, devi creare regole di autorizzazione con priorità più alta che consentano il traffico in uscita almeno verso i tuoi 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 individuare le richieste DNS provenienti da 35.199.192.0/19. Per usare un'espressione regex per la 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 avere ACL configurate 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 hai accesso alla shell, puoi utilizzare uno strumento come tcpdump per cercare i pacchetti in entrata da e in uscita verso 35.199.192.0/19:
sudo tcpdump port 53 and tcp -vv
Verifica le route di ritorno
La tua rete on-premise deve avere una route alla destinazione 35.199.192.0/19 con l'hop successivo impostato come un tunnel VPN o una connessione Interconnect per la stessa rete VPC che ha inviato la richiesta DNS. Questo comportamento è descritto in Crea una zona di forwarding.
Se utilizzi più tunnel VPN per connettere la stessa rete VPC alla tua rete on-premise, la risposta non deve essere inviata utilizzando lo stesso tunnel che l'ha inviata. Tuttavia, la risposta deve essere inviata 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 alla tua rete on-premise, devi assicurarti che le risposte DNS non vengano inviate a quella errata. Google Cloud ignora le risposte DNS inviate alla rete VPC errata. Per una soluzione consigliata, consulta la nostra guida alle best practice.
Il forwarding in uscita a un server dei nomi che utilizza un indirizzo IP non RFC 1918 non va a buon fine
Per impostazione predefinita, Cloud DNS utilizza il routing standard, che instrada le query tramite internet pubblico quando il server dei nomi di destinazione ha un indirizzo IP non RFC 1918. Il routing standard non supporta l'inoltro di query ai server dei nomi con indirizzi non RFC 1918 non raggiungibili da internet pubblico.
Per inoltrare le query a un server dei nomi che utilizza un indirizzo IP non RFC 1918 tramite la tua rete VPC, configura la zona di forwarding o la policy del server Cloud DNS in modo che utilizzi il routing privato per il server dei nomi di destinazione.
Per una spiegazione delle differenze tra routing standard e privato, consulta le destinazioni di forwarding e i metodi di routing.
Questa limitazione si applica anche se esiste una route VPC per il server dei nomi di destinazione; le route per gli indirizzi non RFC 1918 non hanno alcun effetto sul comportamento di forwarding in uscita di Cloud DNS quando è configurato il routing standard.
Il forwarding in uscita a un controller dell'interfaccia di rete (NIC) secondario non riesce
Assicurati di aver configurato correttamente il controller di interfaccia di rete (NIC) secondario.
Per istruzioni su come configurare NIC aggiuntivi, consulta Crea istanze di macchine virtuali con più interfacce di rete.
Le query inoltrate in uscita ricevono errori SERVFAIL
Se Cloud DNS riceve un errore da tutti i server dei nomi di destinazione o non riceve una risposta da nessuno dei server dei nomi di destinazione, restituisce un errore SERVFAIL.
Per risolvere il problema, verifica che i server dei nomi on-premise siano configurati correttamente. Poi, verifica che i server dei nomi on-premise rispondano alle query dall'intervallo di indirizzi Cloud DNS descritto in Apri Google Cloude i firewall on-premise per consentire il traffico DNS entro 4 secondi. Se i tuoi server dei nomi on-premise consultano i server dei nomi upstream (ad esempio perché sono configurati come resolver di memorizzazione nella cache), verifica che non ci siano problemi con i server dei nomi upstream.
Inoltre, se la destinazione di forwarding è un sistema on-premise, tieni presente che le route configurate per quel percorso possono essere route dinamiche personalizzate o route statiche personalizzate, con l'importante eccezione che le route statiche personalizzate con tag di rete non sono valide per il forwarding delle query DNS. Assicurati che la route utilizzata per raggiungere il server dei nomi on-premise non specifichi 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 i set di record di risorse presenti nella zona
Esistono diversi motivi per cui potresti ricevere dati imprevisti quando esegui query per i set di record di risorse presenti in una zona gestita di Cloud DNS:
I set di record di risorse creati utilizzando la sintassi
@specificata in RFC 1035 non sono supportati. Cloud DNS interpreta il simbolo@nei set di record di risorse in modo letterale; pertanto, nella zonaexample.com., un set di record creato per il QNAME@viene interpretato come@.example.com.anzichéexample.com.. Per risolvere il problema, assicurati di creare set di record senza il simbolo@; tutti i nomi sono relativi all'apex della zona.Come tutti i record, i record CNAME con caratteri jolly sono soggetti alle regole di esistenza descritte in RFC 4592. Ad esempio, supponiamo di definire i set di record seguenti nella zona
example.com.:*.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.92Una query per
public.srv1.images.example.com.restituisceNOERRORcon una sezione di risposta vuota. L'esistenza di un record tra il CNAME e il QNAME impedisce la restituzione del CNAME, ma non essendoci un record che corrisponde esattamente al QNAME, Cloud DNS restituisce una risposta vuota. Si tratta di un comportamento DNS standard.
La VMGoogle Cloud mostra record PTR (pointer) errati
Quando viene eseguita la migrazione di una VM durante un evento di manutenzione, la logica dei record PTR non gestisce correttamente alcuni casi limite e ripristina i record PTR DNS al nome di dominio completo (FQDN) googleusercontent.com. Per ripristinarne la funzionalità, applica di nuovo il record PTR.
Per informazioni dettagliate su come applicare i record PTR a una VM, consulta Crea un record PTR per un'istanza VM.
I set di record di risorse Cloud DNS vengono restituiti in ordine casuale
In linea con le pratiche del settore DNS, i server dei nomi Cloud DNS ora randomizzano l'ordine dei set di record di risorse e ignorano l'ordinamento indicato dal server autoritativo. Si tratta del 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 funzionalità che ha come target una zona Cloud DNS diversa, la richiesta viene rifiutata. Ad esempio, se invii una richiesta di funzionalità solo a livello di zona a un server globale o una richiesta di funzionalità solo a livello globale a un server a livello di zona, il server rifiuta la richiesta e restituisce un errore _UNSUPPORTED_ZONAL_RESOURCETYPE.
Per un elenco delle risorse e delle funzionalità supportate da Cloud DNS a livello di zona, consulta Supporto di Cloud DNS a livello di zona.
Rilevamento avanzato delle minacce
Questa sezione fornisce informazioni sui problemi che potresti riscontrare durante l'utilizzo di DNS Armor e suggerimenti su come risolverli.
Le metriche non mostrano query DNS inviate al rilevatore di minacce o ne mostrano poche
Innanzitutto, verifica di avere un rilevatore di minacce DNS.
Verifica il rilevatore di minacce DNS
Nella console Google Cloud , vai alla pagina Rilevamento avanzato delle minacce.
Verifica che sia elencato un rilevatore di minacce.
Verifica di avere query su internet
I log delle query vengono inviati solo quando vengono effettuate query o richieste su internet relative alla tua rete.
Nella console Google Cloud , vai alla pagina Monitoring.
In Metrica, seleziona
Cloud DNS Query, quindi scegliQueryeDNS response counts.Visualizza le metriche per i tipi di destinazione su internet.
In alternativa, se hai abilitato Cloud Logging per le query DNS, utilizza Esplora log per verificare di avere query su internet.
Nella console Google Cloud , vai alla pagina Esplora log.
Visualizza i log DNS e verifica la presenza di query su internet.
I log degli eventi di minaccia non vengono restituiti
Se gli eventi di minaccia non vengono ricevuti da Cloud Logging, verifica innanzitutto che sia configurato un rilevatore avanzato di minacce nella dashboard. Tieni presente che i log degli eventi di minaccia vengono restituiti solo quando viene rilevata una minaccia.
Verifica che il rilevamento delle minacce sia abilitato
Nella console Google Cloud , vai alla pagina Rilevamento avanzato delle minacce.
Verifica che sia elencato un rilevatore di minacce.
Gli eventi di minacce DNS non vengono generati per alcuni domini illeciti o non validi
Alcuni eventi di minaccia DNS relativi a domini illeciti o non validi potrebbero non essere generati per i domini ottenuti da elenchi pubblici di domini non validi su internet, poiché i domini di minaccia DNS cambiano di frequente. I domini vecchi o scaduti in questi elenchi non generano eventi di minaccia DNS.
Di seguito sono riportati i domini di test che puoi utilizzare per verificare i domini di minaccia DNS:
- dnst-gcp-blox.com
- ftags-gcp-blox.com
- dga-gcp-blox.com
Verifica che gli eventi di minaccia DNS vengano generati per i domini di test
Accedi a una VM che fa parte del progetto che stai monitorando.
Apri un terminale ed esegui un comando dig per uno dei domini di test.
domain=TEST_DOMAIN
dig $domain -t ASostituisci
TEST_DOMAINcon uno dei domini elencati.Apri la console Google Cloud e vai alla pagina Esplora log.
Esegui la query seguente:
resource.type="networksecurity.googleapis.com/DnsThreatDetector"Cerca il dominio di test che hai utilizzato nel comando dig.
Questi domini generano eventi di minaccia DNS. Se non riesci a trovare i log DNS per i domini elencati, contatta l'assistenza.
Passaggi successivi
- Per scoprire di più sulle funzionalità di Cloud DNS, consulta la panoramica di Cloud DNS.
- Per risolvere gli errori, consulta Messaggi di errore.
- Per ricevere ulteriore supporto, consulta la pagina di assistenza.