Spesso vedo nella configurazione dei DNS server di alcuni domini valori di TTL (Time to Live) molto bassi e decisamente diversi fra loro, pertanto ritengo utile chiarire quello che è il mio punto di visto sulla materia.

Partiamo da una definizione ufficiale, come DNS MadeEasy ce la propone:

The TTL (Time to Live) in seconds is the amount of time the record will cache in resolving name servers and in web browsers. The longer the TTL, the less frequent remote systems will lookup the DNS record, and the less query traffic the domain receives. The shorter the TTL, the faster DNS changes propagate in servers that have cached data, and the higher the volume of query traffic the domain receives.

Recommended values:
Records configured with dynamic IP’s or Failover should have TTL’s set anywhere from 180 to 600 (3 to 10 minutes cache).
Records that are static should have TTL’s set between 1800 (being on the low end) to 86400 seconds (30 minutes to 1 day cache).
If a change is needed for a record with a high TTL, the TTL can be lowered prior to making the change and then raised back up again after.

Come si può notare bisogna in primo luogo fare distinzione fra :

  • record che si riferiscono a IP dinamici o che utilizzano servizi di Failover dinamici
  • record di indirizzi statici che poi sono i casi più comuni

Nel secondo caso io consiglio di mettere il valore 86400 come ttl, che equivale a 86400 secondi = 1 giorno.

Tale valore, infatti, rende di fatto la navigazione internet più veloce (il nostro dns locale non dovrà verificare ogni volta se l’indirizzo ip è cambiato o meno) e caricherà il nostro server autoritativo di meno lavoro.

Qualora sia in programma uno spostamento di sito o di server (ribadisco “programma” in quanto questo tipo di attività andrebbe sempre programmato con cura) si potrà variare il TTL qualche giorno prima ad un valore di 600 o 1800 secondi e poi finito il trasferimento, dopo qualche giorno, si potrà riposizionare il valore originale di 86400.

Ma cosa succede se ho una emergenza e devo cambiare subito l’IP?.

Personalmente ritengo che le emergenze dovrebbero essere gestite con piani preventivi che non prevedano necessariamente il cambio di un IP, e comunque, nel caso peggiore, il servizio richiederà al massimo un giorno per aggiornarsi.

Ribadisco, che se un sito internet non può permettersi un down di 24 ore per un guasto, allora è un sito che necessità di un sistema di sicurezza e ridondanza che va progettato ad hoc e non certamente gestito con un DNS che abbia un TTL di 60 secondi.


Ma Google consiglia diversamente per i record MX di Google for Work… come mai?

Un collega del reparto tecnico di Farnedi ICT, mi ha fatto notare come alcuni provider (ad esempio Register.it) utilizzino valori di default molto più bassi, e che la stessa Google nella guida alla configurazione del servizio di posta Google for Work consiglia valori di molto inferiori (3600 secondo = 1 ora): vedi pagina configurazione MX di Google che sul tema dice:

* Il valore TTL (Time To Live, Durata) corrisponde al numero di secondi che trascorrono prima che successive modifiche al record MX abbiano effetto. Una volta configurati correttamente i record MX, ti consigliamo di modificare il valore TTL inserendo una cifra compresa tra 3600 e 86400, che comunica ai server su Internet di verificare ogni 24 ore, invece che ogni ora, la presenza di eventuali aggiornamenti al record MX.

Approfondendo sui tema si trova anche questo link ufficiale sempre di Google: nozioni base su DNS dove si legge:

Ti consigliamo di impostare un valore TTL pari a 3600, che impone ai server Internet di verificare eventuali modifiche al record ogni ora.

In sintesi, la questione è controversa, e spesso sulla rete si trovano pareri discordanti, che a mio giudizio non tengono conto di tutti i fattori di vantaggio che un TTL più lungo possono offrire complessivamente.

In generale possiamo considerare in modo diverso i diversi record DNS che si vanno a creare, siano essi dei record A di webserver che difficilmente cambieranno  frequentemente (quando ad esempio puntano un server di hosting o un ip di un sistema di loadbalancing o elastic-ip di AWS).

Un discorso diverso può essere fatto se si valuta un server MX, che eventualmente può puntare ad un cluster di IP che possono cambiare più frequentemente (ma in realtà ritengo che anche in questo caso il TTL possa essere mantenuto alto – leggi di seguito il capitolo sui CNAME).

Ma i record CNAME come vengono risolti, rispetto al TTL?

Una questione controversa è quella che riguarda i CNAME, record DNS che puntano ad altri record (Tipicamente record A): quale è il TTL che prevale? quello del CNAME o quello del record A di arrivo?

Cercando sulla rete ho trovato questa risposta al quesito su StackExchange

Il punto principale è che:

  • dipende da come il DNS resolver che utilizzeremo interpreterà la direttiva TTL ,e pertanto non è universalmente applicabile a tutti i casi
  • di base viene usato il TTL del CNAME (che a mio parere è giusto mantenere di 1 giorno) e se viene fornito un IP nuovo solo se si verifica che il TTL del record “puntato” non è più valido.
Pertanto secondo questa interpretazione anche i record CNAME possono avere un TTL lungo e in generale questo vale sia per i record MX che CNAME che utilizzano entrambi come destinazione un indirizzo simbolico e non un IP.

 

Riferimenti e bibliografia

 


E tu come la pensi? Commenti questo post con le tue valutazioni.

Tagged:

About The Author

Lascia un commento o richiedi supporto con il pulsante "Aiuto"