TTL DNS: come scegliere valori corretti e ridurre i problemi

Introduzione

Il TTL DNS è uno di quei parametri che molti impostano una volta e poi dimenticano. Eppure influisce in modo diretto su propagazione delle modifiche, carico sui resolver, tempi di aggiornamento dei record e persino sulla percezione di un sito quando si cambia hosting, IP o provider email.

TTL significa Time To Live: indica per quanto tempo un record DNS può restare in cache prima che il resolver chieda di nuovo il valore autoritativo. In pratica, più il TTL è alto, più il record resta “fermo” nelle cache; più è basso, più le modifiche diventano visibili in fretta, ma con maggiore frequenza di interrogazioni DNS.

Capire come usarlo bene evita errori classici: modifiche che sembrano non propagarsi, switch di server fatti troppo presto, mail che puntano ancora al vecchio MX, oppure una riduzione del TTL lasciata permanente senza motivo, con conseguente aumento di query inutili.

Cos’è davvero il TTL DNS

Ogni record DNS può avere un TTL espresso in secondi. Il valore viene letto dai resolver ricorsivi, che lo usano per decidere quanto conservare il risultato in cache. Se un record ha TTL 3600, un resolver può riutilizzare quel dato per circa un’ora prima di chiedere un aggiornamento.

Il punto importante è che il TTL non controlla la “velocità di Internet” né obbliga tutti a vedere il nuovo record nello stesso istante. Controlla solo quanto a lungo una risposta può essere considerata valida nella cache. Per questo le modifiche DNS non sono mai istantanee in senso assoluto: dipendono da quando ogni resolver ha memorizzato il dato precedente.

Esistono poi altri livelli di cache: il browser, il sistema operativo, i resolver del provider, eventuali CDN e proxy. Il TTL DNS è solo uno dei tasselli, ma resta uno dei più importanti quando si gestiscono siti, email e migrazioni.

Valori tipici e quando usarli

Non esiste un TTL perfetto per tutti i casi. Esiste però una fascia ragionevole, da adattare all’obiettivo operativo.

• 300 secondi o meno: utile prima di una migrazione, quando prevedi un cambio rapido di IP o server.
• 900–3600 secondi: buon compromesso per molti record dinamici o soggetti a cambi più frequenti.
• 14400–86400 secondi: adatto a record stabili, come quelli che cambiano raramente.

Un TTL molto basso non è sempre una scelta migliore. Se porti tutto a 60 secondi in modo permanente, aumenti il numero di richieste ai DNS autoritativi senza un vero vantaggio, soprattutto se la zona è stabile. Al contrario, un TTL troppo alto rende lente le correzioni quando devi intervenire rapidamente.

La scelta corretta dipende dal tipo di record. Un A record del sito può tollerare un valore medio, mentre un record usato in una fase di migrazione potrebbe scendere temporaneamente. I record MX meritano più attenzione, perché incidono sulla consegna della posta. I record TXT usati per SPF, DKIM e verifiche spesso richiedono cambi più frequenti durante la fase di setup.

Quando abbassare il TTL

Abbassare il TTL ha senso soprattutto prima di una modifica pianificata. È la strategia più pulita per preparare una migrazione o un cambio di infrastruttura senza aspettare troppo dopo il cutover.

Il metodo pratico è semplice: riduci il TTL almeno un ciclo prima dell’intervento, aspetta che il valore precedente sia scaduto nelle cache più diffuse, poi esegui la modifica. In questo modo massimizzi la probabilità che i resolver richiedano presto il nuovo record.

È una tecnica utile nei casi più comuni:

• cambio di IP del sito;
• migrazione verso nuovo server o nuova CDN;
• variazione dei record MX durante il trasferimento della posta;
• verifiche SPF/DKIM/DMARC quando i record TXT devono essere aggiornati spesso.

Una volta conclusa la fase critica, conviene riportare il TTL a un valore più stabile. Tenere il TTL basso per sempre non è una buona abitudine se non c’è una reale esigenza operativa.

Quando alzare il TTL

Se la zona DNS è stabile, alzare il TTL può essere una scelta sensata. Riduce le richieste ai resolver autoritativi e rende il comportamento più efficiente, soprattutto per domini con traffico costante e record che cambiano raramente.

Per molti siti normali, un TTL tra 1 e 4 ore è spesso equilibrato. Per record quasi statici, come quelli di un hostname principale in infrastrutture stabili, anche valori più alti possono essere accettabili. L’importante è che la scelta sia coerente con la frequenza delle modifiche previste.

Alzare il TTL è particolarmente utile quando:

• non prevedi cambi di IP a breve;
• la zona è consolidata;
• vuoi ridurre la pressione sui DNS autoritativi;
• stai gestendo un’infrastruttura con molti domini o sotto-domini.

Il vantaggio pratico è duplice: meno query inutili e meno dipendenza da cache molto brevi che, in caso di instabilità, possono aumentare il rumore operativo.

Errori comuni da evitare

Il primo errore è confondere il TTL con il tempo di propagazione totale. Il TTL influenza la cache, ma la propagazione percepita dipende anche da quando i resolver hanno memorizzato il vecchio dato.

Il secondo errore è modificare il record e solo dopo abbassare il TTL. È troppo tardi: chi ha già in cache il valore vecchio continuerà a usarlo fino alla scadenza precedente.

Il terzo errore è impostare TTL estremamente bassi senza motivo. In alcuni casi può aumentare il carico e non risolve problemi reali di aggiornamento, soprattutto se il collo di bottiglia è altrove.

Il quarto errore è ignorare i record correlati. Se cambi IP del sito ma lasci invariati record secondari o configurazioni della posta, il risultato può sembrare un problema DNS quando in realtà è una questione di coerenza tra zone, hosting e servizi.

Come verificare il TTL corretto

La verifica non va fatta solo nel pannello DNS. Conviene controllare il valore pubblicato e osservare come viene risposto dai resolver pubblici più usati.

In un sistema Linux puoi controllare rapidamente con strumenti come dig. Il risultato atteso è vedere il record con il relativo TTL residuo, che può diminuire ad ogni interrogazione se la cache è attiva.

dig example.com A +noall +answer

Se vuoi testare un resolver specifico, puoi interrogare direttamente Google DNS, Cloudflare o un resolver del provider:

dig @8.8.8.8 example.com A +noall +answer

dig @1.1.1.1 example.com A +noall +answer

Il risultato utile non è solo il valore numerico, ma la coerenza con il record che hai impostato nella zona autoritativa. Se il TTL pubblico non coincide con quello atteso, verifica se il pannello DNS applica un valore globale diverso o se stai osservando una cache intermedia.

Per una panoramica più ampia, puoi controllare anche i record MX e TXT con lo stesso metodo. Questo è importante quando il problema sembra riguardare il sito ma in realtà colpisce la posta o le verifiche di dominio.

Gestione pratica in hosting e pannelli

In molti pannelli di hosting il TTL si imposta direttamente nella gestione della zona DNS. Il nome del campo può cambiare: TTL, Time To Live, Default TTL o Record TTL. In alcuni ambienti c’è un TTL globale per la zona e in altri un TTL per singolo record.

La regola pratica è questa: se il provider consente il TTL per record, usa un valore coerente con la funzione di quel record. Se invece il pannello applica un TTL unico alla zona, scegli una media ragionevole che non penalizzi né la stabilità né le modifiche future.

Nei casi di migrazione, il percorso migliore è quasi sempre:

1. abbassare il TTL con anticipo;
2. attendere la scadenza delle cache più diffuse;
3. eseguire il cambio;
4. verificare la risoluzione da più resolver;
5. riportare il TTL a un valore normale quando tutto è stabile.

Questo approccio è più affidabile di una modifica improvvisata fatta all’ultimo minuto.

TTL e CDN: attenzione alle sovrapposizioni

Se usi una CDN o un reverse proxy, il TTL DNS non è l’unico valore che conta. La CDN può avere i propri tempi di cache, i propri TTL interni e regole di invalidazione che incidono sulla visibilità delle modifiche.

In pratica, puoi avere un record DNS aggiornato ma contenuti ancora serviti dalla CDN o da un proxy intermedio. Per questo, quando il problema sembra “DNS”, conviene distinguere tra:

• risoluzione del nome;
• cache del resolver;
• cache della CDN;
• cache applicativa o del browser.

Questa distinzione evita diagnosi sbagliate. Molte volte il record è corretto, ma il contenuto visibile resta vecchio perché la cache di bordo non è stata svuotata oppure perché il backend risponde ancora con la vecchia configurazione.

TTL per email: perché conta più di quanto sembra

Nel mondo email il TTL ha un peso enorme, soprattutto quando si lavora su MX, SPF, DKIM e DMARC. Cambiare provider di posta o configurare un nuovo sistema senza considerare il TTL può portare a ritardi di consegna, verifiche fallite o transizioni incomplete.

Prima di toccare la posta conviene ridurre il TTL dei record coinvolti con anticipo. In seguito, dopo la migrazione, puoi riportarli a valori più stabili. Questo rende più semplice correggere eventuali errori di configurazione senza aspettare ore o giorni prima che tutti vedano il nuovo assetto.

Per la posta, la prudenza è ancora più importante perché i server remoti non interrogano il tuo DNS in modo continuo: si affidano alle cache. Un TTL ragionevole aiuta, ma non sostituisce una migrazione pianificata con verifiche sui record effettivamente pubblicati.

Una regola semplice per non sbagliare

Se il record cambia spesso, il TTL deve essere più basso. Se il record è stabile, il TTL può essere più alto. Se stai preparando un intervento, il TTL va abbassato prima. Se hai finito l’intervento, il TTL va riportato a un valore equilibrato.

Questa regola è semplice, ma funziona bene nella maggior parte degli scenari reali. Non cerca il valore perfetto assoluto: cerca il compromesso giusto tra reattività e stabilità.

In ambienti professionali, il TTL va trattato come un parametro operativo, non come un dettaglio secondario. È piccolo, ma può fare la differenza tra una migrazione pulita e una finestra di disservizio più lunga del previsto.

Conclusione

Il TTL DNS non serve solo a “far propagare prima” le modifiche. Serve a controllare il comportamento della cache in modo consapevole. Se lo usi bene, riduci i tempi di transizione nei cambi pianificati e mantieni efficiente la zona nel funzionamento normale.

La scelta corretta non è quasi mai estrema. Un TTL troppo basso crea rumore, uno troppo alto rallenta gli interventi. Il valore giusto è quello coerente con la frequenza di cambio dei record e con il tipo di servizio che stai gestendo.

Se vuoi un criterio pratico da ricordare, è questo: abbassa prima di cambiare, alza quando hai stabilizzato. In DNS, la disciplina vale più dell’improvvisazione.