# Verifica propagazione DNS: quanto manca alla modifica URL: https://notificationharbor.com/it/tools/verifica-propagazione-dns Type: tool Locale: it Published: 2026-10-07 Updated: 2026-10-08 --- > Stima l'attesa nel caso peggiore dopo una modifica DNS partendo dal TTL e dal tempo trascorso dalla modifica. Funziona nel browser e copre record, nuove chiavi DKIM e cambi di nameserver. ## 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. ## 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. *[Interactive widget — see the live page for the full experience]* ## 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. ## Quattro passaggi che accorciano l'attesa 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. **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. **Fai la modifica e annota l'ora** — Salva la modifica, annota l'ora e inserisci il tempo trascorso nel calcolatore qui sopra. 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. *Call to action: Scopri come funziona Notification Harbor* ## FAQ ### 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.