Riassunto

Questo verificatore di propagazione DNS stima per quanto tempo una modifica DNS può restare invisibile ad alcuni resolver. La propagazione è la scadenza della cache: un resolver conserva la vecchia risposta fino al termine del suo TTL, quindi il caso peggiore coincide con il vecchio TTL. I nuovi record possono restare in cache come assenti per il TTL negativo del SOA, e il cambio di nameserver segue il TTL NS del registro. Inserisci il tipo di modifica, il TTL e il tempo trascorso per vedere l'attesa residua. Funziona nel browser e non interroga il DNS in tempo reale.

Verifica propagazione DNS: quanto manca perché la modifica sia attiva

Inserisci il TTL e il tempo trascorso dalla modifica. Questo verificatore di propagazione DNS mostra l'attesa nel caso peggiore per la modifica di un record, una nuova chiave DKIM o un cambio di nameserver.

Calcola la finestra di attesa

Verificatore di propagazione DNS

Scegli il tipo di modifica, inserisci il TTL corrispondente e il tempo trascorso da quando hai salvato. Il risultato si aggiorna mentre digiti e nulla lascia il browser.

Il TTL che il record aveva prima della modifica, non quello nuovo.

Come funziona

Cosa misura davvero il calcolatore

La propagazione è la scadenza della cache

Il DNS non invia le modifiche a nessuno. Ogni resolver conserva la risposta ricevuta finché il TTL non scade, poi la richiede di nuovo. Il resolver più lento è quello che ha ricevuto la vecchia risposta poco prima della tua modifica, quindi il caso peggiore coincide con il vecchio TTL.

I nuovi record hanno un loro orologio

Un record che non esisteva può essere comunque in cache come assente. Questa risposta negativa dura per il valore più piccolo tra il TTL del SOA e il suo campo minimum. Se nessuno ha cercato il nome in anticipo, il nuovo record è visibile subito.

I cambi di nameserver seguono il registro

Cambiare nameserver modifica i record NS nella zona padre, e quel TTL non lo imposti tu. Il calcolatore lo prende come dato in ingresso, con due giorni come valore tipico per i TLD grandi come .com.

Prima di una modifica DNS per l'email

Quattro passaggi che accorciano l'attesa

È l'ordine che seguiamo per le modifiche a SPF, DKIM, DMARC e MX su un dominio di invio.

  1. 1

    Leggi il TTL attuale

    Esegui dig sul record e leggi il numero nella sezione answer. È il TTL che la tua modifica dovrà superare.

  2. 2

    Abbassalo in anticipo

    Imposta il TTL a 300 secondi, poi aspetta almeno quanto il vecchio TTL prima di modificare il record. I resolver devono far scadere per primi la copia a lunga durata.

  3. 3

    Fai la modifica e annota l'ora

    Salva la modifica, annota l'ora e inserisci il tempo trascorso nel calcolatore qui sopra.

  4. 4

    Verifica alla fonte, poi su un resolver

    Interroga prima il tuo nameserver autoritativo, poi un resolver pubblico. Rialza il TTL quando entrambi concordano e la finestra è passata.

Domande frequenti

Questo verificatore di propagazione DNS è gratuito?
Sì. Nessuna registrazione, nessun limite di richieste. Il calcolo è aritmetica su tre numeri che digiti, quindi viene eseguito nel browser e nulla viene inviato ai nostri server.
Interroga i server DNS in tempo reale?
No. Non cerca il tuo record presso resolver di tutto il mondo. Calcola il tempo massimo per cui una risposta in cache può sopravvivere, a partire dal TTL che inserisci. Per vedere cosa restituisce un resolver specifico in questo momento, esegui dig su quel resolver e confrontalo con la finestra mostrata qui.
Perché la stima usa il vecchio TTL e non quello nuovo?
I resolver conservano la risposta ricevuta prima della tua modifica, insieme al TTL che l'accompagnava. Abbassare il TTL nella stessa modifica non cambia nulla per i resolver che hanno già la vecchia risposta. Il nuovo TTL si applica solo alle risposte recuperate dopo la modifica.
Che cos'è il TTL della cache negativa e quando si applica?
Quando un resolver chiede un nome che non ha record, può mettere in cache la risposta "non esiste" (RFC 2308). Dura per il valore più piccolo tra il TTL del record SOA e il suo campo minimum. Riguarda solo i resolver che hanno interrogato il nome prima che tu creassi il record, ad esempio un selettore DKIM testato troppo presto.
Perché un cambio di nameserver richiede tanto tempo?
I record NS che puntano ai tuoi nameserver risiedono presso il registro, con un TTL che non controlli. Per i TLD grandi come .com quel TTL è in genere di due giorni. Finché non scade, alcuni resolver continuano a interrogare i vecchi nameserver.
Sono oltre la finestra e vedo ancora il vecchio valore. Cosa faccio?
Smetti di dare la colpa alla cache. Interroga direttamente il tuo nameserver autoritativo e verifica che serva il nuovo valore. Se non lo fa, la modifica è finita nella zona sbagliata, sull'host sbagliato, oppure non è mai stata salvata. Se invece lo fa, prova da un resolver che non hai mai usato e controlla che non ci sia una cache locale sulla tua macchina o sulla tua rete.
Vale anche per i record SPF, DKIM e DMARC?
Sì. Sono record TXT e vengono messi in cache come gli altri. Un server di ricezione che ha in cache il vecchio record SPF continua a valutarlo finché il TTL non scade, quindi un invio subito dopo una modifica può essere giudicato con la vecchia policy.

Tieni sotto controllo l'infrastruttura dei tuoi invii

Questo strumento stima un'attesa. Notification Harbor copre gli invii che controlli tu: warmup del dominio, observability per singolo invio, e SPF, DKIM e DMARC configurati correttamente prima del primo invio in produzione.

Scopri come funziona Notification Harbor
notificationharbor
Inizia gratis