Capire il TTL DNS: perché le modifiche richiedono tempo

Ogni record DNS ha un TTL (time to live), espresso in secondi. È un'istruzione che il nameserver autorevole del dominio dà a ogni resolver che recupera il record: «puoi riutilizzare questa risposta per questo tempo prima di chiedere di nuovo». Un TTL di 300 secondi significa che un resolver che ha appena cercato un dominio non si prenderà la briga di chiedere di nuovo per cinque minuti, anche se nel frattempo il record cambia.

Il compromesso che il TTL bilancia

Un TTL più lungo significa meno query DNS, lookup mediamente più veloci (perché più richieste vengono servite dalla cache) e meno carico sui nameserver autorevoli. Un TTL più breve significa che la modifica a un record si propaga più in fretta, al prezzo di query più frequenti. Non esiste un valore giusto in assoluto: dipende da quanto spesso ci si aspetta che il record cambi e da quanto la situazione tolleri risposte obsolete.

Cosa succede davvero durante una modifica

Aggiornare un record DNS non spinge la modifica a ogni resolver di Internet. Cambia soltanto ciò che il nameserver autorevole dirà la prossima volta che gli verrà chiesto. Ogni resolver che ha già in cache la vecchia risposta continua a servirla finché il TTL della copia in cache non scade: per questo lo stesso dominio può risolversi per un breve periodo in indirizzi diversi a seconda di quale resolver, e quale cache, sta rispondendo.

• Una mossa pratica comune prima di una migrazione pianificata è abbassare il TTL uno o due giorni prima, così il cutover finale si propaga più in fretta.
• Dopo la migrazione, il TTL viene in genere riportato al suo valore normale.
• Un record senza modifiche recenti e con un TTL lungo può comunque richiedere l'intera finestra del TTL per sparire del tutto dalle cache nel mondo, una volta che cambia.

Scegliere un TTL nella pratica

Anche le risposte negative vengono messe in cache, cosa facile da trascurare. Quando un dominio non esiste, la stessa risposta NXDOMAIN viene memorizzata, regolata da un valore separato (il TTL minimo del record SOA, non il TTL di un record che non c'è mai stato). Un dominio appena registrato può a volte sembrare non risolversi per un breve periodo successivo semplicemente perché un resolver aveva già in cache il suo NXDOMAIN da prima che la registrazione fosse completata.

Il TTL è una richiesta, non una garanzia

Vale la pena sapere che il TTL è indicativo e non è fatto rispettare da nessuna autorità esterna. Un resolver è tecnicamente libero di tenere in cache una risposta più a lungo del TTL dichiarato (alcuni lo fanno, sotto carico elevato, per ridurre il volume di query) o di eliminarla prima (un resolver a corto di memoria può scartare in anticipo le voci della cache). Nella stragrande maggioranza dei casi, i resolver pubblici e degli ISP ben gestiti rispettano i TTL in modo fedele e prevedibile, ma è questo il motivo per cui una stima della propagazione basata sul TTL è una solida regola empirica e non una garanzia rigida e contrattuale. Se una modifica non è ancora comparsa in modo significativo dopo la finestra del vecchio TTL, una cache intermedia insolitamente aggressiva è una delle spiegazioni meno comuni ma reali da tenere a mente.

Se stai verificando che una modifica DNS sia andata in produzione, un singolo lookup ti dice solo cosa ha in cache un resolver in questo momento. Ripetere il lookup a distanza di qualche minuto, o pianificare un controllo ricorrente, è un modo molto più affidabile per confermare che una modifica si sia davvero propagata, invece di beccare una sola volta una risposta obsoleta in cache e darla per definitiva.