Extended Summary of "DNS Observatory: the Big Picture of the DNS"

1. EXTENDED SUMMARY DI «DNS OBSERVATORY: THE
BIG PICTURE OF THE DNS»
Pawel Foremski, Oliver Gasser, and Giovane C. M. Moura. 2019. DNS Observatory: The Big Picture
of the DNS. In Internet Measurement Conference (IMC ’19), October 21-23, 2019, Amsterdam,
Netherlands, ACM, New York, NY, USA, 14 pages. https://doi.org/10.1145/3355369.3355566
Laureanda:
Barbara Dubaz
Relatore:
Prof. Alberto Bartoli
Dipartimento di Ingegneria e Architettura
Corso di Studi in Ingegneria Elettronica e Informatica
Anno accademico 2021-2022

2. INTRODUZIONE
DNS Observatory: piattaforma creata per
l’analisi di stream di query DNS tra
centinaia di recursive resolver e
authoritative nameservers, entrambi
distribuiti in tutto il mondo, tra gennaio e
aprile 2019. Sono state totalizzate 1.6
bilioni di transazioni DNS.

3. ACQUISIZIONE & ELABORAZIONE DATI
Il processo di acquisizione ed elaborazione dei dati è composto dai seguenti passi:
1. Acquisizione dei pacchetti diretti ai nameserver e le rispettive risposte;
2. Eliminazione delle informazioni non rilevanti;
3. Creazione di liste Top-K elencate in base ad una chiave;
4. Creazione di file temporali e aggregamento in file da 24h.

4. ANALISI DEI DATI:
DISTRIBUZIONE DEL TRAFFICO
I Top-100K nameserver gestiscono ~95%
del traffico globale.
Il 20.7% delle risposte sono NXDOMAIN.
~1000 nameserver gestiscono oltre il
50% del traffico globale.
Per i Top-100K FQDN,
bastano i primi 10K per
vedere il 18.6% del traffico.
Per i Top-100K eSLD, i
primi 100 sono soggetti a
un maggior numero di query
in confronto agli altri.

5. ANALISI DEI DATI:
SISTEMI AUTONOMI (SA)
Osservando la tabella risultante
dall’aggregazione dei Top-100K
nameserver in base
all’organizzazione che gestisce il
SA, si ha che:
▪I prefissi IP delle Top-10
organizzazioni ricevono oltre il
50% delle query mondiali
(51.5%);
▪Servizi come DNS Hosting e
Virtual Private Server aumentano
ritardi e numero di hop;
▪I Content Delivery Network, come
CLOUDFLARE e AKAMAI,
ottimizzano tempi di risposta e
hop count.

6. ANALISI DEI DATI:
TIPI DI QUERY
Nella seguente tabella vengono elencati i Top-10 tipi di query più utilizzati
globalmente.
La netta differenza nelle richieste A/AAAA di risposta NXDOMAIN suggerisce
l’utilizzo delle richieste di tipo A per il DNS scanning e altre attività automatizzate
(come attacchi Pseudo-Random SubDomain)

7. ANALISI DEI
DATI:
RITARDI DI
RISPOSTA
Analizzando i Top-100K nameserver, oltre il 70% hanno
ritardi compresi tra 35-350ms, corrispondendo ai nameserver
posti a grande distanza dai resolver.
I nameserver più popolari sono i più veloci: dei Top-25K
nameserver rappresentati nella figura (b), i Top-10K
gestiscono oltre la metà del traffico mondiale con ritardi e
hop count inferiori.
Il rapporto tra il numero di hop e i ritardi di risposta per i root
nameserver e i gTLD nameserver è rappresentato in (c) e (d).

8. QNAME MINIMIZATION
Il QNAME (Query NAME)
minimization è una tecnica
implementata dai resolver
per migliorare la privacy
dei dati degli utenti.
I resolver che implementano
il QNAME min. inviano ~18K
query ai root nameserver e
~4K ai TLD nameserver,
valori piccolissimi in
confronto al totale e che non
influisce al traffico.
Client
Resolver
Root Nameserver
TLD Nameserver [.it]
SLD Nameserver
www.esempio.it ?
.it ?
esempio.it ?
www.esempio.it ?
1
2
3
4
5
6
7
8
Chiedi TLD
Chiedi SLD
Risposta DNS
Risposta DNS

9. TIME TO LIVE (TTL) DNS
Una variazione del TTL causa una variazione del numero di query:
• TTL più piccoli => Incremento del numero di query
• TTL più grandi => In 17 casi si ha una diminuzione del numero di query, in 34 un incremento
causato da richieste di risposta NXDOMAIN o improvvisa popolarità dei domini.
La variazione dei TTL può essere considerata un indice di cambiamenti nell’infrastruttura DNS.

10. HAPPY EYEBALLS E NEGATIVE CACHING TTL
Happy Eyeballs è un algoritmo utilizzato per minimizzare i
ritardi causati da una risposta IPv6 negativa.
Il negative caching TTL è il periodo in cui viene salvata nella
DNS cache una risposta negativa (NXDOMAIN, NoData…)
 Negative caching TTL molto inferiori rispetto ai TTL regolari causano un
aumento del numero di query a risposta vuota.
Alcune soluzioni proposte sono:
1. Aggiungere un tipo di query che comprenda sia A che
AAAA;
2. Separare il negative caching TTL per NXDOMAIN e
NoData;
3. Cambiare i valori dei negative caching TTL con dei valori più
in linea.
Resolver
Nameserver
A
AAAA
2
1

11. VALIDITÀ DEI DATI
Il numero di resolver utilizzati è ristretto
rispetto al numero totale disponibile a
causa di limitazioni della larghezza di
banda per l’elaborazione dati.
Nella figura (a) è rappresentato
l’andamento del numero di nameserver
interrogati in 1h.
▪ Il numero dei nameserver mancanti
corrisponde a quelli meno popolari.
Nella figura (b) si vede che basta il 5%
dei resolver per vedere il 95% dei
Top-10K nameserver più popolari.