◈ netchecks.org

17 controlli · senza account · self-hosted

Testa la tua rete con un clic

17 strumenti gratuiti di diagnostica di rete in un'unica dashboard.

FAQ

0 tracker · 14 lingue · modalità chiara e scura · self-hosted

← Tutti gli articoli

Network guides

DNS Propagation Explained: Why Your DNS Change Takes Time

When you change a DNS record, you expect it to take effect immediately. In practice it often does not, and the delay is not a bug - it is the system working as designed. DNS is built on caching, so every resolver that has already looked up your domain keeps the old answer until it decides to check again.

In this guide we look at why propagation takes time, what the TTL value controls, how recursive resolvers store answers, and how you can verify a change from several independent points. Understanding this turns a confusing wait into a predictable process.

  1. 1983

    DNS is specified

    RFC 882 and RFC 883 define the Domain Name System, introducing a hierarchical and distributed name service for the internet.

  2. 1987

    Caching and TTL are formalized

    RFC 1034 introduces the Time To Live concept, telling resolvers how long they may keep an answer before checking the authoritative server again.

  3. 1990s

    Recursive resolvers spread

    ISPs and organizations deploy recursive resolvers that cache answers for their users, dramatically speeding up lookups but adding propagation delay.

  4. Today

    Public resolvers and faster checks

    Large public resolvers like Google, Cloudflare and Quad9 add many independent caches to check, making propagation easier to observe from multiple points.

Why a DNS change does not appear everywhere at once

The internet does not resolve every domain by asking the source each time. Instead, recursive resolvers cache the answers they have already fetched and reuse them for a set period. When you change a record, the change is instant at the authoritative server, but every resolver that cached the old value keeps serving it until that value expires.

This is why a change seems to appear in some places and not others. The delay is not one uniform time - it is a patchwork of individual caches, each expiring at its own pace depending on when it last looked up your domain.

What the TTL value actually controls

TTL, or Time To Live, is the number of seconds a resolver may keep a cached answer before it must ask the authoritative server again. A high TTL, like 86400 seconds, means caches hold the old answer for a day. A low TTL, like 300 seconds, means they refresh after five minutes.

Lowering the TTL before a planned change is the standard way to make propagation fast. Set it low a day or two in advance, let the old caches drain, then make the change. After it settles you can raise the TTL back up to reduce load on the authoritative server.

A DNS change propagates through the chain: the authoritative server updates instantly, while cached resolvers keep the old record until their TTL expires.

Low versus high TTL: the trade-off

A low TTL means changes spread quickly, which is ideal for environments where records change often, such as failover setups or dynamic IPs. The cost is more queries hitting the authoritative server, since caches cannot hold answers for long and keep asking.

A high TTL means fewer queries and lower server load, which suits stable records that rarely change. The downside is that a mistake takes much longer to undo, because old caches will keep serving the wrong answer for the whole TTL period.

How to check propagation across multiple resolvers

To verify a change, query several independent recursive resolvers rather than trusting a single one. A tool that checks Google, Cloudflare and Quad9 at once gives you a much better picture than your own resolver, which may still be holding a stale cached value.

When the new record is visible from most public resolvers, propagation is essentially complete, even if a few small caches lag behind. If the change still looks stuck everywhere, check the authoritative server directly - a problem there is not a propagation issue at all.

In sintesi

DNS propagation is a feature, not a bug: caching keeps the internet fast at the cost of a short delay after changes. Understand the TTL, lower it before a planned change, and verify with several resolvers so a wait becomes predictable rather than confusing.

← Tutti gli articoli

Verifica del mio IP

Il tuo indirizzo IP pubblico e la posizione di rete, rilevati automaticamente.

Si carica automaticamente all'apertura di NetChecks — nessun dato da inserire. Usa il pulsante Aggiorna dopo aver cambiato rete o riconnesso la VPN.

Il tuo browser

Scansione All-in-One

Esegue in un'unica passata tutti i controlli rilevanti su un IP o hostname: DNS, whois, ping, traceroute, una scansione delle porte note (1-1024), header HTTP e certificato SSL.

Inserisci un dominio o un indirizzo IP ed esegui la scansione per controllare DNS, whois, ping, traceroute, porte comuni, intestazioni HTTP e certificato SSL in un solo passaggio.

La maggior parte dei controlli viene eseguita in parallelo - di solito termina in circa 30 secondi, di più se il target è lento o irraggiungibile.

Il passaggio di scansione delle porte viene eseguito solo se la casella di consenso sopra è selezionata - tutti gli altri controlli vengono eseguiti comunque.

Ping

Invia richieste echo ICMP a un host per verificare raggiungibilità e latenza.

Inserisci un nome host o un indirizzo IP e premi Ping per inviare richieste ICMP echo e misurare la latenza di andata e ritorno.

You Host ICMP Echo Request (type 8) ICMP Echo Reply (type 0) measures: RTT · TTL · packet loss

      

Scopri di più su Ping

Cos'è

Ping invia pacchetti ICMP Echo Request a un host e misura il tempo impiegato dai pacchetti ICMP Echo Reply per tornare indietro. È il test di connettività di rete più elementare che esista: risponde esattamente a una domanda, "questa macchina è raggiungibile, e con quale rapidità?". Il protocollo ICMP (RFC 792) è stato progettato nel 1981 specificamente per trasportare messaggi di controllo e diagnostica sulle reti IP, al di fuori di qualsiasi traffico applicativo - Ping ne è l'implementazione più nota e universalmente disponibile, presente praticamente su ogni sistema operativo e dispositivo di rete fin dalle prime versioni.

Come funziona

Ogni pacchetto ICMP trasporta un campo TTL (Time To Live) decrementato di uno a ogni router attraversato; se raggiunge zero prima di arrivare al target, il pacchetto viene scartato e un errore viene rimandato al mittente. Il tempo di andata e ritorno (RTT), misurato in millisecondi, riflette la latenza di rete cumulativa sull'intero percorso, non solo l'ultimo tratto vicino al target - un punto spesso frainteso, poiché un risultato di ping lento può avere la sua causa in qualsiasi punto del percorso, non necessariamente vicino al server testato. Un ping in genere invia più pacchetti di seguito anziché uno solo, il che permette di distinguere un picco di latenza occasionale da un problema ricorrente e di calcolare un tasso di perdita di pacchetti sul campione.

Interpretare i risultati

Un RTT basso e stabile - pochi millisecondi su una rete locale, tra 10 e 50 ms per una destinazione nello stesso paese, e notevolmente di più per un collegamento intercontinentale - indica una connessione sana. Anche una piccola perdita di pacchetti (oltre l'1-2%) è particolarmente dannosa per usi sensibili alla latenza come VoIP o sessioni remote interattive, dove ogni pacchetto perso si manifesta come un'interruzione o un'interferenza udibile. Una latenza molto variabile da un pacchetto all'altro (jitter) è spesso, per questi stessi usi, un problema maggiore di una latenza elevata ma perfettamente stabile. "Richiesta scaduta" significa che non è arrivata alcuna risposta entro il tempo previsto - l'host potrebbe essere effettivamente offline, un firewall potrebbe bloccare silenziosamente l'ICMP, oppure un percorso potrebbe essere interrotto in qualche punto del tragitto; "Destinazione irraggiungibile" è diverso e più informativo: un router intermedio ha esplicitamente rimandato indietro un messaggio dicendo di non essere riuscito a inoltrare il pacchetto, il che aiuta a circoscrivere dove si trovi realmente il problema.

Errori comuni

L'errore di interpretazione più comune è concludere che un host sia "offline" nel momento in cui un ping fallisce, quando in realtà moltissimi server e dispositivi - specialmente dietro un firewall ben configurato, o ospitati presso i grandi provider cloud - bloccano deliberatamente l'ICMP in ingresso per policy, pur essendo pienamente operativi e raggiungibili sui loro servizi reali (HTTP, un database, ecc.). L'assenza di risposta a un ping è quindi una prova significativa di inattività solo se combinata con altri segnali, come il fatto che anche l'applicazione stessa non risponda. Al contrario, un ping riuscito non garantisce affatto che il servizio applicativo ospitato su quella macchina funzioni correttamente - sono due livelli dello stack di rete del tutto indipendenti.

Quando usarlo

La prima cosa da verificare prima di escalare un ticket: la macchina risponde almeno, prima di indagare oltre? Confermare la connettività dopo una modifica a una regola firewall o a una tabella di routing, per assicurarsi che la modifica non abbia interrotto l'accesso. Stabilire una misurazione di latenza di riferimento prima di un rollout VoIP o di un failover di un collegamento operatore, in modo da avere un punto di confronto oggettivo se in seguito arrivano lamentele sulla qualità delle chiamate. Un controllo di stato periodico e leggero per un MSP che monitora più sedi cliente in parallelo, sempre come complemento - mai come sostituto - di un monitoraggio più approfondito a livello applicativo.

Traceroute

Traccia il percorso di rete (hop per hop) verso un host di destinazione.

Inserisci un nome host o un indirizzo IP ed esegui la scansione per vedere ogni salto di rete tra questo server e la destinazione, con la latenza di ciascun salto.

You TTL=1 TTL=2 TTL=3 Host each hop replies "ICMP Time Exceeded" until TTL reaches the host

      

Ricerca DNS (Nslookup)

Interroga i record DNS: A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, CAA.

Inserisci un dominio, scegli un tipo di record (A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV o CAA) ed esegui la ricerca.

You Root .com Auth NS ① query root ② referral → TLD ③ referral → auth NS ④ answer

      

Whois

Cerca le informazioni di registrazione per un dominio o un indirizzo IP.

Inserisci un dominio o un indirizzo IP per consultarne i dati di registrazione: registrar, organizzazione proprietaria e date importanti.

You Registry RDAP / :43 query: domain / IP reply: registrar, dates, name servers

      

Controllo blacklist

Verifica se un indirizzo IP o un dominio è presente in blacklist pubbliche anti-spam/abuso (DNSBL).

Inserisci un indirizzo IPv4 o un dominio ed esegui per controllare contemporaneamente 7 blacklist pubbliche (DNSBL/RBL) - ciascuna viene mostrata come elencata, non elencata o controllo non riuscito.

You zen.spamhaus.org spamcop.net sorbs.net +4 more reverse-IP DNS query to each DNSBL zone, in parallel

      

Scansione porte TCP

Verifica se le porte TCP sono aperte su un host o IP: porte comuni, un elenco personalizzato o l'intero intervallo 1-65535.

Inserisci un host o un IP, scegli porte comuni, un elenco personalizzato o l'intervallo completo, quindi esegui la scansione per vedere quali porte TCP rispondono.

You 22 open 443 open 3389 closed 8080 closed SYN → SYN-ACK = open · SYN → RST = closed

        
      

Analizzatore di header HTTP

Recupera lo stato della risposta HTTP e gli header per un URL.

Inserisci un URL per ottenere il suo codice di stato HTTP e tutte le intestazioni di risposta inviate dal server.

You Server GET / HTTP/1.1 200 OK + headers Content-Type · Strict-Transport-Security · X-Frame-Options …

      

Verifica certificato SSL/TLS

Esamina il certificato TLS di un host: emittente, date di validità e giorni rimanenti.

Inserisci un nome host per ispezionare il suo certificato TLS: emittente, date di validità e giorni rimanenti prima della scadenza.

You Host ClientHello → ← ServerHello + Certificate + Finished Root CA Intermediate Leaf (site) certificate chain of trust · validity dates checked

      

Ricerca Geo-IP

Cerca la posizione geografica e le informazioni di rete per un indirizzo IP. Lascia vuoto per cercare il tuo indirizzo IP pubblico.

Inserisci un indirizzo IP qualsiasi, oppure lascia vuoto per cercare il tuo, per vedere la posizione approssimativa e le informazioni di rete/ISP.

IP address Geo / RIR database City · Country ASN · Org

        
        
      

Calcolatore di subnet/CIDR

Calcolato interamente nel tuo browser — nessun dato inviato al server.

Inserisci un indirizzo IP e un prefisso CIDR (es. 192.168.1.0/24) per calcolare all'istante l'intervallo di rete, l'indirizzo di broadcast e il numero di host utilizzabili.

network bits (prefix) host bits /24 example — split moves with your prefix

      

Test di velocità

Test di base della velocità di download/upload rispetto a questo server (la precisione dipende dalla connessione in uplink del server stesso).

Premi Avvia per misurare la velocità di download e upload verso questo server. La precisione dipende dalla connessione di questo server.

You Server ↓ download ↑ upload throughput (Mbps)

      

Dizionario dei codici paese

Codici paese ISO 3166-1 alpha-2 — ricerca eseguita interamente nel tuo browser.

Cerca o sfoglia l'elenco dei codici paese ISO 3166-1 alpha-2, ricercato interamente nel tuo browser.

PaeseCodice ISO

Dizionario dei prefissi telefonici

Prefissi internazionali per paese — ricerca eseguita interamente nel tuo browser.

Cerca o sfoglia i prefissi telefonici internazionali per paese, ricercati interamente nel tuo browser.

PaesePrefisso

Orologio mondiale

Scegli un fuso orario per vedere l'ora attuale — trascina il globo per farlo girare.

Scegli un fuso orario dall'elenco, oppure trascina il globo, per vedere l'ora attuale in quel luogo.

Il tuo orario
--:--:--
—

—

Orario selezionato
--:--:--
—
— UTC±00:00
Differenza rispetto a te —

—

Trascina per ruotare il globo.

Stato della rete mobile francese

Siti di antenne mobili guasti o in manutenzione in Francia, per operatore (Orange, Free, SFR, Bouygues Telecom), dai dati pubblici dell'ARCEP. Istantanea aggiornata una volta al giorno dall'ARCEP - non un flusso minuto per minuto.

Sfoglia i dati sui guasti delle antenne mobili e della fibra per operatore francese — nessun dato da inserire, aggiornato automaticamente dai dati pubblici di Arcep.

Fonte: ARCEP, dataset "Sites indisponibles", pubblicato con Licence Ouverte / Etalab 2.0 - riuso commerciale esplicitamente consentito, a differenza dei dati IODA/CAIDA usati in precedenza in questa scheda. Il badge Normale/Attenzione/Allerta è una stima interna (numero di guasti odierno rispetto alla mediana dei giorni precedenti), non una classificazione ufficiale dell'ARCEP. Link alle fonti qui sotto.

Dipartimenti più colpiti

Numero di siti attualmente guasti o in manutenzione, per dipartimento. Fai clic su un operatore sopra per filtrare.

Dati: Arcep — Sites indisponibles · Mappa ufficiale dello stato della rete


Rete fissa (Fibra)

Qualità della rete in fibra (FTTH) per operatore: tasso di guasti segnalati e tasso di errore di connessione, dai dati pubblici dell'ARCEP. Indicatori mensili, media mobile su 6 mesi - non un flusso in tempo reale come la sezione mobile.

Fonte: ARCEP, dataset "Qualité des réseaux en fibre optique", pubblicato con Licence Ouverte / Etalab 2.0 - riuso commerciale esplicitamente consentito. Link alle fonti qui sotto.

Per operatore (gruppo madre)

Medie sugli ultimi 6 mesi disponibili, per gruppo madre dell'operatore infrastrutturale.

Dati: Arcep — Qualité des réseaux en fibre optique