--- id: "dns-propagation" kind: "glossary-term" title: "propagazione DNS" language: "it" category: "DNS e basi tecniche" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/it/glossario/propagazione-dns/" translations: en: "https://tldlog.com/glossary/dns-propagation/" es: "https://tldlog.com/es/glosario/propagacion-dns/" de: "https://tldlog.com/de/glossar/dns-propagation/" fr: "https://tldlog.com/fr/glossaire/propagation-dns/" pt-BR: "https://tldlog.com/pt/glossario/propagacao-dns/" ru: "https://tldlog.com/ru/glossariy/rasprostranenie-dns/" zh-Hans: "https://tldlog.com/zh/cihui/dns-chuanbo/" --- # propagazione DNS Il nome informale del ritardo prima che una modifica al DNS sia visibile a tutti. In realtà nulla si diffonde su internet: i resolver conservano semplicemente le vecchie risposte finché le loro copie memorizzate non scadono. L'attesa dipende dal TTL dei record e, per le modifiche dei name server, dalle impostazioni proprie del TLD. Quando le impostazioni DNS di un dominio cambiano, per esempio per spostare un sito web o passare a nuovi name server, non tutti gli utenti vedono la modifica nello stesso momento. Per un certo periodo alcuni raggiungono la vecchia configurazione e altri la nuova. Questa attesa è ciò che si chiama propagazione DNS. ## Che cosa si intende per propagazione DNS «Propagazione» è un termine informale. Fa pensare a una modifica che si diffonde attraverso internet, ma in realtà non viene inviato nulla da nessuna parte. I resolver, i server che cercano i nomi per conto degli utenti, conservano copie delle risposte già ricevute e le riutilizzano finché non scadono. Solo allora ripetono la richiesta. La RFC 9499, il documento dell'IETF sulla terminologia DNS, non contiene la voce «propagation». Il termine di solito copre due tipi di modifica: - Una modifica a un record nella zona del dominio stesso, come un nuovo record A che indirizza il nome verso un nuovo server web. - Un cambio di name server. Si effettua presso il registrar, che lo trasmette al registro; il registro pubblica poi la nuova delega nella zona del TLD. ## Perché le modifiche non sono immediate: cache e TTL Le cache principali sono i resolver ricorsivi gestiti da fornitori di accesso a internet, aziende e servizi pubblici. Lo stub resolver di un telefono o di un computer di norma si affida a uno di questi. Ogni record DNS ha un TTL: un numero di secondi, fissato da chi gestisce la zona, che indica per quanto tempo se ne può conservare una copia. Per una copia in cache il conteggio scende e, arrivato a zero, la copia viene scartata e la ricerca successiva recupera di nuovo il record. Un TTL di 0 significa che il record non deve essere messo in cache. Il TTL è un massimo, non una garanzia. I resolver possono limitare i TTL molto lunghi (la RFC 8767 raccomanda un limite di sette giorni), e molti conservano le risposte per almeno alcune decine di secondi anche quando il TTL è più basso. Soprattutto, nessuno può cancellare una copia in cache dal resolver di qualcun altro. È questo il vero motivo dell'attesa. ## Quanto tempo serve davvero e come ridurlo prima di una modifica Non esiste un valore unico e universale: dipende dai TTL in gioco. Per la modifica di un record, la vecchia risposta può sopravvivere in un resolver fino al vecchio TTL del record, contato dal momento in cui quel resolver l'ha recuperata l'ultima volta. Con un TTL di 3600, un resolver può fornire la vecchia risposta fino a un'ora dopo la modifica. Per un cambio di name server si sommano tre ritardi: 1. Il registrar invia la modifica al registro. 2. Il registro la pubblica nella zona del TLD. Per i gTLD soggetti al Registry Agreement base dell'ICANN (versione del 21 gennaio 2024), il livello di servizio è di 60 minuti per almeno il 95% delle sonde di test dell'ICANN, a ottobre 2026. Questo valore non riguarda i gTLD storici come .com, che hanno accordi propri, né i ccTLD. 3. Scadono i record NS in cache. La zona del TLD conserva una propria copia dei record NS del dominio, con un TTL che il titolare del dominio non può modificare. Il metodo standard per ridurre l'attesa, descritto nella RFC 1034 nel 1987, consiste nell'abbassare il TTL in anticipo, almeno un intero periodo del vecchio TTL prima della modifica, effettuare la modifica e poi rialzare il TTL. Per le zone .es, Red.es raccomanda un TTL e un Minimum del SOA di 3.600 secondi in condizioni normali, e valori temporanei fino a 900 secondi (15 minuti) prima di modifiche importanti (a ottobre 2026). Abbassare i propri TTL non accorcia la copia dei record NS conservata dal TLD. ## Cache negativa: perché un nuovo nome può risultare ancora «inesistente» I resolver ricordano anche che qualcosa non esiste. Se qualcuno cerca un nome prima che i suoi record siano creati, il resolver può mettere in cache una risposta NXDOMAIN (il nome non esiste) o una risposta NODATA (il nome esiste ma non ha record di quel tipo). Una risposta negativa viene conservata per il minore di due valori del record SOA della zona: il suo TTL e il campo Minimum. Con i valori normali di Red.es, 3600 e 3600 (a ottobre 2026), si arriva fino a un'ora. La RFC 2308 suggerisce che i resolver limitino per impostazione predefinita la cache negativa a un periodo tra una e tre ore. La lezione pratica: creare i record prima di provare o annunciare un nuovo nome. Una prova anticipata può farlo risultare inesistente per tutta la durata della cache negativa. ## Come verificare se una modifica è visibile - Interrogare direttamente i server autoritativi del dominio. Rispondono dalla zona, non da una cache. - Poi interrogare uno o più resolver ricorsivi. Se restituiscono ancora i vecchi dati, il TTL che mostrano è il tempo che manca prima della richiesta successiva. - Per un cambio di name server, verificare che i server del TLD restituiscano i nuovi record NS. È il punto misurato dal tempo di aggiornamento dell'ICANN. ## Pianificare una migrazione senza interruzioni 1. Preparare prima il nuovo hosting o i nuovi name server, e verificare che i nuovi server rispondano già in modo corretto e autoritativo per il dominio. Red.es lo raccomanda per .es. 2. Abbassare i TTL in anticipo, come descritto sopra. 3. Effettuare la modifica: aggiornare i record, oppure cambiare i name server tramite il registrar. Per .es, le modifiche di delega si chiedono a Red.es con la procedura prevista. 4. Mantenere attivi i vecchi server o il vecchio hosting, con dati corretti, almeno per il più lungo tra il TTL del TLD e il TTL del dominio. 5. Verificare, poi rialzare i TTL. Un esempio pratico, con valori puramente illustrativi: example.com ha un record A con un TTL di 86.400 secondi (un giorno). Due giorni prima di spostare il sito web, il titolare abbassa il TTL a 900. Trascorso il vecchio TTL di un giorno, modifica il record A, e in circa 15 minuti i resolver che rispettano il TTL ricevono il nuovo indirizzo. ## Fonti - [Domain names - concepts and facilities (RFC 1034)](https://www.rfc-editor.org/rfc/rfc1034.txt) - [Negative Caching of DNS Queries (DNS NCACHE) (RFC 2308)](https://www.rfc-editor.org/rfc/rfc2308.txt) - [Considerations for Large Authoritative DNS Server Operators (RFC 9199)](https://www.rfc-editor.org/rfc/rfc9199.txt) - [Registry Agreement (ICANN base gTLD Registry Agreement, version of 21 January 2024), Specification 10](https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-21-01-2024-en.html) - [Guía informativa DNS, Versión 1.1 (dominios.es, Red.es)](https://www.dominios.es/sites/dominios/files/2026-02/dns-guia-informativa-y-requisitos-de-configuracion.pdf) ## termini correlati - [caching DNS](https://tldlog.com/it/glossario/caching-dns/) - [TTL](https://tldlog.com/it/glossario/ttl/) - [resolver](https://tldlog.com/it/glossario/resolver/) - [record NS](https://tldlog.com/it/glossario/record-ns/) - [caching negativo](https://tldlog.com/it/glossario/caching-negativo/)