Propagazione e diagnostica

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

Ricerca record MX

In modalità traccia iterativa, il resolver viene ignorato.
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. 1. Root

    Scoperta dei server TLD per il nome richiesto.

  2. 2. TLD

    Riferimento agli NS della zona (delegazione).

  3. 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. 1. Resolver scelto

    Utilizza il preset o la configurazione personalizzata per eseguire la query esattamente come farebbe il tuo servizio.

  2. 2. Protocollo preservato

    Rispetta il trasporto selezionato (UDP, TCP o DoH) così da riprodurre il comportamento reale.

  3. 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. 1. Resolver multi-punto

    Abilita i preset di propagazione per interrogare diversi attori distribuiti nel mondo.

  2. 2. Confronto automatico

    Raggruppa le risposte identiche e mette in evidenza divergenze o errori specifici di un resolver.

  3. 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 MX

Un record MX indica quali server ricevono la posta per un dominio. Punta a un hostname. Il resolver segue questo nome per trovare record A o AAAA e il server mittente può consegnare i messaggi.
Un record MX contiene nome, tipo, priorità, target e TTL. Il TTL indica per quanto tempo la risposta resta in cache nel resolver locale.

Esempio di record DNS MX

NomeTipoPrioritàTargetTTL in secondi
@MX10mail.example.net.3600

In questo esempio il nome @ indica l'apice del dominio. Il target è un hostname che deve pubblicare A o AAAA. La priorità più bassa è preferita. Un TTL di 3600 equivale a un'ora.

Esempio con più priorità

È comune pubblicare più record MX per lo stesso nome. Il server mittente sceglie prima la priorità più bassa e, in caso di errore, prova la successiva.

NomeTipoPrioritàTargetTTL in secondi
@MX10mx1.example.net.3600
@MX20mx2.example.net.3600

Questa ridondanza aumenta la continuità del servizio ma non sostituisce il monitoraggio attivo né i test regolari.

Regole essenziali

Un record MX punta a un nome, non a un indirizzo. Il target non deve essere un CNAME. Il nome puntato deve pubblicare A o AAAA ed essere raggiungibile sulla porta 25. L'MX può esistere sull'apice o su un sottodominio se l'indirizzo e-mail utilizza quel sottodominio.

TTL spiegato chiaramente

Un TTL breve rende più rapido un cambiamento, utile quando passi a un nuovo servizio di posta.
Un TTL medio o lungo riduce le query ai server autoritativi, adatto a un servizio stabile.
Riduci il TTL qualche ora prima dello switch e rialzalo quando tutto è validato.

Da sapere
I record MX servono per la ricezione. L'invio usa altre impostazioni come SPF, DKIM, DMARC e la configurazione del relay in uscita.

Dove usare un record MX

Pubblica l'MX sul dominio che riceve la posta, di solito l'apice. Per un dominio dedicato (es. support.example.com) pubblica l'MX su quel sottodominio. Gli host referenziati dagli MX mantengono i propri record A o AAAA.

Evita
Di puntare un MX verso un CNAME o un indirizzo diretto.
Di dimenticare i record A o AAAA del target.
Di lasciare un vecchio MX attivo dopo una migrazione.

Verifica online

Un lookup DNS online permette di inserire un dominio e ottenere l'elenco degli MX con priorità, target e TTL visibili da Internet. È un primo controllo utile. Completa con un test locale.

Verifica su Windows

Windows offre nslookup.

Resolver locale
nslookup
set q=mx
example.com
Resolver specifico
nslookup
set q=mx
server 1.1.1.1
example.com

La prima parte usa la configurazione della macchina. La seconda forza un resolver terzo (Cloudflare).

Verifica su Linux e Mac

Su questi sistemi il comando dig è pratico.

Resolver locale
dig MX example.com
Resolver specifico
dig MX example.com @1.1.1.1

Lettura rapida delle risposte

Più righe indicano più server. Il numero di priorità più basso è preferito. Priorità identiche condividono i tentativi in modo equilibrato.
Un TTL residuo elevato può spiegare un ritardo dopo una modifica.
Un target senza A o AAAA impedisce la consegna.

Procedura di migrazione semplice

  1. Prepara gli host di posta con i loro record A o AAAA.
  2. Riduci il TTL degli MX a 300 o 60 secondi qualche ora prima dello switch.
  3. Aggiungi i nuovi MX con la priorità pianificata mantenendo i vecchi durante la transizione.
  4. Testa la ricezione da più reti e controlla le intestazioni dei messaggi.
  5. Rimuovi i vecchi MX e rialza il TTL quando tutto è stabile.

Suggerimento pratico
Annota l'elenco completo degli MX prima delle modifiche. Conserva data, priorità, TTL e motivo. Questa traccia evita errori e facilita un rollback.

Casi comuni

Servizio di posta esterno

Pubblica gli MX forniti dal provider. I target appartengono al dominio del provider. Mantieni un TTL ragionevole.

Filtro anti-spam a monte

Punta l'MX al provider di filtraggio che inoltra poi verso i tuoi server. Monitora latenza e disponibilità.

MX di backup

Dichiara un server secondario con priorità più alta. Conserva i messaggi se il primario è indisponibile e li consegna al suo ritorno.

Troubleshooting rapido

  1. In caso di bounce verifica che il target dell'MX si risolva in A o AAAA.
  2. Controlla la raggiungibilità di rete sulla porta 25 del target.
  3. Se l'MX punta ancora al vecchio provider, rimuovilo dopo lo switch.
  4. Se la risposta resta vecchia, attendi la scadenza del TTL e svuota la cache del resolver locale se possibile.

In sintesi, un record MX indica il server che riceve la posta per un dominio. Punta a un hostname che pubblica A o AAAA. La priorità più bassa viene scelta per prima. Un TTL ben calibrato facilita le modifiche. La verifica passa da uno strumento online e dai comandi nslookup e dig.
Seguendo queste indicazioni la gestione resta chiara. Le modifiche avvengono senza stress e i messaggi arrivano senza problemi.