DNS Resolution Flow

Cosa fa

#

Il Domain Name System (DNS) è il sistema distribuito gerarchico che traduce nomi di dominio leggibili (esempio.com) in indirizzi IP (93.184.216.34). Funziona come una catena di deleghe: nessun singolo server sa tutto, ma ognuno sa a chi chiedere.

TL;DR

#

Flusso di risoluzione:

Browser
  → cache browser
  → cache OS locale
  → resolver ISP / 8.8.8.8
  → Root server       → "per .it vai dai TLD .it"
  → TLD server        → "per example.it vai dal nameserver"
  → Nameserver        → "chat.example.it = 1.2.3.4"
  → resolver          → cacha la risposta con il TTL del record
  → Browser           → "l'IP è 1.2.3.4"

ICANN è l’ente non profit che coordina indirizzi IP e nomi di dominio a livello globale. è l’organizzazione che tiene in ordine la “rubrica mondiale” di Internet, decidendo chi gestisce i vari ‎.com, ‎.org, ecc. e coordinando indirizzi IP e DNS. ICANN (Internet Corporation for Assigned Names and Numbers) è un’organizzazione non a scopo di lucro con sede negli Stati Uniti che:

                        ICANN
                          │
         ┌────────────────┴────────────────┐
         │                                 │
   Root zone (file)                 Politiche / regole
         │
   Root servers (A–M)
         │
   Deleghe TLD (.com, .net, .org, .it, ...)
         │
   Registry di ciascun TLD
         │
   Nameserver autorevoli dei domini
         │
   Resolver → Browser → Utente

Cache — sta dove si fanno le domande, mai alla fonte:

Browser cache          → personale, solo per te
Cache OS locale        → /etc/hosts + cache sistema
Resolver ISP/8.8.8.8   → condivisa tra tutti i suoi client
Nameserver             → fonte autoritativa, non cacha

Analogia — L'Ufficio Postale Gerarchico

#

Immagina di dover consegnare una lettera a "Mario Rossi, Via Roma 15, Firenze, Italia".

Non esiste un unico postino che conosce tutti gli indirizzi del mondo. La lettera passa per una catena:

1. Centro Smistamento Mondiale (Root Server .): "Non so chi è Mario Rossi, ma la lettera va in Italia."
2. Ufficio Postale Nazionale (TLD Server .it): "Non conosco Mario, ma Firenze ha il suo ufficio locale."
3. Ufficio Postale Locale (Authoritative NS): "Mario Rossi? Sì! Via Roma 15. Ecco il suo indirizzo esatto."

Gerarchia DNS e struttura di un nome di dominio

#

                        "."  (Root)
                         │
          ┌──────────────┼──────────────┐
         .com           .org           .it       ← TLD
          │
    ┌─────┴──────┐
tryhackme.com  google.com                        ← Second-Level Domain
    │
    └── store.tryhackme.com                      ← Subdomain

  jupiter.servers.tryhackme.com
     │       │         │    │
     │       │         │    └── TLD
     │       │         └─────── Second-Level Domain (max 63 char)
     │       └───────────────── Subdomain
     └───────────────────────── Subdomain (annidati)

  Lunghezza massima: 253 caratteri
  Caratteri: a-z, 0-9, trattini (no inizio/fine, no consecutivi)

Come Funziona — Il Flusso Completo

#

sequenceDiagram
    participant B as Browser
    participant C as Cache Locale
    participant R as Resolver (ISP)
    participant Root as Root Server (.)
    participant TLD as TLD Server (.com)
    participant NS as Authoritative NS

    B->>C: www.esempio.com?
    C-->>B: cache miss
    B->>R: www.esempio.com?
    R->>Root: www.esempio.com?
    Root-->>R: prova TLD .com →
    R->>TLD: www.esempio.com?
    TLD-->>R: prova ns1.cloudflare.com →
    R->>NS: www.esempio.com?
    NS-->>R: 93.184.216.34 ✓
    R-->>B: 93.184.216.34 (cache TTL)

I Due Tipi di Query

#

graph LR
    subgraph RECURSIVE
        B1[Browser] -->|"Trovami esempio.com"| R1[Resolver]
        R1 -->|fa tutto lui| R1
        R1 -->|risposta finale| B1
    end

    subgraph ITERATIVE
        R2[Resolver] -->|query| Root2[Root]
        Root2 -->|prova TLD| R2
        R2 -->|query| TLD2[TLD]
        TLD2 -->|prova NS| R2
        R2 -->|query| NS2[Auth NS]
        NS2 -->|IP finale| R2
    end

Attori del sistema — location fisica

#

  LOCALE (tua macchina)          RETE (server di qualcun altro)
  ──────────────────────         ──────────────────────────────
  /etc/hosts                     Recursive DNS  (ISP / Google)
  Cache OS RAM                   Root DNS       (Anycast globale)
  /etc/resolv.conf               TLD server     (Verisign, etc.)
                                 Authoritative  (Cloudflare, etc.)

  I primi tre non escono mai dalla tua macchina.
  Dal Recursive DNS in poi sei in rete.

Concetti Chiave: Il TTL

#

TTL — Il Timer della Cache

#

graph LR
    A[Record DNS ricevuto] --> B{TTL scaduto?}
    B -->|No| C[Usa cache]
    B -->|Sì| D[Nuova query DNS]

Best practice operativa quando modifichi un record:

  Giorni prima:   TTL = 86400  (regime normale)
       │
       │  48h prima della modifica
       ▼
  TTL = 300  ◄── i recursive nel mondo svuotano la cache
       │
       │  aspetta 48h (vecchi record con TTL 86400 scadono tutti)
       ▼
  Fai la modifica del record A/CNAME/MX
       │
       │  aspetta max 5 min (nuovo TTL)
       ▼
  Verifica con nslookup che la modifica sia propagata
       │
       ▼
  TTL = 86400  (torna al regime normale)

Scenario Reale — DNS Hijacking

#

Un utente segnala: "Quando vado su intranet.azienda.com mi appare una pagina strana con un login diverso."

sequenceDiagram
    participant U as Utente
    participant M as Malware
    participant F as Fake DNS (attaccante)
    participant C as Clone Site

    M->>U: modifica /etc/resolv.conf
    U->>F: query DNS intranet.azienda.com
    F-->>U: IP falso (clone site)
    U->>C: connessione
    C-->>U: pagina login fake
    U->>C: inserisce credenziali
    C->>F: credenziali rubate ✓

Come investighi:

# Controlla il resolver configurato sul PC sospetto
cat /etc/resolv.conf

# Verifica a quale IP risponde il resolver attuale
dig intranet.azienda.com

# Confronta con il resolver aziendale legittimo
dig @dns-aziendale.com intranet.azienda.com

Scenario Reale — DNS Tunneling (Canale Covert)

#

sequenceDiagram
    participant M as Malware (PC vittima)
    participant FW as Firewall
    participant DNS as DNS Auth (evil-c2.com)

    M->>FW: query DNS dXRlbnRl.evil-c2.com
    Note over M,FW: Dati rubati codificati in base64 nel sottodominio
    FW-->>M: sembra traffico DNS legittimo ✓
    FW->>DNS: forwarda la query
    DNS-->>M: risposta (comandi C2 nascosti)

Come rilevarlo con suricata:

• Sottodomini molto lunghi (> 50 caratteri)
• Alta frequenza di query verso lo stesso dominio
• Entropia alta nel nome del sottodominio

DNS Recursion — vista dal resolver (Wireshark)

#

Quando il resolver esegue la ricorsione, genera una nuova query con un nuovo Transaction ID verso l'upstream. Il dfir catturato sul resolver mostra 4 pacchetti:

Pkt 1: client (172.16.0.8)   → resolver (172.16.0.102)  query    0x8b34  A www.nostarch.com
Pkt 2: resolver (172.16.0.102) → upstream (4.2.2.1)     query    0xf34d  A www.nostarch.com
Pkt 3: upstream (4.2.2.1)    → resolver (172.16.0.102)  risposta 0xf34d  A 72.32.92.4
Pkt 4: resolver (172.16.0.102) → client (172.16.0.8)    risposta 0x8b34  A 72.32.92.4

Il resolver mantiene internamente la mappatura 0xf34d → 0x8b34: sa che quando arriva la risposta con ID 0xf34d deve rispondere al client con l'ID originale 0x8b34.

Come appare in Wireshark — pacchetto DNS

#

Una query DNS è due pacchetti UDP: query e risposta. Porta fissa 53/udp sul server, porta effimera sul client (es. 1060).

Struttura del pacchetto query:

Transaction ID — numero casuale generato dal client. Il server lo copia nella risposta. Stesso meccanismo di DHCP: permette di abbinare risposta a query quando più query sono in volo contemporaneamente su UDP.

Class IN — DNS fu progettato per supportare classi diverse (IN = Internet, CH = Chaosnet, HS = Hesiod). Oggi si usa solo IN. Lo vedi sempre nei pacchetti ma non ha rilevanza pratica — residuo del design degli anni '80.

Flag DNS nella risposta — come leggerli in Wireshark

#

Dalla risposta del resolver (Practical Packet Analysis, cap 9):

Tipi di record — valori numerici nel pacchetto

#

In Wireshark vedi il tipo come numero. I più comuni:

IXFR e AXFR usano TCP invece di UDP — i dati sono troppo grandi per un singolo datagramma. In Wireshark si riconoscono subito perché la porta 53 appare su TCP anziché UDP.

Comandi Diagnostici

#

DNS Zone — cosa si intende

#

La zona è la porzione di spazio DNS che un nameserver gestisce direttamente e di cui è autoritativo.

target.com                ← zona gestita dal nameserver
├── www.target.com
├── mail.target.com
├── vpn.target.com
├── dev.target.com
└── internal.target.com

Il nameserver di target.com conosce tutti questi record perché li ha nel suo zone file — un file di testo con tutti i record DNS del dominio.

La distinzione importante: un resolver (tipo 8.8.8.8) non ha una zona — fa domande per conto dei client. Un authoritative nameserver ha una zona — risponde con dati che possiede direttamente, non che ha cercato per te.

Subdomain Takeover

#

  FASE 1 — configurazione legittima:

  store.tryhackme.com  ──CNAME──►  shops.shopify.com
                                         │
                                   account Shopify attivo ✓

  FASE 2 — abbandono (CNAME rimane, account cancellato):

  store.tryhackme.com  ──CNAME──►  shops.shopify.com
                                         │
                                   NXDOMAIN — nessuno lo possiede

  FASE 3 — attaccante registra shops.shopify.com:

  store.tryhackme.com  ──CNAME──►  shops.shopify.com
                                         │
                                   account ATTACCANTE ← controlla
                                   il contenuto servito

# Rileva CNAME orfani:
nslookup -type=CNAME store.tryhackme.com
# Se il CNAME esiste ma la destinazione dà NXDOMAIN → potenziale takeover

# Servizi noti vulnerabili:
# Shopify, GitHub Pages, Heroku, Fastly, Azure, AWS S3

Collegato a

#

• network — categoria
• dns-records — tutti i tipi di record (A, CNAME, MX, TXT, NS, ecc.)
• nat-concept — il resolver è spesso dietro NAT
• ip-addressing-subnetting — gli IP a cui i record A puntano
• suricata — rileva DNS tunneling e query anomale
• wazuh — monitora le query DNS per comportamenti sospetti