Risoluzione dei problemi di Cloud DNS

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 viene visualizzato un errore attempted action failed, significa che l'API Cloud DNS non è abilitata nel tuo progetto.

Per attivare l'API Cloud DNS:

  1. Nella console Google Cloud, vai alla pagina Libreria API.

    Vai alla libreria API

  2. In Seleziona un progetto recente, seleziona il progetto Google 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 Attiva.

Zone private

Questa sezione illustra i problemi relativi alle zone private.

Problemi relativi alle zone private nei progetti di servizio 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, non è possibile elencare o creare criteri

Per eseguire varie azioni relative alle zone private, ad esempio elencare i criteri dei server DNS (Domain Name System) o creare una zona privata, devi disporre del ruolo Amministratore DNS. Questo ruolo può essere concesso tramite Strumento IAM (Identity and Access Management).

Le zone private non vengono risolte 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 tramite la sua interfaccia principale a meno che il traffico non sia destinato a una subnet collegata a una delle altre interfacce o se nella VM è configurato il routing basato su criteri. 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 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 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 il server dei metadati, 169.254.169.254. In caso contrario, hai configurato il sistema operativo guest in modo da utilizzare un server dei nomi DNS personalizzato anziché il server dei metadati Google Cloud predefinito. Le zone private Cloud DNS richiedono l'utilizzo del server di metadati per la risoluzione dei nomi. Sia l'ambiente guest Linux sia l'ambiente guest Windows lo fanno 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 una rete VPC autorizzata.

Verificare 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 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

Il forwarding DNS richiede subnet, che sono 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 sono identificate nell'output come LEGACY.

Assicurati che nella rete sia presente un indirizzo di inoltro DNS valido.

Il seguente comando 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 non visualizzi un indirizzo IP nella rete/regione che ti aspettavi, invia un ticket all'assistenza Google Cloud.

Esegui il comando dig indirizzando la query all'indirizzo trovato nel comando precedente. Esegui questa operazione 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 segue solo i record CNAME come descritto in Ricerca di 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 consigli, consulta la sezione sulla risoluzione dei problemi relativi alle zone private.

Una VM con indirizzo non RFC 1918 non viene risolta

Riconciliare la VM con un indirizzo non RFC 1918

Se hai creato una VM durante la versione alpha non RFC 1918 prima È stato lanciato 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 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 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 modalità di routing dinamico della rete VPC producer è 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 configurata per inviare il traffico destinato ai server DNS on-premise tramite il tunnel VPN classica. La rete VPC del producer deve inoltre avere una VM o un tunnel VPN nella stessa regione della sottorete utilizzata dalle VM client.

    • Ad esempio, supponiamo che la VPC1 utilizzi una zona di peering che invia query perexample.com. alla VPC2. Supponi anche che il VPC2 abbia una zona di forwarding privata example.com. che inoltra le query a un server dei nomi on-premise utilizzando un Tunnel VPN classica.

      Affinché una VM in us-east1 nel VPC1 possa eseguire query su example.com., il VPC2 deve avere una VM in us-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 una VM di esempio nella tua rete VPC da un ambiente 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

La regola firewall in uscita permessa implicita consente le connessioni in uscita e le risposte stabilite dalle VM nella tua rete VPC, a meno che non abbia creato regole personalizzate per negare l'uscita. Se hai creato regole di esclusione personalizzate, devi creare regole di autorizzazione con priorità più alta che consentano l'esportazione almeno ai 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 proveniente da 35.199.192.0/19 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 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 configurato ACL nel server dei nomi on-premise che blocchino 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 shell, puoi utilizzare uno strumento come tcpdump per cercare i pacchetti in entrata da e i pacchetti 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 per la 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 viene descritto in Creazione di zone di inoltro.

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 consegnata utilizzando un Tunnel VPN con un hop successivo nella stessa rete VPC da cui l'origine della richiesta.

Se hai collegato più di una rete VPC alla tua rete on-premise, devi assicurarti che le risposte DNS non vengano inviate alla rete sbagliata. Google Cloud ignora le risposte DNS inviate al server rete VPC. Per una soluzione consigliata, consulta le nostre Best practice guida.

Il forwarding in uscita a un server DNS che utilizza un indirizzo IP non RFC 1918 non va a buon fine

Per impostazione predefinita, Cloud DNS utilizza il routing standard, instrada le query sulla rete internet pubblica quando il server dei nomi di destinazione non conforme alla RFC 1918. Il routing standard non supporta il forwarding delle query ai server DNS con indirizzi non RFC 1918 non raggiungibili dalla rete internet pubblica.

Per inoltrare le query a un server dei nomi che utilizza un indirizzo IP non RFC 1918 tramite la rete VPC, configura la zona di inoltro o il criterio del server Cloud DNS in modo da 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.

Questa limitazione si applica anche se esiste una route VPC per il nome del server di destinazione. Le route per gli indirizzi non RFC 1918 non influiscono sul comportamento di inoltro in uscita di Cloud DNS quando è configurato il routing standard.

L'inoltro in uscita a una NIC secondaria non riesce

Assicurati di aver configurato correttamente la scheda di interfaccia di rete (NIC) secondaria.

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 riceve una risposta da nessuno di questi, 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 Aprire i firewall Google Cloud e on-premise per consentire il traffico DNS 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 inoltro è un sistema on-premise, tieni presente che le route configurate per quel percorso possono essere route dinamiche o statiche personalizzate, con l'importante eccezione che le route statiche personalizzate con tag di rete non sono valide per l'inoltro delle query DNS. Assicurati che la route utilizzata per raggiungere il server DNS on-premise non specifichi un tag di rete.

Record di risorse

Questa sezione fornisce suggerimenti per la risoluzione dei problemi relativi ai record delle risorse.

Dati imprevisti durante la query sui set di record di risorse presenti nella zona

Esistono diversi motivi per cui potresti ricevere dati imprevisti quando esegui query sui 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 nel RFC 1035 non sono supportati. Cloud DNS interpreta il simbolo @ in questi set di record di risorse in modo letterale. Pertanto, nella zona example.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'apice della zona.

  2. Come tutti i record, i record CNAME con caratteri jolly sono soggetti alle regole di esistenza descritte nel RFC 4592. Ad esempio, supponi di definire 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 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 non gestisce correttamente alcuni casi limite e ripristina i record PTR DNS al 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 su una VM, consulta Creazione di un record PTR per un'istanza VM.

Set di record di risorse Cloud DNS restituiti in ordine casuale

In linea con le pratiche del settore DNS, i server dei nomi Cloud DNS ora randomizzano l'ordine degli insiemi di record di risorse e ignorano l'ordinamento specificato dal server autorevole. Si tratta di un normale comportamento DNS e si applica sia alle zone Cloud DNS pubbliche che 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 delle risorse e delle funzionalità supportate da Cloud DNS zonale, consulta Supporto di Cloud DNS zonale.

Passaggi successivi