Verifica DNSSEC

La falla che DNSSEC chiude

Quando il tuo computer chiede «qual è l’indirizzo di example.com?», la risposta torna in un piccolo pacchetto senza protezione. Il DNS originale non dà a chi riceve alcun modo di verificare chi l’ha scritta. Qualcuno che si trova tra te e il name server, o che infila una risposta falsa nella memoria di un resolver, può mandare visitatori ed e-mail verso una macchina a sua scelta.

DNSSEC aggiunge le firme. Il titolare di una zona firma ogni insieme di record con una chiave privata e pubblica la chiave pubblica corrispondente nella zona come record DNSKEY. Un resolver che riceve una risposta riceve anche la sua firma (RRSIG) e può verificare che i record siano esattamente quelli pubblicati dal titolare. DNSSEC non cifra nulla e non nasconde quali nomi cerchi. Si limita a dimostrare che una risposta è autentica.

Una catena di impronte

Una chiave pubblica che sta nello stesso posto dei dati non dimostra molto, perché un falsario potrebbe sostituire entrambi. Così ogni zona chiede alla zona superiore di garantire per lei. Il genitore pubblica un record DS, una breve impronta (digest) della chiave del figlio, e firma quel record con la propria chiave. La chiave del genitore è garantita allo stesso modo dal suo genitore, e così via fino alla zona radice. La chiave radice è l’unica cosa che un resolver deve conoscere in anticipo ed è inclusa nel software del resolver.

Per example.com il percorso è questo: chiave radice, DS di com nella radice, chiavi di com, DS di example.com in com, chiavi di example.com, record firmati. Basta un anello mancante o sbagliato e la prova fallisce.

Il record DS è la parte che vive fuori dal tuo provider DNS. Viene consegnato al registro tramite il tuo registrar e la maggior parte dei guasti nasce da questa separazione.

Cosa fa questa verifica

Per la radice, la zona di primo livello e ogni zona fino al tuo dominio, il nostro server legge i record DS nel genitore e i record DNSKEY della zona. Li legge tramite resolver pubblici con la validazione disattivata (il flag «checking disabled»), così può ispezionare anche una zona rotta. Per ogni chiave calcola il key tag e per ogni DS ricalcola il digest dalla chiave con la stessa funzione di hash (RFC 4034), poi confronta i due byte per byte.

Poi chiede a tre resolver pubblici che validano (Cloudflare, Google e Quad9) il record SOA del dominio, questa volta con la validazione attiva. Un resolver che ha validato la risposta imposta il flag AD («authenticated data»). Uno che ha trovato un errore risponde SERVFAIL. Il nostro server confronta da sé le impronte, ma non verifica le firme. Quel verdetto spetta ai resolver.

La verifica segnala anche gli algoritmi ritirati o deboli (RSA/MD5, DSA, RSA/SHA-1, digest SHA-1 in un DS), un DS rimasto da una vecchia chiave, le firme a meno di tre giorni dalla scadenza e se la zona usa NSEC o NSEC3 per dimostrare che un nome non esiste.

Riparare una catena rotta

Una catena rotta è peggio di nessun DNSSEC, perché i resolver che validano si rifiutano di rispondere. Di solito va così: il dominio è passato a un nuovo provider DNS, il vecchio record DS è rimasto presso il registrar e ora punta a una chiave che non esiste più.

1. Per tornare online in fretta, elimina il record DS presso il registrar. Il dominio diventa non firmato e funziona per tutti appena scadono le cache, di solito entro un giorno.
2. Per mantenere DNSSEC, apri la pagina DNSSEC del tuo provider DNS attuale, copia il record DS che mostra (key tag, algoritmo, tipo di digest, digest) e inseriscilo presso il registrar al posto di quello vecchio.
3. Prima del prossimo trasloco, rimuovi prima il record DS, aspetta un giorno, cambia i name server, poi firma e pubblica il nuovo DS.

Nel caso «configurato a metà», o completi il lavoro pubblicando il record DS o disattivi la firma presso il provider DNS.