DNSSEC in parole semplici

Modulo 8: Sicurezza e risoluzione dei problemi · Tempo di lettura: 11 minuti

Obiettivo della lezione: Dopo questa lezione sarà in grado di spiegare in parole semplici cosa protegge DNSSEC, come funziona la catena di fiducia e perché può andare storto dopo un trasferimento.

Concetti chiave: DNSSEC, firma (RRSIG), chiave (DNSKEY), record DS, catena di fiducia, resolver validante, SERVFAIL

Il problema: come si fa a sapere che una risposta è autentica?

Nel modulo 1 ha visto che un resolver pone una serie di domande: alla root, al server TLD e al nameserver autoritativo. La risposta che torna viene creduta e messa in cache. Ma il DNS normale non controlla se quella risposta proviene davvero dal nameserver giusto. Un malintenzionato che riesce a inviare una risposta falsa prima che arrivi quella vera può far credere a un resolver che example.com si trovi su 203.0.113.66 invece che su 192.0.2.10. Questo si chiama cache poisoning: la cache viene "avvelenata" e chiunque usi quel resolver finisce sul server sbagliato.

DNSSEC (DNS Security Extensions) risolve questo problema firmando le risposte. Il resolver può così verificare se una risposta è autentica e non è stata modificata lungo il percorso.

Cosa fa e cosa non fa DNSSEC

Questo è l'aspetto più importante da ricordare:

Una firma funziona come un sigillo su una busta: chiunque può leggere la lettera, ma si vede subito se qualcuno l'ha aperta.

I tre elementi

DNSSEC aggiunge alcuni tipi di record. Non deve crearli Lei stesso (lo fa il Suo gestore DNS o il pannello), ma li incontrerà:

• DNSKEY: la chiave pubblica della zona. Con questa chiunque può verificare le firme.
• RRSIG: la firma apposta su un gruppo di record. Ogni risposta A, MX o TXT riceve un RRSIG. Una firma ha una data di inizio e una di fine: la zona deve quindi essere rifirmata regolarmente.
• DS (Delegation Signer): una breve "impronta digitale" della chiave della Sua zona. Questa non si trova nella Sua zona, ma presso il genitore: per example.com quindi presso il registro di .com (Verisign), per un dominio .nl presso SIDN (il registro di .nl nei Paesi Bassi).

Ecco come appare una risposta firmata (abbreviata):

$ dig example.com A +dnssec +noall +answer
example.com.  3600  IN  A      192.0.2.10
example.com.  3600  IN  RRSIG  A 13 2 3600 20261119000000 20261029000000 30794 example.com. s7yJ5o...

Nell'RRSIG si vedono, tra l'altro, l'algoritmo (13 = ECDSA P-256 con SHA-256), la data di scadenza (19 novembre 2026), la data di inizio e il numero della chiave (30794).

La catena di fiducia

Perché il DS si trova presso il genitore? Perché una chiave nella Sua stessa zona non dimostra nulla: un malintenzionato potrebbe anche inviare una propria chiave. Per questo il controllo procede dall'alto verso il basso:

1. Il resolver si fida della chiave della root. Questa è integrata in ogni resolver validante (il trust anchor).
2. La root ha un DS per .com, firmato con la chiave della root. Così il resolver sa quale chiave dovrebbe avere .com.
3. La zona .com ha un DS per example.com, firmato con la chiave di .com.
4. La zona example.com ha una DNSKEY che corrisponde a quel DS, e con questa si possono verificare tutti gli RRSIG.

Ogni anello dimostra il successivo. Se un anello si spezza, l'intera catena diventa inaffidabile.

Un resolver validante (la maggior parte dei grandi resolver pubblici, e sempre più provider) percorre questa catena. Se è corretta, ottiene la risposta. Se non è corretta, il resolver non restituisce una risposta, ma lo stato di errore SERVFAIL. Per il visitatore il sito sembra allora semplicemente "non esistere", mentre i Suoi record potrebbero essere perfettamente a posto.

Può vederlo Lei stesso con un dominio che è stato danneggiato appositamente:

$ dig dnssec-failed.org A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

Con +cd ("checking disabled") chiede al resolver di saltare il controllo. Se a quel punto ottiene comunque una risposta, sa con certezza che il problema dipende da DNSSEC:

$ dig +cd dnssec-failed.org A @1.1.1.1 +short
96.99.227.255

Un dominio senza DNSSEC (nessun DS presso il genitore) non restituisce SERVFAIL: semplicemente non è firmato e viene lasciato passare come "non protetto".

Dove si verificano gli errori: trasferimenti e cambi di chiave

DNSSEC in sé quasi non si rompe mai. Il problema sorge quando il DS presso il registro non corrisponde più alla chiave nella zona. Questo accade soprattutto:

• In caso di trasferimento dei nameserver o del fornitore DNS. Il nuovo fornitore firma con una propria chiave, ma presso il registro è ancora presente il DS del vecchio fornitore. Conseguenza: SERVFAIL per chiunque usi un resolver validante. Questo è l'errore classico dopo un trasferimento.
• In caso di cambio di chiave in cui il nuovo DS non è stato inviato (in tempo) al registro.
• Quando le firme scadono, perché la zona non viene più rifirmata.

L'ordine sicuro da seguire in caso di trasferimento è quindi:

1. Rimuova il DS presso il registro (oppure faccia fornire dal nuovo gestore un DS che aggiungerà).
2. Attenda che la TTL del vecchio DS sia trascorsa.
3. Cambi i nameserver.
4. Attivi DNSSEC presso il nuovo gestore e faccia inserire il nuovo DS presso il registro.

Molti registrar e pannelli oggi gestiscono questo automaticamente, purché dominio e DNS si trovino presso lo stesso fornitore. Se si trovano presso fornitori diversi, deve trasferire il DS Lei stesso.

Verificare da sé: DNSViz, Zonemaster e internet.nl

Non deve ripercorrere la catena con dig. Esistono strumenti gratuiti che lo fanno per Lei e mostrano il risultato.

DNSViz (https://dnsviz.net/) disegna l'intera catena in un'immagine. Ecco come usarlo:

1. Nella pagina iniziale digiti il nome di dominio nel campo di ricerca (solo il nome, senza https:// e senza www) e clicchi su Go.
2. DNSViz mostra l'ultima analisi. Se è datata, o se ha appena modificato qualcosa, clicchi su Update now. Dopo qualche secondo vedrà l'immagine.
3. Legga l'immagine dall'alto verso il basso: in cima la root (.), sotto il TLD (per esempio nl), in basso il Suo dominio. Ogni zona è un riquadro.

Cosa vede nell'immagine:

La catena si segue così: il DS (presso il genitore) punta verso la DNSKEY (nella Sua zona), e quella DNSKEY appone con un RRSIG la propria firma sui record. È esattamente la catena vista in questa lezione, ma disegnata.

I colori indicano se tutto è corretto:

• Blu: sicuro (secure). La catena procede ininterrotta dalla root fino a questo elemento.
• Nero: non firmato (insecure). Non c'è un DS, quindi non c'è nulla da verificare. Non è un errore, il dominio semplicemente non usa DNSSEC.
• Rosso: danneggiato (bogus). Un DS non corrisponde a una chiave, oppure una firma non è corretta. Un resolver validante restituisce allora SERVFAIL.
• Viola (su una firma): la firma è scaduta o non è ancora valida. La zona non viene più rifirmata.
• Giallo: un avviso, per esempio un nameserver che non risponde correttamente, o un algoritmo che lo strumento non riconosce.
• Grigio e tratteggiato: si fa riferimento a una chiave che non esiste. Se vede una DNSKEY tratteggiata sotto un DS, presso il genitore è ancora presente un DS di una vecchia chiave: l'errore classico dopo un trasferimento.

Accanto a un elemento può comparire un triangolino (avviso) o un simbolo di errore rotondo. Vi passi sopra con il mouse, oppure guardi nell'elenco sotto l'immagine: lì è spiegato a parole cosa non va.

Provi con sidn.nl (tutto blu) e con dnssec-failed.org (rosso, con una chiave tratteggiata sotto il DS).

Altri strumenti che osservano la stessa cosa da un'altra angolazione:

• Zonemaster (https://zonemaster.net/): controlla l'intera zona come farebbe un registro, incluso DNSSEC. Il risultato è un elenco con verde (corretto), arancione (avviso) e rosso (errore).
• internet.nl (https://internet.nl/): il test del sito web e della posta elettronica mostra, tra l'altro, se DNSSEC per il Suo dominio e per i Suoi server di posta è in ordine, con spunte verdi o croci rosse.
• Verisign DNSSEC Debugger (https://dnssec-debugger.verisignlabs.com/): percorre la catena passo dopo passo e mette a ogni passaggio una spunta verde o una croce rossa. Utile se sta cercando un errore specifico.

Li usi dopo ogni modifica a DNSSEC, e soprattutto prima e dopo un trasferimento. Lasci che lo strumento rianalizzi con calma: anche questi strumenti lavorano con cache e TTL.

Nella pratica: come appare in un pannello

In Mio WebOké attiva DNSSEC per un dominio sotto DNSSEC/DANE; il pannello crea le chiavi e invia il DS al registro. In DirectAdmin e presso fornitori esterni come Cloudflare la voce si chiama di solito "Abilita DNSSEC"; Cloudflare Le mostra quindi un record DS che deve inserire Lei stesso presso il Suo registrar. Altri pannelli funzionano in modo simile: c'è sempre un passaggio "crea le chiavi" (presso il fornitore DNS) e un passaggio "DS presso il registro" (presso il registrar).

Riepilogo

• DNSSEC firma le risposte DNS in modo che un resolver possa verificare che siano autentiche. Non cripta nulla.
• DNSKEY è la chiave, RRSIG la firma, DS l'impronta digitale presso il genitore.
• Il controllo procede come una catena dalla root fino al Suo dominio. Se un anello si spezza, un resolver validante restituisce SERVFAIL.
• Quasi tutti i problemi nascono perché il DS presso il registro non corrisponde più, spesso dopo un trasferimento.
• Con dig +cd vede se un problema dipende da DNSSEC.
• DNSViz disegna la catena: blu è sicuro, nero è non firmato, rosso è danneggiato. Zonemaster, internet.nl e il Verisign DNSSEC Debugger sono buoni pareri alternativi.

Quiz

Esercizio

Esercizio Z8.1: Vedere DNSSEC. Scopra quale di due domini ha DNSSEC in ordine e quale è stato danneggiato apposta: sidn.nl e dnssec-failed.org. Richieda per entrambi il record DS e il record A tramite un resolver validante (per esempio 1.1.1.1 o 9.9.9.9), con dig o uno strumento online. Compili: il numero della chiave (key tag, il primo numero) del DS di sidn.nl, e lo stato che ottiene per dnssec-failed.org.

Esercizio Z8.1b: Leggere DNSViz. Analizzi nlnetlabs.nl in DNSViz (https://dnsviz.net/, digiti il nome e clicchi su Go; clicchi su Update now se l'analisi è datata). Legga l'immagine e compili: (1) lo stato di nlnetlabs.nl (sicuro, non firmato o danneggiato), (2) il numero dell'algoritmo dei record DNSKEY (indicato in ogni ovale come alg=), (3) quanti ovali DNSKEY sono presenti nella zona di nlnetlabs.nl, (4) il numero della chiave (id=) della DNSKEY grigia piena verso cui punta il DS, e (5) lo stato che DNSViz indica per dnssec-failed.org. Il controllo richiede gli stessi dati in tempo reale.

Esercizio O8.1: Valutare tre zone dimostrative DNSSEC. Abbiamo predisposto tre zone dimostrative: signed-demo.dnspractice.com (catena corretta), broken-demo.dnspractice.com (danneggiata apposta) e unsigned-demo.dnspractice.com (non firmata). Scopra per ogni zona se è sicura, danneggiata o non firmata, per esempio con DNSViz o con dig +dnssec (osservi il flag AD, e in caso di SERVFAIL provi anche +cd). Scelga qui sotto la Sua risposta per ciascuna zona.

Per saperne di più

Questi articoli descrivono i passaggi nei pannelli di WebOké; presso altri fornitori i pulsanti hanno nomi diversi.

• Guida WebOké 5.8: DNSSEC e DANE
• Che cos'è il DNSSEC?
• Attivazione di DNSSEC
• Il sito web o l'indirizzo e-mail non funziona dopo un trasloco o una modifica DNS: verifichi il Suo dominio