Propagazione e diagnostica

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

Ricerca record TXT

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 TXT

Un record TXT pubblica testo associato a un nome di dominio. I servizi lo usano per dimostrare la proprietà del dominio, configurare impostazioni e-mail come SPF, DKIM, DMARC o esporre informazioni tecniche.
Un record TXT contiene nome, tipo, valore e TTL. Il TTL indica per quanto tempo la risposta resta in cache nel resolver locale.

Esempio di record DNS TXT

NomeTipoValoreTTL in secondi
@TXT"v=spf1 ip4:203.0.113.0/24 ~all"3600

Il nome @ indica l'apice del dominio. Il valore contiene una regola SPF in formato testo. Un TTL di 3600 equivale a un'ora.

Esempi comuni

NomeTipoValoreTTL in secondi
selector1._domainkeyTXT"v=DKIM1; k=rsa; p=MII...AB"3600
_dmarcTXT"v=DMARC1; p=quarantine; adkim=s; aspf=s"3600
@TXT"property=token12345"300

Queste righe mostrano un selettore DKIM, una policy DMARC e un token di verifica. Il nome mirato dipende dal servizio.

Più record TXT sullo stesso nome

È possibile pubblicare più record TXT sullo stesso label. Ogni valore appare nella risposta. Per SPF mantieni una sola voce per nome e raggruppa i meccanismi. Per DKIM usa un selettore diverso per ogni chiave.

TTL spiegato semplicemente

Un TTL breve rende una modifica visibile più rapidamente, utile durante un aggiornamento SPF o una verifica di dominio.
Un TTL medio o lungo riduce le query ai server autoritativi, adatto a una configurazione stabile.
Riduci il TTL qualche ora prima della modifica, poi rialzalo dopo la convalida.

Da sapere
Un valore TXT può superare i 255 byte. In tal caso viene suddiviso in più stringhe quotate nella zona. I resolver ricompongono le stringhe sul client.

Dove usare un record TXT

Pubblica il TXT sul nome richiesto dal servizio. SPF sta spesso all'apice. DKIM su selector._domainkey. DMARC su _dmarc. I servizi di verifica forniscono un nome specifico. Un TXT può convivere con A, AAAA, MX sullo stesso nome.

Evita
Due voci SPF sullo stesso nome: uniscile in un unico valore.
Di dimenticare le virgolette o gestire male i caratteri speciali.
Di pubblicare DKIM sul selettore sbagliato.

Verifica online

Un lookup DNS online permette di inserire un nome a dominio e ottenere l'elenco dei valori TXT con il TTL visibile da Internet. È un primo controllo utile. Completa con un test locale.

Verifica su Windows

Windows offre nslookup.

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

Verifica su Linux e Mac

Su questi sistemi il comando dig è pratico.

Resolver locale
dig TXT www.example.com
Resolver specifico
dig TXT www.example.com @1.1.1.1

Lettura rapida delle risposte

Più righe indicano più valori TXT. I prefissi v=spf1 v=DKIM1 v=DMARC1 aiutano a identificare la funzione di ogni voce.
Un TTL residuo elevato può spiegare un ritardo dopo un cambiamento.
Un valore vuoto o troncato segnala spesso virgolette mancanti o una suddivisione gestita male.

Procedura di migrazione semplice

  1. Annota valori e TTL attuali.
  2. Riduci il TTL a 300 o 60 secondi qualche ora prima della modifica.
  3. Prepara il nuovo valore. Per SPF unisci i meccanismi in un'unica linea.
  4. Pubblica il nuovo valore e rimuovi il vecchio se necessario.
  5. Verifica con nslookup o dig da più reti e rialza il TTL quando tutto è stabile.

Suggerimento pratico
Per DKIM pubblica una nuova chiave su un nuovo selettore. Lascia la vecchia durante il periodo di transizione e rimuovila quando tutto è validato.

Casi comuni

SPF per la ricezione corretta

Pubblica una regola SPF all'apice con indirizzi e domini autorizzati. Testa prima della produzione.

DKIM per la firma

Pubblica la chiave pubblica sul selettore fornito dal servizio e-mail. Verifica che la chiave sia completa.

DMARC per la policy di dominio

Pubblica la policy su _dmarc con la direttiva p e le opzioni utili. Monitora i report se attivi.

Verifica di proprietà

Pubblica un token TXT temporaneo fornito da un servizio. Rimuovilo dopo la verifica se possibile.

Troubleshooting rapido

  1. Se SPF risulta invalido, verifica che esista una sola voce SPF sullo stesso nome.
  2. Se DKIM fallisce, controlla selettore e chiave e cerca interruzioni o spazi extra.
  3. Se DMARC non è rilevato, controlla il nome _dmarc e il valore v=DMARC1.
  4. Se la risposta resta vecchia, attendi la scadenza del TTL e svuota la cache del resolver locale se possibile.

In sintesi, un record TXT pubblica informazioni testuali per un nome di dominio. Serve a verifiche, policy e-mail e altri usi tecnici. Il TTL controlla la durata della cache. Più record TXT possono convivere sullo stesso nome, ma solo uno deve contenere SPF. La verifica passa da uno strumento online e dai comandi nslookup e dig.
Con queste linee guida la gestione resta chiara. Le modifiche avvengono senza stress e i servizi funzionano come previsto.