SlideShare a Scribd company logo
1 of 10
Summary of
“Cache Me If You Can:
Effects of DNS Time-to-Live”
Relatore:
Prof. Alberto Bartoli
Laureando:
Andrea Zennaro
Anno Accademico 2019/2020
UNIVERSITÀ DEGLI STUDI DI TRIESTE
Dipartimento di Ingegneria e Architettura
Corso di Laurea Triennale in Ingegneria Elettronica e Informatica
Introduzione
 DNS struttura fondamentale per il funzionamento di Internet
• Qualsiasi operazione richiede informazioni DNS
• Suddivisione in zone: zona figlia, zona genitore
 Il caching è il componente cardine per buone prestazioni DNS
• Utile contro brevi interruzioni nella navigazione
• Utile per prevenire attacchi DDoS
 I valori TTL dei record controllano la durata della cache
• Da essi dipendono: latenza, resilienza, traffico
Problema: configurare i TTL
 I record vengono duplicati in più luoghi, a volte con diversi TTL
• Due tipi di resolver: Child-Centric e Parent-Centric
 Mancanza di specifiche precise per la priorità delle risposte
 La risoluzione di un FQDN richiede molteplici record
• Differenti TTL per le coppie di record NS-A
• Gestione differente dei record A a seconda se sono in-bailiwick o out-of-bailiwick
Obiettivi dello studio
1. Determinare cosa controlla il caching di una zona
• Resolver Child-Centric o Parent-Centric
• Utilizzo dei record A in-bailiwick e out-of-bailiwick
2. Fornire intervalli di valori TTL agli operatori di zona a seconda delle esigenze
• TTL lunghi vs TTL brevi
Child-Centric o Parent-Centric?
 Procedimento: domande a ripetizione per i recod NS-A
 Analisi del TLD .uy
• Child TTL record NS = 300s e record A = 120s (.uy)
• Parent TTL coppia di record NS-A = 2 giorni (root)
 Analisi del SLD google.co
• Child TTL record NS = 4 giorni (google.com)
• Parent TTL record NS = 900s (.co)
 La maggioranza dei resolver è Child-Centric
In-/out-of-bailiwick
 Uso del dominio cachetest.net
• TTL record NS = 1 ora e TTL record A = 2 ore per il server autorevole
• Inizializzazione di un nuovo server autorevole dopo 9 minuti
Out-of-bailiwick: entrambi i server
fuori dal dominio
La maggioranza dei resolver utilizza il vecchio
record A fino al termine del suo TTL
In-bailiwick: entrambi i server nel
dominio
La maggioranza dei resolver utilizza il vecchio
record A finché il record NS è valido
Feedback dal dominio .uy
 Prima: TTL record NS del server autorevole = 5 minuti
 Dopo: TTL record NS del server autorevole = 1 giorno
 Risultati ottenuti:
• Diminuzione dei tempi medi di risposta
• Diminuzione della latenza
• Riduzione sostanziale del traffico
 Dimostrazione che l’utilizzo di TTL più lunghi è generalmente più conveniente
Raccomandazioni per gli operatori DNS
 Caching più lungo = risposte più veloci, traffico DNS inferiore
• Valori TTL a partire da 1 ora
• Ideale per TLD e zone generiche
 Caching più breve = supporto a modifiche operative
• Valori TTL di pochi minuti e a volte secondi
• Passare rapidamente da un vecchio server a uno nuovo
 Configurare i TTL in modo identico sia nella propria zona che in quella genitore
Conclusioni
 TTL effettivo spesso diverso da quello configurato
• Dipende dalle preferenze dei resolver
 È importante controllare i TTL sia nella propria zona che in quella genitore
• Se possibile impostare i valori TTL in modo identico
 Migliori prestazioni del dominio .uy dopo le modifiche suggerite
• Dovute all’impiego di TTL più lunghi, generalmente preferiti
 È necessario conoscere i compromessi dovuti ai TTL per buone prestazioni DNS
Grazie per l’attenzione

More Related Content

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

Mobile app and disaster recovery with aws
Mobile app and disaster recovery with awsMobile app and disaster recovery with aws
Mobile app and disaster recovery with aws
Paolo latella
 
9 Intranetting
9 Intranetting9 Intranetting
9 Intranetting
acapone
 
festival ICT 2013: Versatilità del Cloud Computing: dalle APP al Disaster Rec...
festival ICT 2013: Versatilità del Cloud Computing: dalle APP al Disaster Rec...festival ICT 2013: Versatilità del Cloud Computing: dalle APP al Disaster Rec...
festival ICT 2013: Versatilità del Cloud Computing: dalle APP al Disaster Rec...
festival ICT 2016
 
presentazione_Lelli_final
presentazione_Lelli_finalpresentazione_Lelli_final
presentazione_Lelli_final
Matteo Lelli
 
Presentazione Nuvola Vertica Light
Presentazione Nuvola Vertica LightPresentazione Nuvola Vertica Light
Presentazione Nuvola Vertica Light
Alberto.F
 
Creating Highly-Available MongoDB Microservices with Docker Containers and Ku...
Creating Highly-Available MongoDB Microservices with Docker Containers and Ku...Creating Highly-Available MongoDB Microservices with Docker Containers and Ku...
Creating Highly-Available MongoDB Microservices with Docker Containers and Ku...
MongoDB
 
Creating highly available MongoDB Microservices with Docker Containers and Ku...
Creating highly available MongoDB Microservices with Docker Containers and Ku...Creating highly available MongoDB Microservices with Docker Containers and Ku...
Creating highly available MongoDB Microservices with Docker Containers and Ku...
MongoDB
 
DDive2011 - Performance on Lotus Domino
DDive2011 - Performance on Lotus DominoDDive2011 - Performance on Lotus Domino
DDive2011 - Performance on Lotus Domino
GTTech
 

Similar to Summary of "Cache Me If You Can: Effects of DNS Time-to-Live (20)

Tivoli Storage Manager - backup and restore for Domino, #dd13
Tivoli Storage Manager - backup and restore for Domino, #dd13Tivoli Storage Manager - backup and restore for Domino, #dd13
Tivoli Storage Manager - backup and restore for Domino, #dd13
 
Townet e il Tdma
Townet e il TdmaTownet e il Tdma
Townet e il Tdma
 
Il modello Differentiated Service (DiffServ) per il QoS
Il modello Differentiated Service (DiffServ) per il QoSIl modello Differentiated Service (DiffServ) per il QoS
Il modello Differentiated Service (DiffServ) per il QoS
 
Mobile app and disaster recovery with aws
Mobile app and disaster recovery with awsMobile app and disaster recovery with aws
Mobile app and disaster recovery with aws
 
6 Dns Parte1
6 Dns Parte16 Dns Parte1
6 Dns Parte1
 
9 Intranetting
9 Intranetting9 Intranetting
9 Intranetting
 
Datacenter@glance
Datacenter@glanceDatacenter@glance
Datacenter@glance
 
Implementazione DAOS in ambienti enterprise
Implementazione DAOS in ambienti enterpriseImplementazione DAOS in ambienti enterprise
Implementazione DAOS in ambienti enterprise
 
festival ICT 2013: Versatilità del Cloud Computing: dalle APP al Disaster Rec...
festival ICT 2013: Versatilità del Cloud Computing: dalle APP al Disaster Rec...festival ICT 2013: Versatilità del Cloud Computing: dalle APP al Disaster Rec...
festival ICT 2013: Versatilità del Cloud Computing: dalle APP al Disaster Rec...
 
Presentation - Extended Summary of “Comparing the Effects of DNS, DoT, and D...
Presentation - Extended Summary of “Comparing the Effects of DNS, DoT, and  D...Presentation - Extended Summary of “Comparing the Effects of DNS, DoT, and  D...
Presentation - Extended Summary of “Comparing the Effects of DNS, DoT, and D...
 
Dalla Unified Communication & Collaboration alla Virtualizzazione: le opportu...
Dalla Unified Communication & Collaboration alla Virtualizzazione: le opportu...Dalla Unified Communication & Collaboration alla Virtualizzazione: le opportu...
Dalla Unified Communication & Collaboration alla Virtualizzazione: le opportu...
 
Thread
ThreadThread
Thread
 
Soluzioni per la difesa da attacchi DoS nelle reti SDN
Soluzioni per la difesa da attacchi DoS nelle reti SDNSoluzioni per la difesa da attacchi DoS nelle reti SDN
Soluzioni per la difesa da attacchi DoS nelle reti SDN
 
presentazione_Lelli_final
presentazione_Lelli_finalpresentazione_Lelli_final
presentazione_Lelli_final
 
Solo un server domino può sopportare così tanto carico e continuare a funzionare
Solo un server domino può sopportare così tanto carico e continuare a funzionareSolo un server domino può sopportare così tanto carico e continuare a funzionare
Solo un server domino può sopportare così tanto carico e continuare a funzionare
 
Presentazione Nuvola Vertica Light
Presentazione Nuvola Vertica LightPresentazione Nuvola Vertica Light
Presentazione Nuvola Vertica Light
 
OpenStack Network-as-a-Service - Neutron
OpenStack Network-as-a-Service - NeutronOpenStack Network-as-a-Service - Neutron
OpenStack Network-as-a-Service - Neutron
 
Creating Highly-Available MongoDB Microservices with Docker Containers and Ku...
Creating Highly-Available MongoDB Microservices with Docker Containers and Ku...Creating Highly-Available MongoDB Microservices with Docker Containers and Ku...
Creating Highly-Available MongoDB Microservices with Docker Containers and Ku...
 
Creating highly available MongoDB Microservices with Docker Containers and Ku...
Creating highly available MongoDB Microservices with Docker Containers and Ku...Creating highly available MongoDB Microservices with Docker Containers and Ku...
Creating highly available MongoDB Microservices with Docker Containers and Ku...
 
DDive2011 - Performance on Lotus Domino
DDive2011 - Performance on Lotus DominoDDive2011 - Performance on Lotus Domino
DDive2011 - Performance on Lotus Domino
 

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

  • 1. Summary of “Cache Me If You Can: Effects of DNS Time-to-Live” Relatore: Prof. Alberto Bartoli Laureando: Andrea Zennaro Anno Accademico 2019/2020 UNIVERSITÀ DEGLI STUDI DI TRIESTE Dipartimento di Ingegneria e Architettura Corso di Laurea Triennale in Ingegneria Elettronica e Informatica
  • 2. Introduzione  DNS struttura fondamentale per il funzionamento di Internet • Qualsiasi operazione richiede informazioni DNS • Suddivisione in zone: zona figlia, zona genitore  Il caching è il componente cardine per buone prestazioni DNS • Utile contro brevi interruzioni nella navigazione • Utile per prevenire attacchi DDoS  I valori TTL dei record controllano la durata della cache • Da essi dipendono: latenza, resilienza, traffico
  • 3. Problema: configurare i TTL  I record vengono duplicati in più luoghi, a volte con diversi TTL • Due tipi di resolver: Child-Centric e Parent-Centric  Mancanza di specifiche precise per la priorità delle risposte  La risoluzione di un FQDN richiede molteplici record • Differenti TTL per le coppie di record NS-A • Gestione differente dei record A a seconda se sono in-bailiwick o out-of-bailiwick
  • 4. Obiettivi dello studio 1. Determinare cosa controlla il caching di una zona • Resolver Child-Centric o Parent-Centric • Utilizzo dei record A in-bailiwick e out-of-bailiwick 2. Fornire intervalli di valori TTL agli operatori di zona a seconda delle esigenze • TTL lunghi vs TTL brevi
  • 5. Child-Centric o Parent-Centric?  Procedimento: domande a ripetizione per i recod NS-A  Analisi del TLD .uy • Child TTL record NS = 300s e record A = 120s (.uy) • Parent TTL coppia di record NS-A = 2 giorni (root)  Analisi del SLD google.co • Child TTL record NS = 4 giorni (google.com) • Parent TTL record NS = 900s (.co)  La maggioranza dei resolver è Child-Centric
  • 6. In-/out-of-bailiwick  Uso del dominio cachetest.net • TTL record NS = 1 ora e TTL record A = 2 ore per il server autorevole • Inizializzazione di un nuovo server autorevole dopo 9 minuti Out-of-bailiwick: entrambi i server fuori dal dominio La maggioranza dei resolver utilizza il vecchio record A fino al termine del suo TTL In-bailiwick: entrambi i server nel dominio La maggioranza dei resolver utilizza il vecchio record A finché il record NS è valido
  • 7. Feedback dal dominio .uy  Prima: TTL record NS del server autorevole = 5 minuti  Dopo: TTL record NS del server autorevole = 1 giorno  Risultati ottenuti: • Diminuzione dei tempi medi di risposta • Diminuzione della latenza • Riduzione sostanziale del traffico  Dimostrazione che l’utilizzo di TTL più lunghi è generalmente più conveniente
  • 8. Raccomandazioni per gli operatori DNS  Caching più lungo = risposte più veloci, traffico DNS inferiore • Valori TTL a partire da 1 ora • Ideale per TLD e zone generiche  Caching più breve = supporto a modifiche operative • Valori TTL di pochi minuti e a volte secondi • Passare rapidamente da un vecchio server a uno nuovo  Configurare i TTL in modo identico sia nella propria zona che in quella genitore
  • 9. Conclusioni  TTL effettivo spesso diverso da quello configurato • Dipende dalle preferenze dei resolver  È importante controllare i TTL sia nella propria zona che in quella genitore • Se possibile impostare i valori TTL in modo identico  Migliori prestazioni del dominio .uy dopo le modifiche suggerite • Dovute all’impiego di TTL più lunghi, generalmente preferiti  È necessario conoscere i compromessi dovuti ai TTL per buone prestazioni DNS