Propagazione e diagnostica

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

Ricerca record SVCB

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 SVCB

Un record SVCB descrive come collegarsi a un servizio. Può indicare un altro nome e fornire parametri come protocollo, indirizzi di fallback e porta. Per un sito web si pubblica spesso un record HTTPS, variante dedicata di SVCB.
Un record SVCB contiene nome, tipo, priorità, target, parametri e TTL. Il TTL indica per quanto tempo la risposta resta in cache nel resolver locale.

Esempio di record DNS SVCB

NomeTipoPrioritàTargetParametriTTL in secondi
_imap._tcp.example.comSVCB1mail.example.net.alpn=imap port=993 ipv4hint=203.0.113.103600

Il nome identifica il servizio imap su tcp. Il target è un altro hostname. I parametri indicano protocollo, porta di ingresso e un indirizzo di fallback. Un TTL di 3600 equivale a un'ora.

Esempio in modalità alias

Una priorità pari a zero attiva la modalità alias: il nome si comporta come un alias verso il target.

NomeTipoPrioritàTargetParametriTTL in secondi
apex.example.comSVCB0cdn.example.net.(nessun parametro)3600

Questa modalità permette di evitare un CNAME dove non lo si desidera.

Parametri comuni

ParametroRuolo
alpnAnnuncia i protocolli supportati (h2, h3...)
portIndica la porta di ingresso del servizio
ipv4hintFornisce indirizzi IPv4 indicativi
ipv6hintFornisce indirizzi IPv6 indicativi
echPubblica dati ECH per cifrare il ClientHello

Questi parametri guidano il client ma non sostituiscono i record A e AAAA, che restano la fonte degli indirizzi.

TTL spiegato chiaramente

Un TTL breve rende visibile più rapidamente un cambiamento, utile durante una transizione.
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 dopo la validazione.

Da sapere
Per il web è preferibile usare un record HTTPS: segue le stesse regole di SVCB e aggiunge campi utili ai browser.

Dove usare un record SVCB

Su un nome dedicato al servizio, ad esempio _imap._tcp o _smtp._tcp quando il protocollo lo prevede.
All'apice in modalità alias se serve puntare a un altro nome evitando un CNAME.
SVCB può convivere con A e AAAA. I client che non lo supportano usano gli indirizzi classici.

Evita
Di concatenare target senza motivo: vai dritto al punto.
Di pubblicare parametri che non corrispondono al servizio reale.
Di dimenticare A o AAAA sul target quando i client devono raggiungerlo.

Verifica online

Un lookup DNS online permette di inserire un nome e vedere priorità, target, parametri 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=svcb
example.com
Resolver specifico
nslookup
set q=svcb
server 1.1.1.1
example.com

Verifica su Linux e Mac

Su questi sistemi il comando dig è pratico.

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

Lettura rapida delle risposte

Una priorità a zero indica un alias. Un valore superiore descrive un servizio con parametri.
La presenza di alpn guida la scelta del protocollo. I campi ipv4hint e ipv6hint sono solo suggerimenti.
Un TTL residuo elevato può spiegare un ritardo dopo una modifica.

Configurazione semplice

  1. Definisci l'obiettivo: alias verso un target o pubblicazione di parametri.
  2. Riduci il TTL a 300 o 60 secondi prima della configurazione.
  3. Pubblica il record SVCB con priorità e parametri scelti.
  4. Verifica con nslookup o dig da più reti.
  5. Alza il TTL quando tutto è stabile.

Suggerimento pratico
Documenta priorità, target e parametri. Segna data e motivo. Questa traccia facilita le verifiche.

Casi comuni

Servizio applicativo

Pubblica un SVCB su _api._tcp per annunciare alpn e porta. L'applicazione saprà connettersi.

Sito dietro un provider

Usa la modalità alias per puntare al nome fornito dal servizio. Mantieni record A e AAAA sul target.

Transizione a HTTP/3

Su un sito pubblica un record HTTPS dedicato con alpn h3 e, se disponibile, il parametro ech.

Troubleshooting rapido

  1. Se i client ignorano SVCB, verifica la presenza di A e AAAA sul target.
  2. Se viene scelto il protocollo sbagliato, controlla il parametro alpn.
  3. Se compare un loop, verifica che il target non rimandi al nome originale.
  4. Se la risposta resta vecchia, attendi la scadenza del TTL e svuota la cache del resolver locale se possibile.

In sintesi, un record SVCB descrive un servizio e può fungere da alias controllato. I parametri guidano il client senza sostituire i record A e AAAA. Un TTL ben calibrato facilita le transizioni. 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 gli utenti raggiungono il servizio senza problemi.