7 Ottobre 2021

Che cos’è il Time To Live dei DNS (TTL)?

Come scegliere correttamente il giusto valore del TTL del DNS in quest’epoca moderna.

Un TTL (o Time to Live) è un’impostazione cruciale in ogni record DNS che può fare la differenza in alcuni casi tra la vita e la morte, eppure se ne parla raramente.

Se sei anche tu colpevole di utilizzare il TTL predefinito per i tuoi record, devi leggere questo.

Significato TTL

Il TTL dice ai server dei nomi per quanto tempo devono essere memorizzate nella cache le informazioni DNS. I server dei nomi di risoluzione sono come gli intermediari dello scambio DNS. Quando inserisci un dominio nel tuo browser, in realtà stai chiedendo al tuo server dei nomi di risoluzione locale l’indirizzo IP di quel dominio.

Time to Live (TTL) è la quantità di tempo in cui un record viene memorizzato nella cache in un resolver quando viene interrogato il record. Viene misurato in secondi ed è impostato all’interno di ogni record nella configurazione DNS. In altre parole, TTL è un valore che indica al risolutore DNS per quanto tempo deve persistere la cache prima di richiederne una nuova. 

Esempio : se il TTL per un record è impostato su 86.400 secondi (24 ore), il server raccoglierà le informazioni per visualizzare i dettagli aggiornati per quel particolare record in 24 ore e non reinterrogherà il server DNS prima che siano scadute 24 ore.

Perché il TTL è importante?

Per i record di base A e CNAME, probabilmente non ti imbatterai in scenari in cui i tempi TTL causano problemi. Tuttavia, una volta che inizi a modificare dinamicamente gli endpoint come il failover, il TTL diventa molto importante.

Ad esempio, supponiamo che l’indirizzo IP primario per il dominio che stiamo cercando non sia disponibile. Questo dominio ha anche abilitato il failover, che indirizzerà gli utenti a un indirizzo IP di backup quando il primario è inattivo.

Questo potrebbe essere gestito in due modi. Se il record ha un TTL elevato, gli utenti verranno comunque indirizzati all’indirizzo IP primario fino alla scadenza della cache del resolver. Se il record ha un TTL basso, è più probabile che venga puntato prima all’endpoint corretto.

Ma facciamo un esempio forse più eloquente e di facile comprensione.

Immaginiamo che tu abbia registrato il dominio pippo.it su FORNITORE 1 e tu abbia il servizio di Hosting Web e Mail separato su un server in gestione da FORNITORE 2.

Immaginiamo ora, come è successo a Marzo 2021 che il datacenter del FORNITORE 2 vada a fuoco in maniera gravissima tanto da risultare distrutto.

Incendio Datacenter OVH
Incendio del Datacenter OVH in Francia con conseguente perdita irrimediabile di milioni di siti web.

Immaginiamo che tu sia una persona scaltra e che faccia backup automatici su un server esterno che chiameremo FORNITORE 3.

I dati del backup sono integri e salvi dunque.

Per ripartire velocemente, molto probabilmente andrai da FORNITORE 3 (Quello dove è il backup) e chiederai di noleggiare un server dove andrai a fare il restore del backup dei file e del database. Importerai la configurazione del webserver, i certificati SSL e ti rimane solo di Puntare i record DNS del dominio con il www e senza il www verso L’IP del nuovo server sul FORNITORE 3.

Un gioco da ragazzi.

Ti logghi nel pannello di controllo della gestione dominio, ti sposti nella zona DNS dove sono memorizzate le informazioni e trovi un record di default impostato a 640800.

640800 cosa ? Secondi !

Ovvero una settimana.

Tu inserisci il valore del nuovo IP del server sul FORNITORE 3 dove hai fatto il restore del backup e prima che il mondo venga informato del nuovo IP passerà fino ad una settimana perchè i nameserver hanno avuto come direttiva quella di considerare buona l’informazione DNS recuperata per una settimana.

Ovvio, se un nameserver di un fornitore (facciamo per esempio Google) è passato 2 giorni fa, il tempo da aspettare non sarà più una settimana, ma 5 giorni, ma comunque è lecito e corretto dire che con un TTL di 640800 ci si aspetta una propagazione DNS in una settimana così come un TTL a 86400 secondi ci si aspetta la propagazione entro 24 ore e via dicendo.

Se il valore fosse stato ad esempio a 900 secondi, il sito sul nuovo server del FORNITORE 3 sarebbe tornato visibile entro un tempo massimo di 15 minuti.

DNS TTL e migliori impostazioni

Una delle domande più comuni che ci vengono poste è: “Quali sono le migliori impostazioni per il Time To Live ?” Poiché la risposta non è sempre semplice per tutti gli scenari. Abbiamo compilato alcune best practice per aiutarti a determinare quale impostazione è più appropriata per il tuo dominio. 

Valori TTL elevati consigliati

I valori TTL elevati vengono in genere utilizzati per i record che cambiano raramente, come i record MX o TXT. TTL più lunghi riducono i tempi di risoluzione poiché ogni volta che un server dei nomi autorevole fornisce una risposta a una query, si ottiene una ricerca aggiuntiva. Un TTL elevato fornisce risposte più rapide per più risorse statiche archiviando le informazioni localmente prima di doverle recuperare di nuovo.

Esempio TTL 

Se hai il record A www.example.com che punta all’indirizzo IP 2.2.2.2 e un TTL impostato su 86.400 (24 ore), quando il client A interroga www.example.com , l’IP 2.2.2.2 verrà memorizzato nel suo cache per un’intera giornata. Il cliente A non effettuerà un’altra query per www.example.com poiché il suo resolver sa già a quale IP andare e per quanto tempo. Se l’IP per quel record A viene modificato in 3.3.3.3, il Cliente A continuerà a passare a 2.2.2.2 per le 23 ore successive alla visita iniziale fino a quando il TTL non arriva a 0. A questo punto, il record scade e un è possibile eseguire una nuova query su tale FQDN. Quindi, il Cliente A verrà indirizzato a 3.3.3.3. alla loro prossima domanda.

Nota : se è necessario apportare modifiche quando si utilizzano valori TTL elevati, sarà necessario abbassare il TTL e attendere la scadenza della cache prima di poter apportare modifiche. Ciò eliminerà la necessità di attendere la scadenza del record.

Valori TTL bassi consigliati

Le risorse che richiedono aggiornamenti frequenti richiedono un valore TTL basso. Un tempo di cache inferiore è inoltre essenziale per le modifiche al sito Web e alla rete. I servizi di gestione DNS, come Failover e Load Balancing, richiedono un TTL basso per poter indirizzare gli utenti finali all’IP aggiornato. In caso di picchi di traffico imprevisti, le query non possono essere inviate all’IP aggiornato fino alla scadenza della cache, lasciando inefficaci i servizi di gestione DNS durante i periodi critici. Un TTL più breve è il rimedio per questo tipo di situazioni.

Nota : bassi TTL sono consigliati per i record critici. Un buon intervallo potrebbe essere compreso tra 30 secondi e 300 secondi (5 minuti) .

Se un TTL è impostato su 30 secondi per adattarsi a frequenti modifiche al DNS, l’esperienza dell’utente finale è minimamente influenzata e ti offre la massima flessibilità. Anche se questo può sembrare l’ideale, se un utente visita frequentemente il tuo sito in un giorno, esegue una query sul record www.example.com ogni 30 secondi circa e quando lo moltiplichi per il numero di utenti, il conteggio delle query aumenta, che può comportare costi maggiori. 

Logica TTL

La regola empirica per l’impostazione dei valori TTL per i record non critici che potrebbero richiedere modifiche nel prossimo futuro consiste nel considerare un TTL più breve. Tuttavia, non vuoi nemmeno pagare per il maggior numero di query fornite da TTL inferiori, quindi un TTL di appena 30 secondi, o anche mezz’ora, non è la migliore risoluzione. In questo caso, vorrai utilizzare un TTL più lungo da 1 a 12 ore .

Puoi regolare il tuo TTL per adattarlo alle esigenze di accessibilità dei tuoi utenti finali.  

Casi d’uso TTL più comuni

I seguenti casi d’uso includono le risposte del nostro team di supporto per aiutarti con i migliori valori TTL per il tuo dominio.

Scenario : utilizzo il failover e ho bisogno del minor tempo di inattività possibile. Quale TTL devo impostare?

Risposta : se la disponibilità del tuo FQDN è assolutamente indispensabile, il failover è un must ma richiede un TTL basso per funzionare nel modo desiderato. Il failover non può ignorare in alcun modo i TTL. Se hai un TTL di 1800 (secondi) per il tuo record di failover e fallisce sul secondo IP, gli utenti non verranno indirizzati all’IP aggiornato per un massimo di 30 minuti (fino alla scadenza della cache nel resolver). Con questo in mente, vorrai impostare un TTL basso e più basso è, meglio è. Detto questo, molti resolver non riconosceranno TTL inferiori a 30 secondi, ma puoi sempre fare un record di test per scoprire se il tuo resolver consente TTL inferiori a 30 secondi. 

Scenario : questo record non necessita di failover, ma apportiamo alcune modifiche.

Risposta : se il record in questione non è mission-critical ma viene aggiornato di tanto in tanto, un TTL più alto è la strada da percorrere. La domanda di follow-up più comune è “e quando devo fare un cambiamento?” e la risposta è pianificare l’aggiornamento. Supponiamo che tu abbia il TTL impostato su 7200 (2 ore), una volta che sai di voler effettuare l’aggiornamento, riduci il TTL per quanto tempo ti senti a tuo agio con i tempi di inattività (30 secondi è il minimo che consigliamo) e quindi attendi il TTL- in questo caso, aspetteresti due ore. Trascorse due ore, puoi modificare il record e ripristinare il valore TTL iniziale.

Comprensione del tempo di vita (time to live) per il perfezionamento della strategia DNS

La bellezza del Time To Live è poter personalizzare completamente i valori per adattarli al meglio alle esigenze del tuo dominio. Comprendere TTL e come usarlo in modo efficace ti assicurerà di massimizzare la tua strategia DNS.

Una regola per vivere felici con i DNS

Una regola semplice per vivere sereni con i Time To Live dei DNS è quella che recita “non troppo, non troppo poco. Il Giusto”. Ovvero comprendere che un valore troppo elevato del TTL possa essere assolutamente CATASTROFICO in alcune condizioni in cui si ha necessità di switchare velocemente l’IP ad esempio verso un nuovo server, un nuovo fornitore, una nuova struttura (magari perchè si sta diventando vittime di attacchi DDoS ad esempio), ed allo stesso tempo comprendere che può essere paranoico impostare un TTL a 10 secondi a meno che effettivamente non possiamo tollerare nemmeno un minuto di downtime.

Ammesso che non siate realtà come Top Fortune 500, in cui un minuto di Down può significare milioni di euro di danni, un valore ragionevole e pacifico per la quasi totalità della popolazione e delle realtà è di impostarlo tra un range che vai dai 5 ai 15 minuti.

Con questa “regola” magari non farete la migliore scelta ma SICURAMENTE non farete la peggiore.

Hai dei dubbi? Non sai da dove iniziare? Contattaci !

Abbiamo tutte le risposte alle tue domande per aiutarti nella giusta scelta.

Chatta con noi

Chatta direttamente con il nostro supporto prevendita.

0256569681

Contattaci telefonicamente negli orari d’ufficio 9:30 – 19:30

Contattaci online

Apri una richiesta direttamente nell’area dei contatti.

INFORMAZIONI

Managed Server S.r.l. è un player italiano di riferimento nel fornire soluzioni avanzate di sistemistica GNU/Linux orientate all’alta performance. Con un modello di sottoscrizione dai costi contenuti e prevedibili, ci assicuriamo che i nostri clienti abbiano accesso a tecnologie avanzate nel campo dell’hosting, server dedicati e servizi cloud. Oltre a questo, offriamo consulenza sistemistica su sistemi Linux e manutenzione specializzata in DBMS, IT Security, Cloud e molto altro. Ci distinguiamo per l’expertise in hosting di primari CMS Open Source come WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart e Magento, affiancato da un servizio di supporto e consulenza di alto livello adatto per la Pubblica Amministrazione, PMI, ed aziende di qualsiasi dimensione.

Red Hat, Inc. detiene i diritti su Red Hat®, RHEL®, RedHat Linux®, e CentOS®; AlmaLinux™ è un marchio di AlmaLinux OS Foundation; Rocky Linux® è un marchio registrato di Rocky Linux Foundation; SUSE® è un marchio registrato di SUSE LLC; Canonical Ltd. detiene i diritti su Ubuntu®; Software in the Public Interest, Inc. detiene i diritti su Debian®; Linus Torvalds detiene i diritti su Linux®; FreeBSD® è un marchio registrato di The FreeBSD Foundation; NetBSD® è un marchio registrato di The NetBSD Foundation; OpenBSD® è un marchio registrato di Theo de Raadt. Oracle Corporation detiene i diritti su Oracle®, MySQL®, e MyRocks®; Percona® è un marchio registrato di Percona LLC; MariaDB® è un marchio registrato di MariaDB Corporation Ab; REDIS® è un marchio registrato di Redis Labs Ltd. F5 Networks, Inc. detiene i diritti su NGINX® e NGINX Plus®; Varnish® è un marchio registrato di Varnish Software AB. Adobe Inc. detiene i diritti su Magento®; PrestaShop® è un marchio registrato di PrestaShop SA; OpenCart® è un marchio registrato di OpenCart Limited. Automattic Inc. detiene i diritti su WordPress®, WooCommerce®, e JetPack®; Open Source Matters, Inc. detiene i diritti su Joomla®; Dries Buytaert detiene i diritti su Drupal®. Amazon Web Services, Inc. detiene i diritti su AWS®; Google LLC detiene i diritti su Google Cloud™ e Chrome™; Facebook, Inc. detiene i diritti su Facebook®; Microsoft Corporation detiene i diritti su Microsoft®, Azure®, e Internet Explorer®; Mozilla Foundation detiene i diritti su Firefox®. Apache® è un marchio registrato di The Apache Software Foundation; PHP® è un marchio registrato del PHP Group. CloudFlare® è un marchio registrato di Cloudflare, Inc.; NETSCOUT® è un marchio registrato di NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, e Kibana® sono marchi registrati di Elastic N.V. Questo sito non è affiliato, sponsorizzato, o altrimenti associato a nessuna delle entità sopra menzionate e non rappresenta nessuna di queste entità in alcun modo. Tutti i diritti sui marchi e sui nomi di prodotto menzionati sono di proprietà dei rispettivi detentori di copyright. Ogni altro marchio citato appartiene ai propri registranti. MANAGED SERVER® è un marchio registrato a livello Europeo da MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italia.

Torna in alto