Propagazione e diagnostica

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

Ricerca record PTR

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 PTR

Un record PTR associa un indirizzo IP a un hostname. È la risoluzione inversa. I sistemi lo usano per log, controlli di rete e messaggistica. Per raggiungere un indirizzo usiamo A o AAAA; per risalire a un nome utilizziamo PTR.
Un record PTR contiene nome, tipo, target e TTL. Il TTL indica per quanto tempo la risposta resta in cache nel resolver locale.

Esempio di record DNS PTR per IPv4

NomeTipoTargetTTL in secondi
10.113.0.203.in-addr.arpa.PTRmail.example.net.3600

Il nome corrisponde all'indirizzo 203.0.113.10 scritto al contrario nella zona in-addr.arpa. Il target è l'hostname atteso. Un TTL di 3600 equivale a un'ora.

Esempio di record DNS PTR per IPv6

NomeTipoTargetTTL in secondi
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.PTRhost.example.net.3600

Il nome utilizza ogni cifra esadecimale di 2001:db8::10 al contrario nella zona ip6.arpa. Il target è l'hostname atteso.

Coerenza tra forward e reverse

Una configurazione corretta allinea PTR con A o AAAA. Il nome restituito dal PTR deve risolversi nello stesso indirizzo. Questa coerenza aiuta messaggistica e diagnostica.

TTL spiegato chiaramente

Un TTL breve rende visibile rapidamente una modifica, utile durante un cambio di indirizzo.
Un TTL medio o lungo riduce le query ai server autoritativi, ideale per una configurazione stabile.
Riduci il TTL qualche ora prima della modifica e rialzalo dopo la validazione.

Da sapere
Un indirizzo può pubblicare un solo PTR utile. Moltiplicarli crea ambiguità. Meglio un nome chiaro che poi si risolve in A o AAAA.

Dove usare un record PTR

Nella zona reverse fornita dal titolare dell'indirizzo. Per IPv4 sotto in-addr.arpa, per IPv6 sotto ip6.arpa. Nei blocchi assegnati da un operatore la gestione del PTR avviene spesso dal loro pannello.

Evita
Di puntare un PTR a un nome privo di record A o AAAA.
Di mantenere un target obsoleto dopo un cambio indirizzo.
Di pubblicare un nome generico che non riflette il servizio.

Verifica online

Un lookup DNS online permette di inserire un indirizzo. Il risultato mostra il nome restituito dal PTR e 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=ptr
10.113.0.203.in-addr.arpa

Oppure semplicemente

nslookup 203.0.113.10
Resolver specifico
nslookup
set q=ptr
server 1.1.1.1
10.113.0.203.in-addr.arpa

Verifica su Linux e Mac

Su questi sistemi il comando dig è pratico.

Resolver locale
dig PTR 10.113.0.203.in-addr.arpa
Resolver specifico
dig PTR 10.113.0.203.in-addr.arpa @1.1.1.1

Per IPv6 si interroga la forma ip6.arpa dello stesso nome.

Lettura rapida delle risposte

Una risposta NXDOMAIN indica assenza di PTR: aggiungi la voce nella zona reverse.
Un nome restituito che non si risolve in A o AAAA segnala un'incoerenza: correggi la zona forward.
Un TTL elevato può spiegare un ritardo dopo una modifica.

Procedura di configurazione semplice

  1. Verifica il controllo della zona reverse con ISP o provider cloud.
  2. Scegli un hostname chiaro che si risolve in A o AAAA verso l'indirizzo.
  3. Crea il PTR con TTL ridotto.
  4. Testa con nslookup o dig da più reti.
  5. Rialza il TTL quando tutto è stabile.

Suggerimento pratico
In ambito e-mail allinea record PTR, nome usato dal server SMTP e relativo record A o AAAA. Questa coerenza migliora la deliverability.

Casi comuni

Server di posta

Richiede un PTR che restituisca un nome dedicato. Il nome deve risolversi nell'indirizzo del server.

Range presso un operatore

Richiedi la delega della zona reverse o usa l'interfaccia fornita per gestire i PTR.

Macchine cloud effimere

Automatizza creazione e cancellazione dei PTR all'avvio e allo spegnimento delle istanze.

Troubleshooting rapido

  1. Se un servizio rifiuta la connessione, verifica presenza del PTR e coerenza con A o AAAA.
  2. Se la risposta resta vecchia, attendi la scadenza del TTL e svuota la cache del resolver locale se possibile.
  3. Se il provider gestisce la zona reverse, apri un ticket indicando indirizzo e nome desiderato.

In sintesi, un record PTR fornisce il nome associato a un indirizzo. Completa i record A e AAAA. Un TTL adeguato e la coerenza tra forward e reverse semplificano i controlli. 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 i servizi si identificano correttamente nella risoluzione inversa.