DNS checker: come controllare bene i record DNS

Un DNS checker è un modo comodo per ispezionare i record che un resolver riesce a recuperare in questo momento per un dominio. Lo si usa dopo aver cambiato host per un sito web, configurato la posta, spostato il DNS su un altro provider o indagato su un nome che non si risolve. Il risultato è un'istantanea, non la garanzia che ogni resolver ricorsivo si sia aggiornato o che il servizio sottostante sia disponibile. Perché il controllo sia utile, scegli l'hostname esatto, seleziona il tipo di record che corrisponde al sintomo e interpreta una risposta vuota in modo diverso da un errore DNS. Questi tre passaggi evitano molti falsi allarmi e ti aiutano a capire quale livello della configurazione merita attenzione.

Scegli il record che risponde alla tua domanda

Per l'indirizzo IPv4 di un sito web ispeziona A; per l'IPv6, AAAA. Un sottodominio può usare un CNAME che punta all'hostname di un provider di hosting invece di contenere direttamente un indirizzo. La consegna della posta dipende prima di tutto dai record MX, mentre i record TXT spesso pubblicano SPF, DKIM, DMARC e i dati di verifica della proprietà. I record NS mostrano quali nameserver sono elencati per una zona e SOA fornisce i campi amministrativi e di temporizzazione associati a quella zona. Controllare solo i record A, quindi, non basta quando il problema riguarda la consegna della posta, un sottodominio delegato o un passaggio di verifica. Parti dal servizio interessato e associa il sintomo ai suoi tipi di record.

Poi verifica con precisione il nome interrogato. example.com, www.example.com e api.example.com sono nomi DNS distinti e possono restituire risposte completamente diverse. Il punto finale nella notazione DNS completa rappresenta la radice e di solito è facoltativo nelle interfacce utente. Non incollare un URL intero con tanto di percorso dando per scontato che il checker capisca quale hostname conta: estrai prima l'hostname. Se stai convalidando un nuovo record, confronta il valore restituito carattere per carattere con le istruzioni del provider. Le policy TXT contengono spesso punteggiatura, separatori o stringhe lunghe in cui un errore di battitura apparentemente minimo può invalidare il record.

Capisci da dove arrivano risposte diverse

Il DNS è distribuito e usa le cache. Un nameserver autorevole conserva i dati pubblicati della zona, mentre i resolver ricorsivi rispondono agli utenti e possono mettere in cache le risposte precedenti finché il relativo TTL non scade. Due checker possono quindi mostrare per un po' valori diversi se interrogano resolver, località o versioni del record differenti. Un checker che interroga un insieme di località può aiutare a mostrare la variazione, ma non dimostra che ogni rete si sia allineata. Se un risultato non corrisponde alla configurazione prevista, individua quale resolver ha risposto e confrontalo con i nameserver autorevoli. Poi considera il TTL e il momento in cui è stato messo in cache il valore precedente, prima di fare un'altra modifica.

• NOERROR senza il record richiesto può significare che il nome esiste ma non ha dati di quel tipo.
• NXDOMAIN significa che il nome interrogato è stato segnalato come inesistente.
• SERVFAIL indica che un resolver non è riuscito a completare la query.
• Un timeout significa che non è arrivata nessuna risposta entro il tempo di attesa del checker.
• Più risposte A o AAAA possono essere intenzionali, per ridondanza o per distribuire il traffico.

Trasforma un controllo DNS in un passaggio sicuro di troubleshooting

Quando modifichi il DNS, tieni un resoconto del prima e del dopo. Annota nome, tipo, valore, TTL, resolver e orario, poi ripeti la stessa query dopo l'aggiornamento. Se il server autorevole restituisce il nuovo valore ma un resolver ricorsivo restituisce ancora il vecchio, può essere opportuno aspettare che le cache scadano; cambiare il record ripetutamente può rendere la situazione più difficile da diagnosticare. Se i server autorevoli non concordano, indaga sulla replica della zona o sulla configurazione del provider. Se tutte le risposte DNS sembrano corrette ma il sito continua a non funzionare, passa a connettività, TLS, routing o stato di salute dell'applicazione, invece di continuare a modificare il DNS alla cieca.

Infine, tratta la risposta in base al suo ambito. I controlli DNS pubblici sono adatti a domini e record pensati per essere visibili su Internet; non servono a esaminare il namespace interno di un'organizzazione. Un IP restituito dal DNS può essere un edge di una CDN, un load balancer o un reverse proxy e non la macchina che ospita l'applicazione. Se ti servono solo le risposte con gli indirizzi pubblici, il lookup da dominio a IP è il passo successivo più mirato. Per la terminologia e gli esempi di A, AAAA, MX, TXT e NS, vedi i tipi di record DNS spiegati.

Leggi il report di un checker con sano scetticismo

Un DNS checker può mostrare un indicatore verde quando riceve una qualsiasi risposta, anche se il valore restituito non è quello richiesto dal tuo servizio. Leggi il nome, il tipo e i dati grezzi invece di affidarti solo a un badge riepilogativo. Anche la risposta di una singola località è un campione, non la garanzia di un accordo globale. Se lo strumento elenca molte località, ricorda che ciascuna può rappresentare un particolare resolver e il suo stato della cache, non tutti gli utenti di quella regione. Usa il report per scegliere il passo diagnostico successivo: confrontare con i dati autorevoli, ispezionare il TTL o testare il servizio. Evita di copiare un IP nella configurazione di produzione senza aver confermato che sia l'endpoint supportato dal provider. Un buon troubleshooting si basa su un valore atteso e su una ragione per cui lo si aspetta, non solo sul fatto che un checker definisca il risultato «valido».