Ricerca record SOA

Host

Tipo

Resolver

Traccia iterativa

In modalità traccia iterativa, il resolver viene ignorato.

Test di propagazione

Interroga più resolver pubblici per confrontare le risposte.

Come utilizzare al meglio le opzioni del motore di lookup DNS

Cos'è la traccia iterativa?

La traccia esegue la risoluzione passo dopo passo. Il resolver interroga prima i server root, poi il TLD (.com, .fr, .eu) e infine i server autoritativi della zona di destinazione. A ogni fase la pagina mostra il server interrogato, la risposta, l'RCODE e la latenza.

1. Root
Scoperta dei server TLD per il nome richiesto.
2. TLD
Riferimento agli NS della zona (delegazione).
3. Authoritative
Risposta finale (o errore) con TTL e latenza.

A cosa serve?

Confrontare le risposte tra resolver e regioni
Individuare cache calde, TTL troppo lunghi o deleghe incomplete
Spiegare una differenza di latenza o un RCODE inatteso

Suggerimento: lascia la traccia disattivata per i controlli rapidi; attivala durante un'indagine o per preparare ticket e post-mortem.

Cos'è la traccia classica?

La traccia classica interroga solo il resolver selezionato (UDP o DoH) e mostra la risposta così come viene percepita da quel punto di rete. Ottieni l'RCODE, le sezioni di risposta e la latenza per il tratto client → resolver.

1. Resolver scelto
Utilizza il preset o la configurazione personalizzata per eseguire la query esattamente come farebbe il tuo servizio.
2. Protocollo preservato
Rispetta il trasporto selezionato (UDP, TCP o DoH) così da riprodurre il comportamento reale.
3. Risposta dettagliata
Mostra domanda, risposta e sezioni authority/additional quando presenti, insieme a TTL e metadati utili.

Perché usarla?

Verificare la vista di un resolver specifico prima di sospettare problemi di delega
Confermare valori in cache e l'impatto di TTL o flush
Documentare una risoluzione esattamente come la vede un client o un microservizio

Suggerimento: tieni disattivata la traccia iterativa quando esegui l'audit di un resolver; riattivala dopo per confrontarla con il percorso root → TLD → authoritative.

Come funziona il test di propagazione?

Il test interroga in parallelo un insieme di resolver pubblici (Google, Cloudflare, Quad9, OpenDNS, ISP…) e raggruppa le risposte per contenuto e RCODE. Vedi subito chi ha già recepito l'aggiornamento.

1. Resolver multi-punto
Abilita i preset di propagazione per interrogare diversi attori distribuiti nel mondo.
2. Confronto automatico
Raggruppa le risposte identiche e mette in evidenza divergenze o errori specifici di un resolver.
3. Riepilogo operativo
Fornisce un riepilogo chiaro, l'elenco dei resolver, le loro latenze e lo stato di ciascun gruppo.

Quando usarlo?

Monitorare la propagazione mondiale di una modifica DNS
Individuare cache obsolete e decidere un flush mirato
Condividere uno snapshot di propagazione in un ticket o post-mortem

Suggerimento: mentre il test di propagazione è attivo, il selettore del resolver resta bloccato. Disattiva la modalità per tornare alla diagnostica su singolo resolver.

Informazioni aggiuntive sui record DNS SOA

Un record SOA descrive l'autorità di una zona DNS. Indica il server autoritativo primario e l'indirizzo di contatto. Fornisce un numero di serie e valori temporali per la sincronizzazione dei server secondari.
Un record SOA contiene nome, tipo, server primario, contatto, numero di serie e cinque durate. Il TTL indica per quanto tempo la risposta resta in cache nel resolver locale.

Esempio di record DNS SOA

Nome	Tipo	Server primario MNAME	Contatto RNAME	Serial	Refresh	Retry	Expire	Minimum TTL	TTL in secondi
@	SOA	ns1.example.net.	hostmaster.example.com.	2025090301	7200	900	1209600	3600	3600

Il nome @ indica l'apice della zona. Il server primario deve risolversi in A o AAAA. Il contatto si scrive come un indirizzo e-mail sostituendo la @ con un punto: hostmaster.example.com corrisponde a hostmaster@example.com. Il serial avanza a ogni modifica della zona. I valori refresh, retry, expire e minimum TTL sono in secondi.

Ruolo dei campi in sintesi

Il server primario MNAME indica l'host di riferimento della zona.
Il contatto RNAME riceve i messaggi relativi alla zona.
Il serial permette ai secondari di sapere se esiste una versione più recente.
Refresh indica quando un secondario verifica il primario.
Retry indica l'attesa tra due tentativi dopo un errore.
Expire indica dopo quanto tempo un secondario abbandona una zona che non può aggiornare.
Minimum TTL serve al negative caching: definisce per quanto tempo una risposta negativa resta in cache. Il TTL predefinito dei record si imposta altrove nella zona.

Da sapere
Esiste un solo SOA per zona ed è pubblicato all'apice insieme agli NS. Il campo minimum TTL non definisce il TTL predefinito degli altri record ma regola la cache negativa.

TTL spiegato chiaramente

Il TTL del SOA controlla quanto tempo la risposta SOA resta in cache sul resolver. Un TTL troppo lungo può ritardare il riconoscimento di un cambio seriale. Un TTL ragionevole migliora la reattività senza sovraccaricare i server autoritativi.

Dove usare un record SOA

All'apice della zona, sempre. I sottodomini delegati hanno un proprio SOA nella loro zona dedicata. Un CNAME non deve apparire all'apice poiché la zona pubblica già SOA e NS.

Evita
Di dimenticare l'incremento del serial dopo una modifica.
Di indicare un server primario che non si risolve in A o AAAA.
Di invertire refresh e retry.
Di usare un expire troppo corto che farebbe cadere la zona sui secondari.

Verifica online

Un lookup DNS online permette di inserire un dominio. Il risultato mostra il SOA visto da Internet: server primario, contatto, serial e valori temporali. Completa con un test locale.

Verifica su Windows

Windows offre nslookup.

Resolver locale

nslookup
set q=soa
example.com

Resolver specifico

nslookup
set q=soa
server 1.1.1.1
example.com

Verifica su Linux e Mac

Su questi sistemi il comando dig è pratico.

Resolver locale

dig SOA example.com

Resolver specifico

dig SOA example.com @1.1.1.1

Lettura rapida delle risposte

Un serial più vecchio su un secondario indica un ritardo di trasferimento.
Un refresh troppo lungo ritarda la propagazione delle modifiche.
Un expire troppo breve può far abbandonare la zona a un secondario.
Un contatto mal formattato impedisce di ricevere messaggi utili.

Procedura di migrazione semplice

Prepara l'aggiornamento della zona.
Incrementa il serial.
Ricarica la zona sul server primario.
Lascia che i secondari si aggiornino o forzane il trasferimento se lo strumento lo consente.
Controlla il nuovo serial da più reti e valida.

Suggerimento pratico
Adotta un formato di serial prevedibile. Una data seguita da un contatore facilita il tracciamento, ad esempio 2025090301 per la prima modifica del giorno.

Casi comuni

Cambio provider DNS

Configura la zona sul nuovo servizio. Verifica SOA e NS. Cambia la delega quando tutto è pronto.

Aggiunta di un server secondario

Abilita il trasferimento zona sul primario. Controlla che il secondario recuperi la zona e mostri il serial corretto.

Correzione dell'indirizzo di contatto

Aggiorna RNAME e verifica che i messaggi raggiungano il destinatario.

Troubleshooting rapido

Se il SOA differisce tra server autoritativi, attendi un ciclo di refresh e ricontrolla.
Se un secondario resta fermo su un serial vecchio, verifica accesso di rete e permessi di trasferimento.
Se la zona sparisce su un secondario, aumenta expire e controlla lo stato del primario.
Se la risposta resta vecchia, attendi la scadenza del TTL e svuota la cache del resolver locale se possibile.

In sintesi, un record SOA definisce l'autorità di una zona. Indica server primario, contatto, serial e valori temporali che regolano la sincronizzazione. Solo un SOA all'apice. Valori coerenti assicurano una propagazione affidabile. La verifica passa da uno strumento online e dai comandi nslookup e dig.
Con questi riferimenti la gestione resta chiara. Le modifiche avvengono senza stress e il DNS risponde come previsto.