Quando Google Public DNS non è in grado di risolvere un dominio, è spesso a causa di un problema con quel dominio o con i suoi server dei nomi autorevoli. I seguenti passaggi possono aiutare a determinare la causa del problema, in modo che gli amministratori di dominio possano risolverlo autonomamente.
Prima di iniziare, controlla il dominio all'indirizzo dns.google come descritto nella pagina generale per la risoluzione dei problemi, che potrebbe indirizzare a un determinato passaggio di diagnostica di seguito. In caso contrario, prova a eseguire tutti i passaggi seguenti fino a trovare la causa.
Passaggio 1: controlla se ci sono problemi di convalida DNSSEC
Se le ricerche web dns.google per il dominio mostrano "Status": 2 (SERVFAIL) e
query senza DNSSEC riuscite, potrebbe esserci un problema DNSSSEC
con i server dei nomi del dominio o il relativo registro di dominio di primo livello (TLD)
(che pubblica i record DS per la convalida DNSSEC dei domini registrati).
- Modifiche al registrar o al servizio DNS
I problemi relativi a DNSSEC possono verificarsi dopo che un dominio passa da un registrar o servizio DNS che supporta DNSSEC a uno che non li supporta. Se il servizio precedente lascia record
DSinattivi nel registro di dominio di primo livello e il nuovo servizio non crea nuovi recordDNSKEYcon recordDScorrispondenti nel registro di dominio di primo livello, la convalida dei resolver come Google Public DNS non può risolvere il dominio.In questo caso, chiedi al registrar di dominio di rimuovere i record DS inattivi dal registro di dominio di primo livello.
- Le risposte DNSSEC sono troppo grandi
Un'altra causa dei problemi relativi a DNSSEC è l'utilizzo di risposte DNSSEC troppo grandi per essere inserite in un pacchetto IP, creando risposte frammentate che potrebbero essere eliminate. Se DNSViz mostra "nessuna risposta ricevuta fino a quando le dimensioni del payload UDP non sono state ridotte", gli errori DNSSEC possono essere causati da risposte molto grandi. Le dimensioni delle risposte possono essere ridotte con una o più delle seguenti azioni:
- Configura "risposte minime" per i server dei nomi autorevoli
- Riduci il numero di record
DNSKEYattivi a due o tre - Utilizza i record
DNSKEYa 1280 o 2048 bit (RFC 6781, StackExchange) - Passa dalle firme RSA a quelle ECDSA più piccole (RFC 8624)
Controlla anche se ci sono altri problemi relativi alle DNSSEC segnalati dagli strumenti nel passaggio 2. Gli esempi includono NSEC o NSEC3 non validi che indicano che non sono presenti sottodomini (le istanze DNS (DNS con zone archiviate in database esterni) potrebbero averne) o firme RRSIG scadute (con processi di firma configurati manualmente che non funzionano).
Passaggio 2: controlla i server dei nomi autorevoli
Se Google Public DNS (o un resolver aperto) ha un problema durante la risoluzione di un dominio, DNSViz mostra i problemi relativi al dominio e al server dei nomi che lo causano. Vai alla pagina web DNSViz e inserisci il nome del dominio problematico. Se DNSViz non ha dati storici o ha solo dati risalenti a più di un giorno prima della data corrente (come mostrato nella pagina), fai clic sul pulsante grande Analizza per visualizzare un pulsante Analizza più piccolo di seguito (se non è già visibile) e fai clic anche su questo. Al termine dell'analisi, fai clic su "Continua" per visualizzare i risultati. Fai clic sugli errori rossi e sugli avvisi gialli nella barra laterale sinistra per visualizzare i dettagli o tieni il puntatore del mouse sugli oggetti nel diagramma per aprire queste informazioni nel contesto.
Se la diagnostica precedente ha indicato possibili problemi DNSSEC con il dominio, vai alla pagina web dello strumento di analisi DNS e inserisci il nome del dominio. Se questo analizzatore segnala errori o avvisi DNSSEC, tieni il puntatore del mouse sulle icone
La pagina web intoDNS mostra i problemi non DNSSEC con il dominio inserito nella pagina principale e mostra anche suggerimenti per risolverli.
Gli amministratori di dominio dovrebbero correggere la maggior parte degli errori segnalati da questi strumenti, poiché possono causare problemi non solo per Google Public DNS, ma anche per altri resolver.
Passaggio 3: controlla se ci sono problemi di delega
Google Public DNS è un resolver incentrato sui genitori che utilizza solo i server dei nomi restituiti nei referral dal dominio principale. Se i nomi e gli indirizzi di glue server del nome nel dominio di primo livello sono obsoleti o errati, potrebbero verificarsi problemi di delega.
Se DNSViz o inDNS segnalano avvisi su incongruenze tra i server dei nomi delegati nel TLD e quelli presenti nel dominio secondario stesso, potrebbe essere necessario risolvere i problemi prima che Google Public DNS possa risolvere il dominio. Se questi strumenti segnalano che il dominio registrato non esiste (NXDOMAIN), verifica che il dominio non sia scaduto o che sia in attesa di registrazione per qualsiasi motivo.
I problemi di delega possono anche essere causati da un errore di risoluzione dei nomi dei server dei nomi per un dominio. Controlla i record A e AAAA dei server dei nomi su dns.google per verificare l'eventuale presenza di problemi con i domini dei server dei nomi.
Passaggio 4: controlla la presenza di risposte di grandi dimensioni.
Il DNS si basa su UDP per trasferire la maggior parte del traffico. I datagrammi UDP di grandi dimensioni sono soggetti a frammentazione e le UDP frammentate soffrono di distribuzione inaffidabile. Questo è stato il tema del DNS Flag Day 2020, l'impegno per migliorare l'affidabilità del DNS a livello globale. Google Public DNS ha partecipato a questo impegno e limita le dimensioni delle risposte UDP accettate su UDP. Prova a eseguire una query come quelle riportate di seguito con il tuo prompt dei comandi o con Google Cloud Shell:
$ dig +short example.com NS ns1.example.com ns2.example.com $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY ...
Queste query per vari tipi di record specificano:
+dnssec- Abilita le DNSSEC, in particolare restituire i record richiesti per la convalida di DNSSEC quando sono disponibili. Queste possono espandere in modo significativo le dimensioni del risultato. Emula il comportamento di Google Public DNS.
+bufsize=1400- Limita la dimensione del buffer UDP consentita. Emula il comportamento di Google Public DNS, in base all'impegno per il DNS Flag Day 2020.
+timeout=1- Imposta il timeout su un secondo. Emula il comportamento di Google Public DNS.
@ns1.example.com- Quale server autorevole eseguire la query: mantieni il segno
@, ma sostituiscilo con il server autore del dominio, come mostrato dal primo comando.
Osserva l'output; vedi una riga come:
;; Truncated, retrying in TCP mode.- Indica che la risposta era più grande della dimensione del buffer UDP richiesta, quindi è stata troncata e in risposta il client è passato a TCP. I server autorevoli dovrebbero essere in grado di gestire il traffico DNS sulla porta TCP 53. Consulta la pagina RFC 7766, che richiede che le implementazioni supportino il trasporto UDP e TCP.
;; MSG SIZE rcvd: 2198- Per qualsiasi numero superiore a 1400? Questo indica ancora una grande risposta.
;; Query time: 727 msec- Per qualsiasi numero superiore a 500? Le risposte lente (soprattutto di quasi 1 secondo) potrebbero essere eliminate da Google Public DNS. Ciò è particolarmente probabile se passiamo a un tentativo di UDP seguito da un tentativo TCP. La posizione geografica del server e del client può influire notevolmente sulla latenza.
;; connection timed out; no servers could be reached- Soprattutto quando si tratta solo di alcune query, indica un problema per cui il server non è in grado di rispondere alle query DNS in modo tempestivo.
Puoi provare a applicare le seguenti varianti di query:
- Aggiunta di un parametro
+tcp. - Questa procedura impone a
digdi utilizzare immediatamente TCP, controllando se il server autoritativo gestisce le query TCP direttamente in questo modo. - Rimozione del parametro
+bufsize=1400. - Verrà ripristinato il comportamento predefinito di
dig(a 5096 pixel). Se le tue query non riescono con questa impostazione ma funzionano senza questa funzione, è possibile che il server non gestisca bene il failover TCP. Affidarsi a UDP per gestire risposte di grandi dimensioni funziona solo a volte. La soluzione migliore è supportare il trasporto TCP per DNS. - Ripetizione in ciascun server dei nomi.
- L'esempio precedente presenta due server dei nomi autorevoli (
ns1ens2). Alcuni problemi sono causati da server diversi che restituiscono risposte diverse. Controlla che tutte le persone rispondano in modo coerente ripetendo le stesse query su tutti i server autorevoli.
Se tutte le query sono piccole (1400 byte o meno), veloci (preferibilmente 500 millisecondi o più veloci) e affidabili (funzionano in modo coerente su TCP e UDP), le dimensioni della risposta non ti preoccupano; leggi le altre sezioni per la risoluzione dei problemi. Anche se le tue risposte sono rapide, le query geograficamente distanti potrebbero essere più lente.
Se uno di questi controlli non è riuscito (grande? lento? inaffidabile?), la procedura principale è A) assicurarti che il tuo server risponda con il troncamento UDP, quando la risposta supera le dimensioni del buffer UDP richieste, e B) in modo che possa gestire il nuovo tentativo di query TCP. Diversi strumenti possono aiutarti a diagnosticare problemi di affidabilità DNS:
- DNSViz
- Debugger DNSSEC
- Tester di conformità EDNS
- DNS Checker: assicurati di deselezionare la casella "CD".
Se tali strumenti rivelano errori o avvisi, assicurati di risolverli. Assicurati inoltre di leggere tutte le altre istruzioni per la risoluzione dei problemi presenti su questo sito.
Passaggio 5: controlla se gli altri resolver pubblici risolvono il dominio
Se non hai individuato alcuna causa del problema dopo aver seguito i passaggi precedenti, esegui i comandi seguenti al prompt dei comandi, sostituendo example.test. con il dominio in questione (e mantenendo i punti finali):
Windows
nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.
macOS o Linux
dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'
Questi comandi utilizzano i resolver DNS di OpenDNS, Quad9 e Cloudflare 1.1.1.1. Se ricevi errori di risoluzione da due di questi problemi e da Google Public DNS, è probabile che il problema riguardi il dominio o i suoi server dei nomi.
Se ottieni risultati da più di un altro resolver pubblico, potrebbe esserci un problema con Google Public DNS. Se non sono stati segnalati problemi simili per il dominio (o il relativo dominio di primo livello) nello strumento di monitoraggio dei problemi, ti consigliamo di segnalarci il problema, inclusi l'output del comando e il testo o gli screenshot della pagina di diagnostica nel report.