Con questo post si conclude la serie dedicata a DNSSEC a cura dal mio amico brillante e appassionato networker Antonio PRADO. Colgo l'occasione per ringraziare Antonio per il suo prezioso contribuito su un argomento di grande interesse, testimoniato dal gran numero di visualizzazioni.
La prime tre parti del post le trovate qui, qui e qui.
Il ruolo dei risolutori ricorsivi
Scegliamo un risolutore come si deve. Innanzitutto dobbiamo comprendere che non tutti i risolutori sono uguali: ci sono quelli che rispondono solo per ciò che sanno in prima persona; quelli che non sanno nulla e chiedono tutto ad altri; quelli che hanno alcune informazioni di prima mano ma per tutto il resto si affidano alla misericordia di name server terzi. In questi ultimi due casi, ça va sans dire, l’atto di fede è essenziale, cioè dobbiamo fidarci delle risposte altrui (per non scoperchiare poi il vaso di Pandora contenente i temi privacy e raccolta dei dati delle interrogazioni fatte dai name server).
Alcune voci autorevoli tra gli studiosi del DNS sulla scena internazionale (penso in questo momento a Paul Vixie) caldeggiano la necessità di usare dei risolutori che possano ricadere nel proprio controllo, finanche residenti nel proprio calcolatore elettronico così da poter costantemente esaminarne funzionalità e comportamento.Nel mondo dei sistemi *nix è oramai consolidato il ricorso a risolutori locali anche in modalità predefinita. Sulla piattaforma usata per gli esempi di questa breve esposizione, FreeBSD, è presente il risolutore Unbound. Vediamo subito come configurarlo e usarlo al meglio soprattutto nella prospettiva di validare le risposte con le estensioni DNSSEC.
Va detto che se abbiamo in animo di gestire in proprio il risolutore dei nomi, dobbiamo soppesare alcune decisioni riguardo la cerchia di colleghi da coinvolgere e riguardo le modalità per chiamarli in causa.
Partiamo dall’àncora di fiducia (trust anchor), cioè dal file contenente le chiavi della zona “.” che poniamo alla base delle nostre validazioni.
Da chi prendiamo le informazioni con la sicurezza che siano autentiche? Innanzitutto proviamo a esaminare le risposte che ci vengono date dai 13 root server:
Possiamo ora inserire il valore del RR DNSKEY appena confermato all’interno di un file che chiameremo “chiavi”.
Tuttavia Unbound offre la possibilità di ottenere le chiavi in questione (in realtà solo quella utile al processo di validazione, cioè la KSK) attraverso l’esecuzione del comando:
che crea il file root.key in /usr/local/etc/unbound/ oppure in /etc/unbound/root.key a seconda di come sia stato installato Unbound.
~ # cat /usr/local/etc/unbound/root.key; autotrust trust anchor file
;;id: . 1
;;last_queried: 1600413395 ;;Fri Sep 18 09:16:35 2020
;;last_success: 1600413395 ;;Fri Sep 18 09:16:35 2020
;;next_probe_time: 1600455307 ;;Fri Sep 18 20:55:07 2020
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
. 86400 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchange=1600413395 ;;Fri Sep 18 09:16:35 2020
~ #
Se, dopo attento controllo, siamo persuasi di usare la funzione di Unbound per ottenere automaticamente la chiave utile alla validazione (unbound-anchor), è sufficiente che in
/usr/local/etc/unbound/unbound.conf
andiamo a inserire la riga:auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
Tra i singoli Paesi, troviamo in testa l’Arabia Saudita con quasi il 97%, tra gli europei l’Islanda con il 95%, la Finlandia è al 92%, la Svezia all’89%. In Europa, l’Italia con il suo 12% circa riesce a fare meglio solo di Spagna (11,22%), Regno Unito (11%) e Romania (4,29%). Perché?
Al di là della precisione statistica dello studio citato, il motivo è intuitivo: sembra che gli utenti italiani non abbiano a disposizione name server ricorsivi capaci di validare il DNSSEC, o meglio, solo il 12% dei navigatori italiani li ha configurati (o perché assegnati dal provider o perché autonomamente impostati).
E il vostro, quello che state usando in questo momento, è buono o no? Testatelo qui:
CONCLUSIONI
Avviamoci a chiudere questi ragionamenti
che ci accompagnano già da alcune pagine. Siamo partiti col rinfrescare un po’
i concetti di base del DNS, la terminologia e il funzionamento; abbiamo poi introdotto
la nozione di DNSSEC e spiegato le novità che questa tecnologia inietta nel
mondo della risoluzione dei nomi affinché si possano superare alcune debolezze
del protocollo originario.
Poi siamo transitati dalla teoria alla pratica, spiegando tutta la filiera delle lavorazioni connesse a ottenere dei dati autentici durante i processi di interrogazione verso i risolutori dei nomi con cenni alle buone pratiche.
Ci siamo interessati anche al rapporto tra costi e benefici della configurazione, gestione e manutenzione dei servizi arricchiti da DNSSEC e infine abbiamo dato un occhio alla diffusione nel mondo di queste estensioni di sicurezza sia nel contesto dei name server autoritativi sia in quello dei ricorsivi.
Tutto ciò detto, ciascuno di noi sarà in grado di formare una propria opinione sull’argomento e, se necessario, avere le coordinate giuste per approfondire, uno a uno, alcuni o tutti gli aspetti qui brevemente trattati.
Infatti queste poche righe sono un invito a studiare di più e meglio un argomento, quello del DNSSEC, che merita ogni giorno di più la nostra attenzione affinché da una parte gli operatori siano stimolati a una implementazione ragionata, dall’altra gli utenti siano consapevoli di alcuni degli ingranaggi che girano sotto il cofano di Internet.
Vorrei infine ringraziare il nostro
maestro, l’amico Tiziano Tofoni, per
avermi chiesto di cimentarmi in questo affascinante lavoretto e di pubblicarlo
su uno dei più importanti spazi di riferimento in Italia delle cose di Internet
(res interretis).
Nessun commento:
Posta un commento