Risolvere i problemi

Questa pagina fornisce soluzioni ai problemi comuni che potresti riscontrare utilizzando Cloud DNS per creare zone private, zone di ricerca inversa, zone di forwarding e record di risorse.

Zone pubbliche

Questa sezione riguarda i problemi relativi alle zone pubbliche

Impossibile creare una zona pubblica

Se viene visualizzato un errore attempted action failed, significa che l'API Cloud DNS non è abilitata per il tuo progetto.

Per abilitare l'API Cloud DNS:

  1. Vai alla pagina Libreria API della console.
    Vai alla pagina Libreria API
  2. In Seleziona un progetto recente, seleziona il progetto Cloud in cui vuoi abilitare l'API.
  3. Nella pagina Libreria API, utilizza la casella Cerca API e servizi per cercare Cloud DNS API. Viene visualizzata una pagina che descrive l'API.
  4. Fai clic su Abilita.

Zone private

Questa sezione illustra i problemi relativi alle zone private.

Problemi relativi alla zona privata nei progetti di servizio VPC condiviso

Per informazioni importanti sull'utilizzo delle zone private con le reti VPC condivise, consulta Zone private e VPC condivisi.

Impossibile creare una zona privata, non può elencare o creare criteri

Devi avere il ruolo di DNS DNS per eseguire varie azioni della zona privata, come elencare i criteri 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 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 dalla sua interfaccia principale a meno che il traffico non sia destinato a una subnet collegata a una delle altre interfaccia o se alla VM è configurato il routing dei criteri. Assicurati che la tua VM di test abbia l'interfaccia principale sulla stessa rete della zona privata che stai testando.

Determina che la tua VM stia utilizzando:

gcloud compute instances describe VM_NAME \
  --zone=GCE_ZONE \
  --format="csv[no-heading](networkInterfaces['network'])"

Assicurati che la rete sia inclusa nell'elenco delle reti autorizzate a eseguire query sulla 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 utilizza la corrispondenza più lunga per decidere quale zona interrogare per un dato nome DNS. Assicurati che il suffisso per il record che stai interrogando corrisponda ad almeno una zona privata accessibile nella tua rete VPC. Ad esempio, Google Cloud cerca prima myapp.dev.gcp.example.lan in una zona che serve 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 una determinata zona privata:

gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
  --format="csv[no-heading](dnsName)"

Query per il nome DNS utilizzando il server dei metadati

Utilizza dig per inviare la query al nome DNS direttamente al server di 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 di 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 predefinito dei metadati di Google Cloud. Le zone private di Cloud DNS richiedono di utilizzare il server dei metadati per la risoluzione dei nomi. Sia l'ambiente ospite di Linux sia l'ambiente guest di Windows fanno tutto questo. Se hai importato l'immagine che stai utilizzando per una VM, verifica che sia stato installato l'ambiente guest appropriato.

Le zone private non vengono risolte tramite Cloud VPN o Cloud Interconnect

Assicurati prima di poter eseguire query e risolvere 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 rete VPC sia operativa. In particolare, il traffico TCP e UDP sulla porta 53 deve essere in grado di uscire dalla tua rete on-premise e di essere consegnato alla tua rete VPC. Verifica la configurazione dei firewall on-premise per assicurarti che il 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 di connettività a una VM di esempio 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 VM Google Cloud di esempio, perché la regola di traffico in entrata implicito blocca tutto il traffico in entrata.

Assicurati che l'inoltro in entrata sia abilitato per la rete VPC autorizzata

L'inoltro in entrata deve essere abilitato per ogni rete VPC autorizzata a eseguire query sulla zona privata Cloud DNS. Utilizza il seguente comando per elencare tutti i criteri:

gcloud dns policies list

Identifica la rete nella tabella di output e controlla il campo Inoltro per verificare se l'inoltro è attivato.

Assicurati che la rete autorizzata sia una rete VPC

L'inoltro DNS richiede subnet, che sono disponibili solo per reti VPC, non reti legacy.

gcloud compute networks list \
  --format="csv[no-heading](name, SUBNET_MODE)"

Le reti precedenti sono identificate nell'output come LEGACY.

Assicurarsi che la rete contenga un indirizzo di forwarding DNS valido

Il comando seguente mostra tutti gli indirizzi IP di inoltro DNS riservati nel 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 alla subnet che ti interessa.

Esempio:

--filter="name ~ ^dns-forwarding AND subnetwork ~ SUBNETWORK_NAME"

Se non vedi un indirizzo IP nella rete o nell'area geografica che ti aspettavi, invia una richiesta di assistenza all'assistenza Google Cloud.

Esegui il comando dig che punta la query all'indirizzo trovato nel comando precedente. Esegui questa operazione da una VM nella stessa rete. Questo test verifica che l'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 sulla VPN.

Record CNAME definito in una zona privata non funzionante

I record CNAME in zone Cloud DNS private sono supportati dal resolver DNS di Compute Engine quando il target è uno dei seguenti:

I record CNAME non possono avere come target altre risorse. Per ulteriori informazioni, consulta la pagina CNAME chasing.

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.

VM con indirizzo non RFC 1918 non risolta

Riconcilia la tua VM con un indirizzo non conforme alla RFC 1918

Se hai creato una VM durante la fase alpha non RFC 1918 prima del lancio del supporto Cloud DNS, è possibile che queste VM non si risolvano correttamente. Per risolvere questo 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 inoltro. Per ulteriori suggerimenti, consulta la sezione per la risoluzione dei problemi relativi alle Zone private.

Le zone di inoltro (inoltro in uscita) non funzionano

Assicurati prima di poter eseguire query e risolvere il nome DNS da una rete VPC autorizzata.

Inoltro delle query dalle VM in una rete VPC consumer a una rete VPC producer non funzionante

Se utilizzi il peering DNS e vuoi inoltrare le query da VM in una rete VPC consumer a una rete VPC producer e poi a uno o più server dei nomi on-premise, devi assicurarti che la rete VPC producer abbia una VM o un tunnel VPN nella stessa regione della subnet utilizzata dalle VM client.

Supponi ad esempio 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 per example.com. che inoltra le query a un server dei nomi on-premise utilizzando un tunnel Cloud VPN o Cloud Interconnect. Affinché una VM situata in us-east1 in VPC1 possa eseguire query su example.com., VPC2 deve avere anche un tunnel VM o VPN in us-east1.

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 una query sul server dei nomi on-premise direttamente da una VM Google Cloud di esempio utilizzando uno strumento come dig:

dig DNS_NAME @192.168.x.x # address of the onprem DNS server

Verifica le regole firewall nella tua rete VPC

La regola implicita per il firewall 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 di negazione personalizzate in uscita, dovrai creare regole di autorizzazione con priorità più elevata che consentano il traffico di almeno server dei nomi on-premise.

Controlla il firewall on-premise

Assicurati che il tuo firewall on-premise sia configurato in modo da consentire il traffico in entrata e in uscita da 35.199.192.0/19.

Controlla i log nel firewall on-premise, cercando le richieste DNS da 35.199.192.0/19. Per utilizzare un'espressione regex per eseguire 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 alcun ACL nel server dei nomi on-premise, in modo da bloccare le query da 35.199.192.0/19.

Controlla il server dei nomi on-premise per verificare 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 i percorsi di ritorno

La tua rete on-premise deve avere una route alla destinazione 35.199.192.0/19 con l'hop successivo che è un tunnel VPN o una connessione Interconnect per la stessa rete VPC che ha inviato la richiesta DNS. Questo comportamento è descritto nella sezione Creare zone di forwarding.

Se utilizzi più tunnel VPN per connettere la stessa rete VPC alla tua rete on-premise, la risposta non deve essere recapitata utilizzando lo stesso tunnel che l'ha inviata. Tuttavia, la risposta deve essere recapitata 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 sbagliata. Google Cloud elimina le risposte DNS inviate alla rete VPC errata. Per una soluzione consigliata, consulta la nostra guida relativa alle best practice.

L'inoltro in uscita a un server dei nomi che utilizza un indirizzo IP non conforme alla RFC 1918 non riesce

Per impostazione predefinita, Cloud DNS utilizza il routing standard, che prevede il routing delle query attraverso la rete Internet pubblica quando il server dei nomi target ha un indirizzo IP non conforme alla RFC 1918. Il routing standard non supporta le query di inoltro ai server dei nomi con indirizzi non conformi alla RFC 1918, non raggiungibili dalla rete Internet pubblica.

Per inoltrare le query a un server dei nomi che utilizza un indirizzo IP non conforme alla RFC 1918 tramite la tua rete VPC, configura la zona di forwarding Cloud DNS o il criterio del server per utilizzare il routing privato per il server dei nomi di destinazione.

Per una spiegazione delle differenze tra routing standard e routing privato, vedi target di destinazione e 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 effetto sul comportamento di inoltro in uscita di Cloud DNS quando è configurato il routing standard.

Inoltro in uscita a un NIC secondario non riuscito

Assicurati di aver configurato correttamente il controller dell'interfaccia di rete secondaria (NIC).

Per istruzioni su come configurare schede NIC aggiuntive, consulta Creazione di istanze di macchine virtuali con più interfaccia di rete.

Le query in uscita ricevono errori di 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 questo problema, verifica che i tuoi server dei nomi on-premise siano configurati correttamente. Quindi, verifica che i tuoi server dei nomi on-premise rispondano alle query nell'intervallo di indirizzi Cloud DNS descritto in Aprire Google Cloud e 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 a monte (ad esempio, perché sono configurati come resolver di memorizzazione nella cache), assicurati che non siano presenti problemi con i server dei nomi a monte.

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 la eccezione importante che le route statiche personalizzate con tag di rete non sono valide per le query DNS di forwarding. Assicurati che la route utilizzata per raggiungere il server dei nomi on-premise non specifichi un tag di rete.

L'inoltro in entrata non riesce su una rete VPC le cui subnet utilizzano intervalli di indirizzi IP non conformi alla RFC 1918.

Cloud DNS non supporta l'inoltro in entrata se la rete VPC contiene subnet i cui intervalli di indirizzi IP non rientrano negli intervalli RFC 1918.

Record di risorse

Questa sezione fornisce suggerimenti per la risoluzione dei problemi dei record di risorse.

Dati imprevisti quando si eseguono query per set di record di risorse presenti nella zona

Esistono diversi motivi per cui potresti ricevere dati imprevisti durante l'esecuzione di query per i set di record di risorse presenti in una zona gestita di Cloud DNS:

  1. I set di record di risorse creati utilizzando la sintassi @ specificata in RFC 1035 non sono supportati. Cloud DNS interpreta il simbolo @ in tali set di record di risorse, pertanto nella zona example.com. un set di record creato per 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'apice della zona.

  2. Come tutti i record, i record CNAME con caratteri jolly sono soggetti alle regole di esistenza descritte in RFC 4592. Ad esempio, supponiamo che tu definisca i seguenti set di record 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.92

    Una query per public.srv1.images.example.com. restituisce NOERROR con una sezione di risposta vuota. L'esistenza di un record tra CNAME e QNAME impedisce che venga restituito il CNAME, ma non esiste un record che corrisponda esattamente a QNAME, quindi Cloud DNS restituisce una risposta vuota. Si tratta di un comportamento DNS standard.

La VM Google Cloud mostra record puntatori errati (PTR)

Quando viene eseguita la migrazione di una VM durante un evento di manutenzione, la logica del record PTR non gestisce correttamente alcuni casi perimetrali e ripristina i record PTR DNS nel nome di dominio completo (FQDN) googleusercontent.com. Per ripristinare la funzionalità, applica di nuovo il record PTR.

Per maggiori dettagli su come applicare i record PTR a una VM, consulta la sezione Creazione di un record PTR per un'istanza VM.

Set di record di risorse Cloud DNS restituiti in ordine casuale

In conformità 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 assegnato dal server autorevole. Si tratta di un normale comportamento DNS che si applica sia alle zone Cloud DNS pubbliche sia 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 a una richiesta di funzionalità solo 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 il supporto per Cloud DNS a livello di zona.

Passaggi successivi