Propagazione e diagnostica

Confronta i resolver in tutto il mondo e ispeziona le risposte restituite.

Verificare la salute DNS di un dominio

Perché eseguire un audit completo?

Un dominio ben configurato risponde velocemente e in modo prevedibile. Quando la delega al parent è esatta, ogni server è raggiungibile in IPv4 e IPv6, il SOA è sincronizzato e le impostazioni di base sono pulite, i guasti scompaiono quasi sempre. Questo audit verifica tutto ciò risalendo la catena reale di risoluzione. Confronta prima la vista del parent con la vista della tua zona, poi interroga ogni server per vedere se risponde in modo autoritativo, accetta UDP e TCP, e se le sue risposte sono coerenti con quelle dei suoi peer. Ottieni una lettura fedele dello stato del dominio nel momento in cui avvii il controllo.

Come funziona l'audit?

Il controllo inizia dal lato del parent. Legge la lista dei NS pubblicata nel registro, così come gli indirizzi incollati al parent quando sono necessari. Questi indirizzi di assistenza si chiamano glue. Servono solo se il nome del server appartiene al dominio che stai verificando. L'audit recupera poi la lista dei NS dalla zona stessa e confronta entrambe le viste. Se c'è una discrepanza, la risoluzione diventa casuale. Un resolver può seguire il percorso del parent, un altro seguire la zona. La diagnosi segnala quindi una discrepanza parent-zona e ti dice cosa correggere.

Una volta validata la delega, lo strumento interroga ogni server. Testa la risoluzione in IPv4 e IPv6 quando possibile. Misura la latenza e verifica che il server risponda in modo autoritativo per il dominio. Verifica anche che la ricorsione sia disabilitata su un server autoritativo e che i trasferimenti di zona non siano aperti a chiunque. Se una risposta è troncata in UDP, verifica che TCP prenda il sopravvento. Questi punti evitano errori sottili che si vedono solo sotto carico o con una risposta voluminosa.

Delega, glue e lame delegation

La delega al parent deve puntare a server che sanno rispondere in modo autoritativo per la tua zona. Quando il parent punta a un host che non è autoritativo, si parla di lame delegation. I resolver perdono tempo, a volte si arrendono, e vedi SERVFAIL. L'audit individua questo caso e indica chiaramente quale server causa il problema. Verifica anche la freschezza dei glue. Un glue obsoleto si verifica quando l'indirizzo di un NS è cambiato ma il record del parent non è stato aggiornato. Risultato semplice: alcuni resolver hanno l'indirizzo corretto tramite la zona, altri continuano a provare il vecchio indirizzo tramite il parent. Il report ti guida per aggiornare i glue presso il registrar.

Accessibilità di rete e trasporto

Un server autoritativo deve rispondere in UDP. Deve anche accettare TCP quando una risposta supera la dimensione prevista. Firewall troppo rigidi rompono questo ripiego. L'audit prova entrambe le modalità e ti dice se TCP è bloccato. Verifica la presenza di IPv4. Segnala l'assenza di IPv6 come un possibile miglioramento piuttosto che un errore bloccante. Infine, ricorda che un server autoritativo non deve fare ricorsione e che un trasferimento di zona non deve essere aperto al pubblico. Questi punti riguardano la sicurezza e la stabilità.

Coerenza delle risposte e SOA

Tutti i server della stessa zona devono pubblicare lo stesso set NS, lo stesso serial SOA e gli stessi dati all'istante T. Quando un server non ha ricevuto l'ultima versione, vedi risposte diverse a seconda del server interrogato. La diagnosi legge il SOA su ogni host e verifica che il serial avanzi in modo monotono. Esamina anche le temporizzazioni del SOA. Un refresh ragionevole permette ai secondari di seguire il primario. Un retry breve accelera il recupero dopo un guasto. Un expire sufficiente evita che un secondario abbandoni la zona troppo rapidamente. Il TTL minimo serve per il caching negativo e deve rimanere misurato. Il report commenta questi valori in modo pratico, senza dogmi, per adattarsi al tuo ritmo di cambiamento.

IPv4 e IPv6

La presenza di IPv6 non è obbligatoria ma sta diventando uno standard. Attivare IPv6 sui tuoi NS elimina una fonte di errori dal lato dei visitatori e dei bot che privilegiano questo stack quando esiste. L'audit testa entrambi gli stack quando sono pubblicati. Segnala l'assenza di AAAA come un'opportunità di miglioramento e non come un guasto.

DNSSEC se lo usi

Se il tuo dominio è firmato, l'audit verifica che il parent pubblichi un DS che corrisponde alle chiavi della zona. Legge i DNSKEY e controlla se le firme sono valide all'apex. Una discrepanza tra DS e chiavi rompe la catena di fiducia. Il report spiega cosa aggiornare per primo e ricorda l'ordine delle operazioni durante un cambio di chiave.

Leggere il risultato e agire

La parte superiore del report riassume lo stato generale. I punti classificati come errori bloccano o degradano francamente la risoluzione. Correggi le discrepanze parent-zona, i glue mancanti, un TCP chiuso, una lame delegation o un serial divergente con priorità. I punti classificati come avvertimenti migliorano la qualità senza essere bloccanti. Un IPv6 assente, una dispersione di NS debole, temporizzazioni SOA poco realistiche rientrano in questa categoria. Ogni punto è accompagnato da una frase di azione concreta. Sai cosa fare e dove farlo, nella zona o presso il registrar.

Scenari concreti

Prima di cambiare provider DNS, avvia l'audit poi riduci i TTL dei record critici. Aggiungi i nuovi NS, aggiorna la delega presso il registro, dichiara i glue se i tuoi NS sono nel tuo dominio, attendi la fine delle cache, poi rilancia l'audit. Validi che il parent e la zona raccontano la stessa storia e che tutti i server rispondono in modo autoritativo con lo stesso SOA.

Dopo un cambio di indirizzo su un NS, verifica immediatamente il glue al parent. Finché il vecchio indirizzo rimane pubblicato, parte del traffico continua ad andare nel posto sbagliato. L'audit ti mette questo punto davanti con l'indirizzo esatto da correggere.

Se gli utenti vedono errori casuali, consulta la sezione coerenza. Un serial congelato o un NS che non ha ricevuto l'ultima zona spiega spesso un comportamento intermittente. Il controllo ti mostra quale server è in ritardo e ti dà l'ordine di rimessa in linea.

Buone pratiche semplici

  • Mantieni almeno due NS su reti distinte.
  • Aggiorna la delega e i glue a ogni cambiamento.
  • Lascia TCP aperto sugli autoritativi.
  • Disabilita la ricorsione e blocca i trasferimenti di zona.
  • Scegli temporizzazioni SOA adatte alla tua cadenza di aggiornamento.
  • Attiva IPv6 quando puoi.
  • Documenta ogni modifica con data e motivo.

Sono gesti brevi che evitano incidenti lunghi.

Cosa guadagni

Un dominio che supera l'audit si risolve ovunque allo stesso modo. I cambiamenti si propagano secondo il TTL scelto e non a caso. Riduci i ticket legati a una "propagazione" interminabile che in realtà è solo una cache mal anticipata. Rilevi anche debolezze che non si vedono durante un semplice lookup, come una lame delegation o un TCP chiuso. Il risultato è un piano d'azione chiaro. Correggi, verifichi, volti pagina.

Riservatezza e perimetro

Il controllo interroga solo informazioni pubbliche. Contatta la tua zona e il parent come farebbe un resolver. Non sono richiesti dati privati. Lo strumento non memorizza la tua configurazione. Solo metriche tecniche anonime vengono conservate per monitorare la disponibilità del servizio.

Con questo audit, parti dai fatti. Parent e zona sono allineati o non lo sono. I server rispondono in modo autoritativo o non lo fanno. Il SOA è sincronizzato o rimane indietro. Guadagni una visione chiara del tuo dominio e un percorso semplice per correggere ciò che deve essere corretto.