Tesi: Summary of "Cache Me If You Can: Effects of DNS Time-to-Live

1. UNIVERSITÀ DEGLI STUDI DI TRIESTE
DIPARTIMENTO DI INGEGNERIA E ARCHITETTURA
Corso di Laurea Triennale in Ingegneria Elettronica e Informatica
Summary of “CACHE ME IF YOU CAN:
EFFECT OF DNS TIME-TO-LIVE”
Laureando Relatore
Andrea Zennaro Prof. Alberto Bartoli
Matricola
IN0500404
_________________________________
Anno Accademico 2019/2020

2. Indice
1) Introduzione.......................................................................................................2
2) Come si configurano i TTL?.............................................................................2
3) Metodologia dello studio...................................................................................3
4) Feedback dal dominio .uy.................................................................................5
5) Alcune raccomandazioni per gli operatori DNS...............................................5
6) Conclusioni........................................................................................................6
Fonti.......................................................................................................................6
1

3. Capitolo 1
Introduzione
Il Domain Name System (DNS) è un componente fondamentale di Internet. Ogni pagina web e
messaggio di posta elettronica richiedono informazioni DNS e una pagina web complessa può
facilmente reperire le informazioni da una dozzina o più di ricerche DNS. Il DNS fornisce un
database distribuito a bassa latenza che viene utilizzato, per esempio, per mappare i nomi di
dominio in indirizzi IP.
Con questa posizione centrale, i fornitori di servizi DNS competono per migliorarne costantemente
la qualità, dato che il DNS deve sempre funzionare e gli errori dei principali sistemi di risoluzione
DNS hanno sempre delle notevoli conseguenze. Ad esempio, nel 2016 un attacco DDoS
(Distributed Denial-of-Service) portò interruzioni a molteplici servizi pubblici (inclusi Twitter,
Netflix e New York Times).
Il caching (ovvero la memorizzazione nella cache) è la pietra essenziale per buone prestazioni e
affidabilità del DNS. Infatti è utile per evitare brevi interruzioni nella navigazione e anche per
prevenire attacchi DDoS significativi.
I valori Time-To-Live (TTL) dei record DNS controllano la durata della cache, influenzando quindi
la latenza, la resilienza e il traffico DNS. Fino ad oggi i TTL sono stati poco approfonditi e
determinare dei buoni valori per il DNS è impegnativo.
Capitolo 2
Come si configurano i TTL?
I record vengono duplicati in più luoghi, a volte con diversi TTL. In particolare, i record DNS che
superano i confini delle delegazioni si trovano sia nella zona genitore che in quella figlia e possono
avere diversi TTL. Ad esempio la risoluzione di un Fully-Qualified-Domain-Name (FQDN)
richiede di identificare i server autorevoli (record NS) e i loro indirizzi IP (record A o AAAA) per
ogni parte del FQDN, ma questi record possono anche avere TTL diversi. Inoltre, i suoi record
possono essere forniti da server in-bailiwick (quando sono all'interno del dominio servito, quindi
ns.example.org è nella giurisdizione di example.org) o out-of-bailiwick (ns.example.com non è
nella giurisdizione di example.org). Questi fattori fanno sì che alcuni resolver ricorsivi scartino i
record A / AAAA in-bailiwick quando il record NS scade.
Le prime specifiche DNS atte a risolvere almeno in parte questo problema si ebbero con il
documento RFC2181, che diede la priorità alle risposte del server autorevole della zona figlio
rispetto a quelle del server della zona genitore, ma non si richiedeva che entrambi i server venissero
interpellati.
L'obiettivo dello studio di Moura et al. è di individuare chi effettivamente controlla il caching di
una zona e di determinare i TTL migliori a seconda delle esigenze che gli operatori DNS devono
soddisfare.
2

4. Capitolo 3
Metodologia dello studio
Per rispondere a queste domande sono stati fatti diversi esperimenti nei quali sono state effettuate ai
server DNS delle domande per le coppie di record NS-A a intervalli regolari. Alcuni degli
esperimenti più significativi sono i seguenti.
Per primo è stato scelto il country-code-Top-Level-Domain (ccTLD) dell'Uruguay .uy perché ha
due valori TTL molto diversi per il suo record NS: 172800s alla root e solo 300s nel proprio server
autorevole. Invece per il record A si ha 172800s alla root e 120s nel proprio server. È stata fatta
prima una domanda per il record NS di .uy e poi una poi per il record A del suo server autorevole
a.nic.uy. In entrambi i casi sono state eseguite domande ogni 10 minuti (il doppio del TTL più breve
dei record NS), per due o tre ore (per i records NS o A). Per ciascuna domanda, .uy-NS e a.nic.uy-
A, sono state ottenute rispettivamente circa 190000 e 280000 risposte valide.
Figura 1: TTL osservati per le domande .uy-NS e a.nic.uy-A
La stragrande maggioranza delle risposte segue il valore del server figlio, non quello del genitore: il
90% di .uy-NS è inferiore a 300s, e l'88% di a.nic.uy-A è inferiore a 120s. È stato concluso che la
maggior parte dei resolver sono Child-Centric (seguendo RFC2181).
L'esperimento è stato poi ripetuto per google.co, che è un popolare Second-Level-Domain (SLD). Il
dominio google.co ha anch'esso due valori TTL per il suo record NS: 900s nel server della zona
genitore (.co) e 345600s nell'attuale server autorevole ns.google.com. Sono stati interrogati ogni
600s, per un'ora.
Figura 2: TTL osservati per le domande google.co-NS
Circa il 70% di tutte le risposte ha TTL più lunghi di 900s, risultati che devono provenire dal server
3

5. autorevole figlio. Circa il 9% di tutte le risposte hanno un TTL di esattamente 900s, suggerendo un
nuovo valore dal server autorevole genitore.
Questo esperimento mostra che i resolver che interrogano i SLD sono simili a quelli che interrogano
i TLD, ovvero che la maggior parte sono Child-Centric.
Per rispondere invece a come interagiscano le diverse parti di un FQDN per influenzare l'effettiva
durata TTL della richiesta originata, è stato utilizzato il dominio cachetest.net. In questo caso si
hanno 60 minuti per il record NS e 120 minuti per il record A.
Per prima cosa è stato esaminato come i resolver gestiscano i server autorevoli in-bailiwick.
Figura 3: serie di risposte per l'esperimento in-bailiwick
La prima freccia verso il basso della figura mostra l'ora in cui è stato inizializzato il nuovo server
autorevole con relativo indirizzo IP (dopo 9 minuti).
Questa figura mostra che, prima di cambiare, tutte le domande ricevono risposta dal server
originale. Dai 9 ai 60 minuti si vede che alcuni resolver (le barre blu) continuano ad utilizzare il
server originale, mostrando che hanno memorizzato nella cache i suoi record A e NS. Altri resolver
(barre grigie) passano al nuovo server, suggerendo che hanno recuperato il nuovo record A. Si nota
che la maggior parte dei resolver si fida della propria cache fino allo scadere del record NS.
Successivamente è stato esaminato come i TTL sono considerati quando i server autorevoli sono
out-of-bailiwick.
Figura 4: serie di risposte per l'esperimento out-of-bailiwick
In questo caso, si nota che l'indirizzo IP del server è considerato attendibile anche quando il record
NS è scaduto.
Confrontando in- e out-of-bailiwick (Figura 3 e Figura 4), si vede che i resolver si fidano del record
A per il vecchio server autorevole per quasi tutta la sua durata nella cache, fino a 120 minuti e non
60 minuti. Questo risultato mostra che la maggior parte dei resolver si fida dei record A
memorizzati nella cache per la durata dei TTL quando sono serviti dai server out-of-bailiwick, ma
non dai server in-bailiwick.
4

6. Capitolo 4
Feedback dal dominio .uy
Durante il periodo di analisi, .uy aveva 8 record NS (5 in-bailiwick, 3 out-bailiwick), ma grazie allo
studio di Moura et al. hanno cambiato i TTL dei record NS dei server figli a 86400s (1 giorno). Si è
quindi riscontrato che con i precedenti TTL brevi il tempo di risposta medio era 28,7ms, mentre con
i successivi TTL lunghi molte domande vengono gestite direttamente dalla ricorsione, fornendo un
tempo di risposta di 8ms.
Le differenze nella latenza sono ancora maggiori: al 75% ile i TTL più lunghi hanno una media di
21ms rispetto ai 183ms dei TTL brevi; al 95% ile i TTL più lunghi hanno una media di 200ms
rispetto a 450ms e, al 99% ile questi valori aumentano rispettivamente a 1375ms e 678ms.
Ciò dimostra come in generale una maggiore memorizzazione nella cache dovuta a TTL lunghi sia
un grande vantaggio dal punto di vista della latenza per i client. Non avendo accesso al traffico su
.uy, non è stato possibile valutarne la riduzione, ma anch'essa è probabilmente sostanziale.
Oltre a .uy, anche altri due ccTLD hanno aumentato i propri TTL dei record NS a 1 giorno,
rispettivamente da 30s e da 480s.
Capitolo 5
Alcune raccomandazioni per gli operatori DNS
Una scansione della root zone ha mostrato 34 TLD (inclusi 8 ccTLD) con TTL NS inferiori a 30
minuti e 122 TLD con TTL NS inferiori a 120 minuti. Sono stati contattati gli operatori degli 8
ccTLD chiedendo loro perché avessero scelto TTL così brevi. Solo 5 di loro hanno risposto, di cui 3
affermando di non aver considerato le implicazioni di un TTL breve o di uno eventualmente più
lungo.
I TTL in uso vanno da un minimo di 5 minuti a poche ore o a uno o due giorni. Questa vasta gamma
di valori temporali nelle configurazioni dei TTL sono dovute al fatto che ci sono molti compromessi
in gioco. Ecco alcuni fattori che gli operatori dovrebbero considerare:
1. Un caching più lungo si traduce in risposte più veloci: l'effetto maggiore della
memorizzazione nella cache consente di rispondere alle domande direttamente da resolver
ricorsivi. Sebbene la domanda al server autorevole è solitamente veloce (meno di 100ms), la
risposta diretta dal resolver ricorsivo è molto più veloce.
2. Un caching più lungo si traduce in un traffico DNS inferiore: la memorizzazione nella cache
può notevolmente ridurre il traffico DNS.
3. Un caching più lungo è migliore per gli attacchi DDoS al DNS: la memorizzazione nella
cache può ridurre notevolmente gli effetti di attacchi DDoS sul DNS, a condizione che le
cache durino più a lungo dell'attacco.
4. Un caching più breve supporta modifiche operative: un modo semplice per passare da un
vecchio server a uno nuovo è cambiare i record DNS. Poiché non esiste un metodo per
rimuovere i record DNS memorizzati nella cache, la durata dei TTL rappresenta un ritardo
di transizione necessario per completare il passaggio a un nuovo server. Quindi i TTL bassi
consentono una transizione più rapida.
5. Un caching più breve aiuta il bilanciamento del carico basato su DNS: molti servizi di
grandi dimensioni utilizzano il bilanciamento del carico basato su DNS (ad esempio il
motore di ricerca Bing). Ogni richiesta DNS in arrivo offre l'opportunità di regolare il
5

7. carico, quindi potrebbero essere desiderati TTL brevi per reagire più rapidamente alle
dinamiche del traffico.
Le organizzazioni devono soppesare questi compromessi per trovare un buon equilibrio, dopo aver
considerato altri fattori come il carico del server e la manutenzione.
Sebbene l'analisi non suggerisca un valore TTL “migliore”, ecco alcune raccomandazioni per
diverse situazioni:
1. Per i proprietari di zone generiche e per i TLD si consigliano TTL più lunghi: almeno 1 ora
e idealmente 4, 8 o 24 ore. Supponendo che una manutenzione possa essere programmata in
anticipo, i TTL lunghi hanno un costo ridotto.
2. Per gli utenti del bilanciamento del carico basato su DNS si consiglia TTL brevi: i TTL
possono durare anche 5 minuti, anche se 15 minuti possono fornire un'agilità sufficiente per
molti operatori. Sono un'eccezione alla prima raccomandazione per TTL più lunghi.
3. Per chi ha il controllo: dato che la maggior parte dei resolver è Child-Centric, si possono
controllare direttamente i TTL utilizzati all'interno della zona stessa. Tuttavia si è dimostrato
che una frazione di resolver utilizzerà i TTL memorizzati nella zona genitore, quindi gli
operatori dovrebbero configurare i TTL in entrambe le zone in modo identico.
Capitolo 6
Conclusioni
Lo studio di Moura et al. ha esaminato i TTL del DNS, dimostrando che il TLL effettivo è spesso
diverso da ciò che è stato configurato, poiché compaiono TTL in più posizioni e i resolver
effettuano scelte diverse in base alle loro preferenze (Parent-/Child-Centric e in-/out-of-bailiwick).
Da questo fatto ne è conseguita l'importanza di controllare, se possibile, i TTL sia nella zona
genitore che nella zona figlia. È stato visto come le modifiche al dominio .uy dell'Uruguay, ovvero
l'utilizzo di TTL più lunghi, abbiano comportato un miglioramento nelle prestazioni: una latenza
media molto più bassa per gli utenti e una riduzione del traffico. Infine è stato riscontrato che gli
operatori odierni hanno scarsa consapevolezza dell'importanza dei TTL e dei vantaggi/svantaggi
derivanti dalla loro lunghezza.
Fonti
Giovane C. M. Moura, John Heidemann, Ricardo de O. Schmidt, Wes Hardaker, Cache Me If You
Can: Effects of DNS Time-to-Live, in IMC '19: Proceedings of the Internet Measurement
Conference
6