DNSSEC | Skull's blog

Posts Tagged ‘DNSSEC’

OK, this is ridiculous…

Posted in Informatica e reti, tagged DANE, DNSSEC on 16 February 2014| Leave a Comment »

DNSSEC for dummies (now auth!)

Posted in Informatica e reti, tagged DNSSEC on 17 August 2011| Leave a Comment »

Dopo essermi occupato –oramai parecchio tempo fa– di come configurare BIND per fungere da resolver validando DNSSEC, mi prendo finalmente il tempo per buttare giù le 4 righe relative a come dotare la vostra zona di DNSSEC.

Per questa ricetta abbiamo bisogno di:

un dominio appartenente ad un TLD già dotato di zona firmata e che accetti la submission dei record DS per i domini erogati (org, net, com, biz vanno bene)
un registrar che vi dia la possibilità di sottomettere il vostro record DS affinché vada nella zona del TLD
un nameserver sotto il vostro controllo, che esegua preferibilmente BIND 9.7 o superiore (per lo/gli slave il requisito è semplicemente l’esecuzione di un DNS con supporto ai tipi di record necessari a DNSSEC)
un tab di un browser (oltre a quello dove è aperta questa pagina) puntato sulla RFC4034, in modo da poter consultare alla bisogna le definizioni relative ai vari Resource Records utilizzati da DNSSEC

Metto le mani avanti su un fronte: DNSSEC non è banale e farete quasi certamente una lunga sequela di errori nella gestione della vostra prima zona firmata. Questi errori potrebbero rendere la vostra zona non valida e il vostro dominio irraggiungibile per chi esegua validazione DNSSEC. Ergo, evitate di fare esperimenti con un dominio in produzione, e procuratevi invece un dominio con cui spippolare in tranquillità…

Supponendo che il dominio lo abbiate già registrato con il registrar di cui sopra (se lo avevate già registrato altrove, richiedete il trasferimento ad altro registrar o prendete un nuovo dominio), procediamo dapprima al configurare il nostro DNS master, definendo la nostra zona in modo simile a questo:

zone "mydomain.tld" {
        type master;
        key-directory "/etc/bind/dnssec-keys";
        update-policy local;
        auto-dnssec maintain;
        file "zones/mydomain.tld";
        allow-query { any; };
        notify yes;
        allow-transfer {
                "slave1";
                "slave2";
        };
};

Se avete perplessità sulle definizioni qui utilizzate, riferitevi ovviamente alla documentazione di BIND.

Rispetto ad una configurazione “tradizionale“, comunque, avrete quantomeno notato un paio di definizioni in più:

key-directory: poichè lasceremo che della firma della zona si occupi direttamente BIND, dobbiamo indicargli dove stanno le chiavi private necessarie
auto-dnssec: come appena detto, lasceremo che il signing della zona sia eseguito da BIND. Con la direttiva “maintain”, BIND sarà in grado di occuparsi anche del rollover delle chiavi quando necessario (questo aspetto lo vedremo in altra sede…)

A questo punto procediamo alla creazione della zona dns iniziale, depositandola nel file sopra definito, come faremmo con qualsiasi zona DNS. Poiché però BIND dovrà occuparsi anche della manipolazione dei contenuti della zona stessa dobbiamo garantire che sia il file di zona che la directory ove esso è depositato siano scrivibili da parte di BIND. Diamo un bel “rndc reload” e verifichiamo dai log di non aver commesso errori.

Il passo successivo consiste nel generare le chiavi per la nostra zona. Saprete certamente (se non lo sapete, consiglio di cercare un po’ di paper e iniziare a studiare…) che per ciascuna zona DNSSEC prevede (in realtà consiglia) l’uso di due chiavi distinte: la KSK e la ZSK, con la prima che viene utilizzata per firmare la seconda e la seconda che viene usata per firmare i dati di zona (non a caso si chiamano Key-Signing-Key e Zone-Signing-Key…).

Procediamo dapprima con la creazione della KSK, attraverso il comando:

dnssec-keygen -f KSK -K /etc/bind/dnssec-keys mydomain.tld

La generazione della chiave richiederà un certo tempo, dato che per la KSK il default si attesta a 2048bit: andate tranquillamente a bervi un caffè. Se il vostro DNS poi non è particolarmente dotato in quanto a CPU, ci sta anche una pizza…

Quando il comando avrà terminato, comunque, troverete nella directory indicata una coppia di file, contenenti rispettivamente la chiave pubblica e privata:

-rw-r--r-- 1 skull skull  607 Aug 17 18:45 Kmydomain.tld.+005+62878.key
-rw------- 1 skull skull 1774 Aug 17 18:45 Kmydomain.tld.+005+62878.private

Attenzione al fatto che, avendo delegato la firma della nostra zona a BIND, questi avrà necessità di accedere in lettura a entrambi i file, quindi impostate i permessi di conseguenza.

Ora che abbiamo la KSK, per prima cosa la utilizziamo per ottenere i record DS (in sostanza l’hash della KSK) che andranno poi forniti al registrar affinché vengano pubblicati dalla zona del vostro TLD, come vedremo poi:

dnssec-dsfromkey -2 Kmydomain.tld.+005+62878.key >Kmydomain.tld.+005+62878.ds

Fatto ciò, provvediamo a generare anche la ZSK:

dnssec-keygen -K /etc/bind/dnssec-keys mydomain.tld

Ora abbiamo tutto il necessario; istruiamo quindi BIND affinché provveda a firmare i dati della nostra zona:

rndc sign mydomain.tld

Verifichiamo i log per verificare se tutto è andato come deve:

Aug 17 12:14:23 ns named[18394]: received control channel command 'sign mydomain.tld'
Aug 17 12:14:23 ns named[18394]: zone mydomain.tld/IN: reconfiguring zone keys
Aug 17 12:14:24 ns named[18394]: zone mydomain.tld/IN: next key event: 18-Aug-2011 00:14:24.075
Aug 17 12:14:24 ns named[18394]: zone mydomain.tld/IN: sending notifies (serial 2011081702)

Se non vi sono errori e vedete una cosa come quella qui sopra, la parte di competenza di BIND è andata come deve. Un zone transfer (“dig axfr mydomain.tld @<master>“) eseguito da uno degli slave vi confermerà che ora la zona presenta tutti i simpatici orpelli tipici di una zona firmata…

L’ultimo passo è far pubblicare il record DS relativo alla vostra nuova e fiammante KSK.

Il file .ds che abbiamo generato con il comando “dnssec-dsfromkey” contiene esattamente il record che andrà pubblicato dal TLD:

mydomain.tld. IN DS 62878 5 2 FB559ED949D1D86AB530C615DE0C944995C01A852AF77919A1891289 35857900

Esso è composto da 4 campi:

il KeyTag relativo alla KSK (sostanzialmente l’ID della KSK cui il DS si riferisce: se cambiate KSK, cambia l’ID e -ovviamente- il digest)
l’algoritmo utilizzato per le chiavi (“5” indica l’accoppiata RSA/SHA1)
il tipo di digest della KSK indicato dal record DS stesso (“2” significa che il digest è di tipo SHA256)
il digest della KSK stessa, eventualmente spezzettato alla bisogna per cacciarlo in zona

I passi per far pubblicare il record al TLD dipendono strettamente dal registrar utilizzato, sicché non posso essere troppo preciso al riguardo.

Nel mio caso ho usato come registrar GKG, che fornisce una comoda interfaccia REST per gestire le operazioni sui record DS.

Nel mio caso, quindi, tutto si è limitato alla creazione del record JSON dentro ad un file che ho denominato “DS”…

{
"digest":"FB559ED949D1D86AB530C615DE0C944995C01A852AF77919A189128935857900",
"digestType":"2",
"algorithm":"5",
"keyTag":"62878",
"maxSigLife":"3456000"
}

…per poi procedere ad inviare la richiesta al registrar attraverso una unica riga di curl, mandandogli via POST tale file:

curl -i --basic -u <myuser>:<mypassword> \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
-X POST \
--data-binary @DS https://www.gkg.net/ws/domain/mydomain.tld/ds

Oplà. Il vostro dominio (firmato) è servito.

Per verificare che tutte le operazioni siano andate a buon fine e che il vostro dominio ora validi correttamente, la maniera più banale è quella di sottometterlo all’analisi automatizzata di http://dnscheck.iis.se/ oppure di http://dnsviz.net/ se desiderate “vedere” tutta la (lunga) catena di chiavi che valida la vostra zona.

Ora i più svegli domanderanno: “sì, ma per inserire in zona nuovi record?”. Il modo in cui abbiamo detto a BIND di gestire la zona fa sì che sia sufficiente utilizzare nsupdate(1) e tutti i record aggiunti saranno automaticamente firmati…