DNSSEC — Domain Name System Security Extensions

Mappa Globale

#

Cosa fa

#

DNSSEC aggiunge autenticazione crittografica alle risposte DNS. Ogni record viene firmato digitalmente dal server autoritativo, e il resolver verifica la firma risalendo una catena di fiducia fino a una chiave hardcoded localmente (Trust Anchor). Previene il DNS cache poisoning rendendo verificabile l'autenticità di ogni risposta.

TL;DR

#

Il DNS base non autentica le risposte: chiunque arrivi prima col pacchetto giusto può inserire IP falsi nella cache — DNS cache poisoning. DNSSEC aggiunge firme digitali (RRSIG) a ogni record. Il resolver verifica le firme risalendo la chain of trust: Autoritativo → TLD → Root → Trust Anchor (hardcoded localmente). Se una firma non torna, la risposta viene scartata.

DNSSEC autentica — non cifra. Il traffico DNS rimane in chiaro. Per cifrarlo: DoH (DNS over HTTPS) o DoT (DNS over TLS).

Il problema: DNS Cache Poisoning

#

Il DNS è progettato per essere veloce, non sicuro. Una risposta DNS non porta nessuna prova di autenticità: il resolver accetta la prima risposta che arriva con il Transaction ID corretto.

Un attaccante remoto può inondare il resolver di risposte UDP false indovinando il Transaction ID (race condition). Se arriva prima della risposta reale, il resolver mette l'IP falso in cache. Da quel momento tutti i client che usano quel resolver vengono dirottati.

sequenceDiagram
    autonumber
    participant F as Franco (Client)
    participant RES as Recursive Resolver
    participant AUTH as Autoritativo (DNS reale)
    participant C as Charlie (Remoto)

    Note over F,AUTH: Cache Miss — il resolver va upstream

    F->>RES: "Che IP ha google.com?"
    RES->>AUTH: Query UDP #4521 — google.com?

    Note over C: Charlie monitora il traffico DNS pubblico.
    Note over C: Indovina il Transaction ID: #4521

    C-->>RES: Risposta falsa #4521 — google.com = 6.6.6.6
    C-->>RES: Risposta falsa #4521 — flooding...
    AUTH-->>RES: Risposta reale #4521 — google.com = 142.250.x.x

    Note over RES: La risposta di Charlie è arrivata prima.
    Note over RES: DNSSEC assente — nessuna firma da verificare.

    RES->>RES: CACHE — google.com → 6.6.6.6 (TTL ore)
    RES-->>F: google.com = 6.6.6.6 (avvelenato)

    Note over RES: Tutti i client successivi ricevono 6.6.6.6 dalla cache.

L'attaccante non intercetta il traffico — agisce da remoto con flooding UDP. Non è necessaria una posizione MITM.

Analogia con ARP poisoning:

• ARP poisoning: inserisce IP→MAC falsi nella cache ARP degli host → reindirizza traffico locale
• DNS poisoning: inserisce hostname→IP falsi nella cache del resolver → reindirizza traffico internet

La soluzione: DNSSEC e RRSIG

#

DNSSEC aggiunge un RRSIG (Resource Record Signature) a ogni record DNS. L'RRSIG è una firma digitale creata dal server autoritativo con la propria chiave privata.

Il resolver, ricevuta una risposta, recupera la DNSKEY (chiave pubblica del server autoritativo) e verifica matematicamente la firma. Se la firma non corrisponde, il record è stato manomesso e viene scartato.

sequenceDiagram
    participant R as Recursive Resolver
    participant A as DNS Autoritativo

    R->>A: "Dammi l'IP di google.com"
    A->>R: IP = 142.250.x.x + RRSIG (firma con chiave privata) + DNSKEY (chiave pubblica)

    Note over R: Verifica la firma RRSIG con la DNSKEY

    alt Firma valida
        R->>R: Record autentico — salva in cache
    else Firma non valida
        R->>R: DNS poisoning rilevato — scarta la risposta
    end

Record coinvolti:

• RRSIG — firma digitale del record, creata con la chiave privata del server
• DNSKEY — chiave pubblica del server, usata dal resolver per verificare le firme
• DS (Delegation Signer) — hash della chiave pubblica del figlio, conservato dal padre

Chain of Trust — come funziona la fiducia

#

Il resolver non può conoscere le chiavi pubbliche di tutti i domini. Usa invece una catena di fiducia gerarchica: ogni livello firma la chiave del livello sotto, e la catena si chiude su una chiave hardcoded localmente — il Trust Anchor.

Regola del DS Record: il Record DS (hash della chiave del figlio) è sempre conservato nel database del padre, mai del figlio. Questo impedisce a chiunque di garantire per se stesso.

Fase di Setup (costruzione dell'albero — avviene raramente)

#

Autoritativo genera chiave → consegna DS al TLD → TLD lo firma e conserva
TLD genera chiave          → consegna DS al Root → Root lo firma e conserva
Root ha la chiave root     → Trust Anchor hardcoded nei resolver di tutto il mondo

Fase di Risoluzione (on-demand, ad ogni cache miss)

#

Fase A — Raccolta via rete (top-down): Il resolver chiede a Root, poi a TLD, poi all'Autoritativo. Raccoglie IP, chiavi pubbliche e firme senza ancora fidarsi di nulla.

Fase B — Validazione offline (bottom-up): Avendo tutto in RAM, il resolver chiude la rete e verifica a ritroso. La validazione è deliberatamente offline: se avvenisse online, un intercettatore potrebbe sostituire le chiavi durante la verifica stessa.

sequenceDiagram
    autonumber
    participant RES as Recursive Resolver
    participant AUTH as Autoritativo
    participant TLD as Server TLD
    participant ROOT as Root Server
    participant TA as Trust Anchor (hardcoded)

    Note over RES,AUTH: Fase A — raccolta
    RES->>AUTH: "IP di google.com?"
    AUTH-->>RES: IP + RRSIG + DNSKEY (autoritativo)
    RES->>TLD: "Verifica chiave autoritativo"
    TLD-->>RES: DS + RRSIG + DNSKEY (TLD)
    RES->>ROOT: "Verifica chiave TLD"
    ROOT-->>RES: DS + RRSIG + DNSKEY (Root)

    Note over RES: Fase B — validazione offline

    RES->>RES: Verifica firma TLD su DS dell'autoritativo
    RES->>RES: Verifica firma Root su DS del TLD
    RES->>TA: Confronta DNSKEY Root ricevuta con Trust Anchor locale
    TA-->>RES: MATCH — catena valida

    Note over RES: Fiducia a cascata: Root → TLD → Autoritativo → IP accettato

Trust Anchor

#

Il Trust Anchor è la chiave pubblica della Root Zone (.) hardcoded nel software del resolver — non arriva dalla rete. È il punto di partenza assoluto della catena di fiducia: il resolver non deve fidarsi di nessuno in rete per ottenerla, ce l'ha già.

Gestita da ICANN con una cerimonia fisica ad alta sicurezza ("Root Key Signing Ceremony"). Esiste una sola chiave crittografica per tutta la Root Zone globale.

Parallelo con TLS: è identico alle root CA hardcoded nel browser. Il browser non chiede in rete "qual è la chiave di DigiCert?" — ce l'ha già nel bundle del sistema operativo.

Cache Poisoning vs MITM su DNSSEC — due attacchi diversi

#

MITM su DNSSEC: un intercettatore in posizione di rete potrebbe provare a forgiare l'intera catena crittografica — chiavi false per ogni livello. Viene sventato dal Trust Anchor: la chiave root ricevuta dalla rete non coincide con quella hardcoded localmente.

sequenceDiagram
    autonumber
    participant RES as Recursive Resolver
    participant C as Charlie (MITM)
    participant TA as Trust Anchor (hardcoded)

    Note over RES,C: Charlie intercetta e forgia l'intera catena

    RES->>C: Richiesta IP per u-random.dev
    C-->>RES: IP 6.6.6.6 + Firma falsa + DNSKEY falsa (autoritativo)
    RES->>C: "Verifica chiave autoritativo"
    C-->>RES: DS falso + Firma falsa + DNSKEY falsa (TLD)
    RES->>C: "Verifica chiave TLD"
    C-->>RES: DS falso + Firma falsa + DNSKEY falsa (Root)

    Note over C: Charlie si è autoproclamato Root. Tutto firmato da sé.

    RES->>TA: Confronta DNSKEY Root (falsa) con Trust Anchor locale
    TA-->>RES: MISMATCH — la chiave non coincide con quella di fabbrica

    Note over RES: Attacco MITM rilevato. Catena scartata. IP 6.6.6.6 bloccato.

NSEC e NSEC3 — Authenticated Denial of Existence

#

Quando un client chiede "esiste pippo.google.com?" e il record non esiste, il DNS normalmente risponde NXDOMAIN (Non-Existent Domain). Ma senza DNSSEC, anche questa risposta negativa potrebbe essere falsificata: un attaccante potrebbe far credere che un record esistente non esista.

DNSSEC risolve questo con i record NSEC e NSEC3: permettono al server di dimostrare crittograficamente che un nome non esiste.

NSEC (Next Secure): lista i record esistenti in ordine alfabetico e firma l'intervallo. "Non esiste nulla tra mail.google.com e www.google.com" - quindi pippo.google.com non esiste.

Problema: NSEC permette la zone enumeration - un attaccante puo' interrogare ricorsivamente tutti i record NSEC e ricostruire l'intera lista dei nomi DNS di una zona. E' equivalente a pubblicare tutta la rubrica del dominio.

NSEC3 (Next Secure version 3): risolve il problema della zone enumeration usando l'hash dei nomi invece dei nomi in chiaro. L'attaccante vede solo "non esiste nulla tra SHA256(nome_A) e SHA256(nome_B)" - non puo' ricavare i nomi originali senza brute force.

Dev Parallel

#

Dev parallel: DNSSEC e' identico alla PKI che verifica i JWT in un'API REST. Il token JWT e' firmato dal server con chiave privata (come l'RRSIG e' firmato dal server autoritativo). Il client verifica la firma con la chiave pubblica (come il resolver verifica l'RRSIG con la DNSKEY). Il Trust Anchor DNSSEC e' il JWK Set endpoint hardcoded nella configurazione del tuo API gateway - quella chiave pubblica di riferimento non arriva dalla rete, e' gia' configurata localmente per evitare che un attaccante la sostituisca.

Cache e performance

#

La verifica crittografica DNSSEC è costosa. Ma avviene una sola volta per TTL: il primo client che fa una query dopo un cache miss fa tutto il lavoro. Il risultato validato viene messo in cache e tutti i client successivi ricevono la risposta già verificata — zero overhead crittografico.

Per questo il DNS poisoning sulla cache del Recursive Resolver è devastante: la cache è condivisa tra tutti i worker (vedi worker-pool) — avvelenare un record significa avvelenarlo per tutti i client serviti da quel resolver.

Scenario Reale

#

Un resolver aziendale inizia a servire IP sbagliati per un dominio di un partner. I client vengono dirottati su un sito malevolo. Analisi: DNSSEC disabilitato sul dominio del partner (nessun DS Record nel TLD). Un attaccante ha sfruttato la finestra di cache miss per fare flooding UDP e avvelenare la cache. Fix: abilitare DNSSEC sul dominio del partner + configurare il resolver per richiedere DNSSEC (dnssec-mode: require in unbound).

Risorse

#

• DNSSEC — RFC 4033/4034/4035 — specifica tecnica completa
• Verisign DNSSEC Debugger — visualizza la chain of trust di un dominio

Collegato a

#

• crypto — firme digitali, PKI, chain of trust