ReissBlog: DNSSEC: una guida ragionata all’implementazione

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:

~ # foreach x ( `jot -w %c 13 a` )

echo '##Risposta del root server' $x; dig @$x.root-servers.net. . DNSKEY IN +short; echo '##';

end

##Risposta del root server a

257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU=

256 3 8 AwEAAdauOGxLhfAKFTTZwGhBXbk793QKdWIQRjiSftWdusCwkPhNyJrI jwtNffCWXGLlZAbpcs414RE3oS1qVwV+AdXsO92SBu5haGlxMUk0NqZO 7Xlf84/wrzGZVRRouPo5pNX/CKS8Mv9UOi0olKGCu31dNfh8qCszWZcl oLDgeLzSnQSkvFoGe69vNCfh7feESKedkBC2qRz0BZv9+oJI0IY/3D7W EnV0NOlf8gSHozhfJFJ/ZAKtvw/Q3ogrVJFk0LyVaU/NVtVA5FM4pVMI RID7pfrPi78aAzG7b/Wh/Pce4jPAIpS3dApq25YkvMuPvfB91NMf9Fem Kwlp78PBVcM=

##Risposta del root server b

##Risposta del root server c

##Risposta del root server d

##Risposta del root server e

##Risposta del root server f

##Risposta del root server g

##Risposta del root server h

##Risposta del root server i

##Risposta del root server j

##Risposta del root server k

##Risposta del root server l

##Risposta del root server m

~ #

Le risposte sembrano essere tutte concordanti sui medesimi risultati. Questo dovrebbe essere sufficiente per avere la sicurezza di quali siano le chiavi per la zona “.”. (Nel caso in cui i risultati non fossero coerenti l’uno con l’altro occorrerà di certo un rigoroso approfondimento).

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:

~ # unbound-anchor

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
~ #

Non entreremo nel dettaglio dell’intera configurazione di Unbound, ma esaminiamo con attenzione i brani utili all’oggetto del nostro interesse.

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"

Nel caso in cui il nostro risolutore Unbound non risieda localmente, possiamo configurare il demone affinché dialoghi con noi su un canale protetto da TLSv1.3 alla porta 853 del protocollo TCP. Sarà sufficiente inserire, dopo averle valorizzate correttamente, le seguenti istruzioni:

tls-service-key: "path/to/privatekeyfile.key"

tls-service-pem: "path/to/publiccertfile.pem"

tls-port: 853

tls-ciphersuites: "TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_AES_128_CCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY130

5_SHA256"

A questo punto cosa abbiamo ottenuto? Un servizio di risoluzione dei nomi dotato di un àncora di fiducia e che, di conseguenza, è in grado di validare le risposte ottenute attraverso le estensioni DNSSEC. Inoltre, nell’ipotesi che non fosse un risolutore locale, abbiamo la possibilità di dialogarci su un canale crittografato.

Proviamo se tutto ciò che stiamo affermando risponde a realtà e dunque chiediamo al nostro Unbound locale di validare il RR IN A per www.prado.it:

~ # drill -aDSV4 www.prado.it A IN

;; Number of trusted keys: 1

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 46293

;; flags: qr rd cd ra ad ; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;; www.prado.it. IN A

;; ANSWER SECTION:

www.prado.it. 200 IN A 104.28.0.91

www.prado.it. 200 IN A 172.67.133.171

www.prado.it. 200 IN A 104.28.1.91

www.prado.it. 200 IN RRSIG A 13 3 300 20200919105638 20200917085638 34505 prado.it. Sv/+y0EyJ3BlWFLbeUNEEStjwftaZOF2sESSId3r7JNFLhY4xyGckoHR6O5icGdUWYYOinxISCPiAi9yxzWPXg==

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec

;; EDNS: version 0; flags: do ; udp: 4096

;; SERVER: 127.0.0.1

;; WHEN: Fri Sep 18 11:58:18 2020

;; MSG SIZE rcvd: 193

;; Chasing: www.prado.it. A

DNSSEC Data Chain:

;; rcode: NOERROR

;; qtype: DNSKEY

rrset:

. 86300 IN DNSKEY 256 3 8 AwEAAdauOGxLhfAKFTTZwGhBXbk793QKdWIQRjiSftWdusCwkPhNyJrIjwtNffCWXGLlZAbpcs414RE3oS1qVwV+AdXsO92SBu5haGlxMUk0NqZO7Xlf84/wrzGZVRRouPo5pNX/CKS8Mv9UOi0olKGCu31dNfh8qCszWZcloLDgeLzSnQSkvFoGe69vNCfh7feESKedkBC2qRz0BZv9+oJI0IY/3D7WEnV0NOlf8gSHozhfJFJ/ZAKtvw/Q3ogrVJFk0LyVaU/NVtVA5FM4pVMIRID7pfrPi78aAzG7b/Wh/Pce4jPAIpS3dApq25YkvMuPvfB91NMf9FemKwlp78PBVcM= ;{id = 46594 (zsk), size = 2048b}

. 86300 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b}

sigs:

. 86300 IN RRSIG DNSKEY 8 0 172800 20200930000000 20200909000000 20326 . o/GuEANolz40+XYxbaT6zMDo5jy5hSBMcBdKpSgsTvSN89k880mzFvi2BfFoP+TYKjUOaK6THCISoH5kP0N9mm9DpFivhXyhQWCtTareLwW63YdqA91tqT+QhluoVlf0ZVoMGyCCib3FRCW0siKGBljadtSr3dootSyKxzGcQ8kSJLyRcQF7fn7LWMadfcFLPjxkk43iWusaFYbLZb2BCo/CzQPd6WdUjiD24C1OwJlVRdYNZPIgZmgO3cw8eU87NaRKWljKv59jyVti1WcYMsWqKFaKag6LOfk4OkVsbFc2Y937cnnxNfthH1Mzlhs3Kybo+yvUd+YZAit+JWkaAg==

---

;; rcode: NOERROR

;; qtype: DS

rrset:

it. 86300 IN DS 41901 10 2 47f7f7ba21e48591f6172eed13e35b66b93ad9f2880fc9bada64f68ce28ebb90

sigs:

it. 86300 IN RRSIG DS 8 1 86400 20201001050000 20200918040000 46594 . prfQGANsv7kM60NCfeB4jUHtRo6HTXD+fXw/Wbip5WVCDIXyUUnHKRv+LmozdvWpyQHFdHo96L928/8vAYq4Rz1RsaO8+fmWeuqqAbSBqBsmyIPo+KZGMPf8ClY9bEanBRxXdjgU6hZSu+wNZLSq7xKw7+yzuqHvo6+3IHDf+5Fzbi0ifeMmFCTuzVPS3b6WBYZjsjW87HqtRok1K9/QgcXbpBKk+FqB4b9xXvNQotPoloFZzUyT/6KgoBAWFIH9/OzlR0cibEp7eybIj7dQqgwL5R/3sAYfZXx6KSHk6ry54CGVQ4KyMg8730WMHY3658s87xA1cnuQ2d1hKpFVwQ==

---

;; rcode: NOERROR

;; qtype: DNSKEY

rrset:

it. 10700 IN DNSKEY 256 3 10 AwEAAbCBaRnTOVXDfC5ulw7mj4aT2Tr/vs1j6q97qKI+eWbyQUwpf9LVcrq7sKMSRoF6oiK9AaHDyCWogIbVADuYKAJfLU0ahJvB00sWQHiqOj5AJFMLnRtD7yylpPRNagRHmv6hFODR6uq0p67yTMzOc7MTixKTsRQQ1lyrr90uNrUaqnRVTc4TLBypvuWXfXP8SBfK4zfq5TPux6V8gU8kzJ17RoWMRetEarY2Q8T34YsT4484Bnns+IJjf8lPjEptfDL+E02+/K+zY4VGemQf/xyyHtu9rAjSLXJv74hXumTWMlUOKwUf7jz1+LMKMYS55czc47pf0BZZAraZjE3NgBk= ;{id = 18395 (zsk), size = 2048b}

it. 10700 IN DNSKEY 257 3 10 AwEAAay8sLBy644P9n/DUS3XakNteW7zvQTBVPGwXDknOSR/ywiIeKRR5aoroib5zkEhchqGxMqYxtnuemPsAW/II9pv/coNAJEx6PYjW7nTXfKvMR+JGgjCHn2o/pK7J+MO9MUp9Vt35qRczcrtc9Yaidh5ZBM2ju/S6X4L7vdNDiWc4iia1fG6p8b+J4mvl6ewzV9sggbBAZGaE//S3ed06FGYdSD9I/fC8PNkBRXXVsv9tR3IlxyGtw0hINGkUKn6Ku+SZ4VtkU5+bvaAeFWwfAIdG+Jaj56gm5rMuRYlCfRzlqM5Q5Yv/LGo22E8SPO8NMAulo9ULP9chxg4mfyzDNU= ;{id = 41901 (ksk), size = 2048b}

sigs:

it. 10700 IN RRSIG DNSKEY 10 1 10800 20201018080327 20200918080327 18395 it. m9esF/hSwQKwWHOf/DK88DPHZuMQv+J4uc3LiKbnj2CQRGGbdfOxAuziko6Nd7R4uTK/lc5phcm++tvnYakqshYGF3ci95A/FWQ740G/ZYzq/GQIFX+VVFzD6eG7HWx43gCwjAFpJMexmN1Y03Ew2xJjiwXUCYlVMglKSAT+3lv8rvJCiFhC6FSDRp3/r8+R7UurrTatzz1op8mUVjOTRZXfu1B3SGuSgRKdV50+LJpl7bCRNTVppOF9yhawsIaQgSUlpKEuZHFlkg+YySxh/1m1u3xSklLtGwAsAWK7c1iOZCXWYJLLhsl4AT1QoHZwpUAiQ5K3ibvsVZP5/npA6g==

it. 10700 IN RRSIG DNSKEY 10 1 10800 20201018080327 20200918080327 41901 it. gAuvQC5gaYgKVfA5F2qnrl3GVEgZ43vj8pgvEaLtqjb6kLn4RbBicMfdqK56zFG6JLCPgUC9QKBMWBpjBD+nAcrL3haWYNErJxoKccLpj6IT6sUTv0SzVXpnAE2kgncGdS/ucOlKSRGzunOdffkNqvUszxm3RLcACp5GS232JttluB2cYWiSBom0eyj/1hDusrLlxuillFJROpovGuoUJ617lqLZQqcLYwbW4EhMY17o0DpJA/o5PsL+csNiqQXdH9puJpWjYZXTSDv4ov00EQIvCqIe1xgCdFLZWHeQ3DorsubbpgSg8zjAipeZlADB9YQU9BFh2PdSKrzmEySeaw==

---

;; rcode: NOERROR

;; qtype: DS

rrset:

prado.it. 10700 IN DS 2371 13 2 7c25a7c8272edc86e8d60b4fb0a970902ed1838526ac0e9bc73c54c1a7ced733

sigs:

prado.it. 10700 IN RRSIG DS 10 2 10800 20201018080327 20200918080327 18395 it. pQds8fXvbeuaj8KZDbUJ0tLhRPQXL/gZTMVhM5SujNPM11pFpK4qaa2G1MTnWZ00adQ1DVI6YE5NjLSJW/bwnBpqKafvmSoUdo/aNHAQxjLwvWjIFuBO7wOp7c2zcefmpG5zxEH/mIIP81/TSBmvh0R1uXkt8hhkMl0QEOe2QMk/eJjt5UauykgALjgwFNBdfAjejD7kZOZg2ZL7swyxhTA/Ax0DLhBsUsR13yeoAQkaKan4+QDottwuULsTcPZccQ7s5jBa7WtX9Q7LJZh89JIar9RbkZIXXinGIpe+6ib46xMYYmEJdoX0mZdIAo3ciwaW8gm+Od4bbzkZsiMfVQ==

---

;; rcode: NOERROR

;; qtype: DNSKEY

rrset:

prado.it. 3500 IN DNSKEY 257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjjnopKl+GqJxpVXckHAeF+KkxLbxILfDLUT0rAK9iUzy1L53eKGQ== ;{id = 2371 (ksk), size = 256b}

prado.it. 3500 IN DNSKEY 256 3 13 oJMRESz5E4gYzS/q6XDrvU1qMPYIjCWzJaOau8XNEZeqCYKD5ar0IRd8KqXXFJkqmVfRvMGPmM1x8fGAa2XhSA== ;{id = 34505 (zsk), size = 256b}

sigs:

prado.it. 3500 IN RRSIG DNSKEY 13 2 3600 20201008050704 20200809050704 2371 prado.it. o4BpZGSvIN+R+weWNNDFWvviZuJCzEdHWrwBMYybhzA4Q0cm18o9gGu0voq/px/UVzncvlZm2m+V2z15F5GdaQ==

---

;; rcode: NOERROR

rrset:

www.prado.it. 200 IN A 104.28.0.91

www.prado.it. 200 IN A 172.67.133.171

www.prado.it. 200 IN A 104.28.1.91

sigs:

www.prado.it. 200 IN RRSIG A 13 3 300 20200919105638 20200917085638 34505 prado.it. Sv/+y0EyJ3BlWFLbeUNEEStjwftaZOF2sESSId3r7JNFLhY4xyGckoHR6O5icGdUWYYOinxISCPiAi9yxzWPXg==

---

DNSSEC Trust tree:

www.prado.it. (A)

|---prado.it. (DNSKEY keytag: 34505 alg: 13 flags: 256)

|---prado.it. (DNSKEY keytag: 2371 alg: 13 flags: 257)

|---prado.it. (DS keytag: 2371 digest type: 2)

|---it. (DNSKEY keytag: 18395 alg: 10 flags: 256)

|---it. (DNSKEY keytag: 41901 alg: 10 flags: 257)

|---it. (DS keytag: 41901 digest type: 2)

|---. (DNSKEY keytag: 46594 alg: 8 flags: 256)

|---. (DNSKEY keytag: 20326 alg: 8 flags: 257)

;; Chase successful

~ #

Validazione avvenuta con successo, cioè i dati che il nostro risolutore ci ha restituito sono autentici. Cosa succederebbe invece se il nome a dominio non facesse uso di DNSSEC?

Ecco la risposta:

~ # drill -aDSV4 www.governo.it A IN

;; Number of trusted keys: 1

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 44425

;; flags: qr rd cd ra ; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;; www.governo.it. IN A

;; ANSWER SECTION:

www.governo.it. 599 IN CNAME www.governo.it.edgesuite.net.

www.governo.it.edgesuite.net. 21600 IN CNAME a1813.b.akamai.net.

a1813.b.akamai.net. 20 IN A 93.186.135.107

a1813.b.akamai.net. 20 IN A 93.186.135.90

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 437 msec

;; EDNS: version 0; flags: do ; udp: 4096

;; SERVER: 127.0.0.1

;; WHEN: Fri Sep 18 12:02:02 2020

;; MSG SIZE rcvd: 146

;; Chasing: www.governo.it. A

DNSSEC Data Chain:

<no data>

DNSSEC Trust tree:

<no data>

No trusted keys found in tree: first error was: No DNSSEC public key(s)

;; Chase failed.

~ #

Potrebbe succedere invece che pur essendo presenti le estensioni DNSSEC la validazione non vada a buon fine? Certo, ecco un esempio appositamente confezionato:

~ # drill -aDSV4 dnssec-failed.org A IN

;; Number of trusted keys: 1

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 39694

;; flags: qr rd cd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;; dnssec-failed.org. IN A

;; ANSWER SECTION:

dnssec-failed.org. 7196 IN A 69.252.80.75

dnssec-failed.org. 7196 IN RRSIG A 5 2 7200 20200918175108 20200911144608 44973 dnssec-failed.org. 4iFT/+KbIw8NxSCntAPARgYakMnDGLqFQyMXg3UQ4jeUHZL5ATt6X6MAKf4dDOesVlD188gAlxV8D76WiXNu/KnFkgh3Oer3OELXverHvMPxUEkaWRGG6qF6WRbUNZGpK0fPJVlpN51dnBo6FScpVWisuBywITf97e6Fmtiro10=

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 5020 msec

;; EDNS: version 0; flags: do ; udp: 4096

;; SERVER: 127.0.0.1

;; WHEN: Fri Sep 18 12:07:41 2020

;; MSG SIZE rcvd: 239

;; Chasing: dnssec-failed.org. A

DNSSEC Data Chain:

;; rcode: NOERROR

;; qtype: DNSKEY

rrset:

. 85732 IN DNSKEY 256 3 8 AwEAAdauOGxLhfAKFTTZwGhBXbk793QKdWIQRjiSftWdusCwkPhNyJrIjwtNffCWXGLlZAbpcs414RE3oS1qVwV+AdXsO92SBu5haGlxMUk0NqZO7Xlf84/wrzGZVRRouPo5pNX/CKS8Mv9UOi0olKGCu31dNfh8qCszWZcloLDgeLzSnQSkvFoGe69vNCfh7feESKedkBC2qRz0BZv9+oJI0IY/3D7WEnV0NOlf8gSHozhfJFJ/ZAKtvw/Q3ogrVJFk0LyVaU/NVtVA5FM4pVMIRID7pfrPi78aAzG7b/Wh/Pce4jPAIpS3dApq25YkvMuPvfB91NMf9FemKwlp78PBVcM= ;{id = 46594 (zsk), size = 2048b}

. 85732 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b}

sigs:

. 85732 IN RRSIG DNSKEY 8 0 172800 20200930000000 20200909000000 20326 . o/GuEANolz40+XYxbaT6zMDo5jy5hSBMcBdKpSgsTvSN89k880mzFvi2BfFoP+TYKjUOaK6THCISoH5kP0N9mm9DpFivhXyhQWCtTareLwW63YdqA91tqT+QhluoVlf0ZVoMGyCCib3FRCW0siKGBljadtSr3dootSyKxzGcQ8kSJLyRcQF7fn7LWMadfcFLPjxkk43iWusaFYbLZb2BCo/CzQPd6WdUjiD24C1OwJlVRdYNZPIgZmgO3cw8eU87NaRKWljKv59jyVti1WcYMsWqKFaKag6LOfk4OkVsbFc2Y937cnnxNfthH1Mzlhs3Kybo+yvUd+YZAit+JWkaAg==

---

;; rcode: NOERROR

;; qtype: DS

rrset:

org. 86395 IN DS 17883 7 1 38c5cf93b369c7557e0515faaa57060f1bfb12c1

org. 86395 IN DS 17883 7 2 d889cad790f01979e860d6627b58f85ab554e0e491fe06515f35548d1eb4e6ee

sigs:

org. 86395 IN RRSIG DS 8 1 86400 20201001050000 20200918040000 46594 . pvONvOaajhBGi1CuTlHcSC04zrhVOFumVOZxtw/KX4nTwIli/aYwgHCB923GXYJ2OrPzvIK2IPTziCt1pX/9aY8FmajhoCqfC4vAKi1l9hk5J2pKy5TW98gZ3efCikDoGD9PQHcZXxEGRpqI51fU4bUO99IURUp+25xEP/i/bsiVF8NDRc2BbXLFl/HTOLMjBtw+S00AKn9ZojjBeAJClUFZtT84d0PfDgamqI94IAEzaImPVbvoXBBmQNE/aDhydRT8ICrkKHudCUz7kOS7kyRz2DrpV6gijWqACzb7ga+yazZUcUI4NTmt6UaoNnPlLuuciaZ51sd8xdD9LawwBQ==

---

;; rcode: NOERROR

;; qtype: DNSKEY

rrset:

org. 896 IN DNSKEY 257 3 7 AwEAAcMnWBKLuvG/LwnPVykcmpvnntwxfshHlHRhlY0F3oz8AMcuF8gw9McCw+BoC2YxWaiTpNPuxjSNhUlBtcJmcdkz3/r7PIn0oDf14ept1Y9pdPh8SbIBIWx50ZPfVRlj8oQXv2Y6yKiQik7bi3MT37zMRU2kw2oy3cgrsGAzGN4s/C6SFYon5N1Q2O4hGDbeOq538kATOy0GFELjuauV9guX/431msYu4Rgb5lLuQ3Mx5FSIxXpI/RaAn2mhM4nEZ/5IeRPKZVGydcuLBS8GZlxW4qbb8MgRZ8bwMg0pqWRHmhirGmJIt3UuzvN1pSFBfX7ysI9PPhSnwXCNDXk0kk0= ;{id = 17883 (ksk), size = 2048b}

org. 896 IN DNSKEY 256 3 7 AwEAAb9pH9bq32fIzmEmQgVebMd8F0IxmKjBrNboErZAIU5dMXBbMuFfx80eWkXbjIg6X9qrl0EOxvu8d8EUzkPO7ThJJlYvWRWau+xHe09lWU64np/h3XBoITXXQN8p4xyQDM+xOHpcSs+4TRI2Qi4FG/Hlbbdadl40i8a54JjmIcml ;{id = 22064 (zsk), size = 1024b}

sigs:

org. 896 IN RRSIG DNSKEY 7 1 900 20201008152825 20200917142825 17883 org. MDq/FA5BltF+tyHnkkqNp9Yg9w+6af80/KryAOQGEsq801jN6QpUE69mXvbXH7wsgbC2qcdJH1jvTP+x4XqjItMxNsaYoCziWomzuBONDG1+tBgI6QtOeSpBQtl8goc/lHBKovWMaaQxxs27mKIu0pDRKMdmffZrGkIE/iIJHVY9XY8N9NNGDph8uMp+1Q4JAFlERWoZdiM0CkkRNcWpHlWqoHa62XWYJha3iOPZ1XxLVgeDgxrGcREygG8XbxLyXMah8ctyvnQ5lYvyVlW1swv9MT1wPsgbu2v4xZ5gfgIoqkGuQJBfd4x19EkAfuqhKQJba1NJRIYPbRiEoHBITg==

---

;; rcode: NOERROR

;; qtype: DS

rrset:

dnssec-failed.org. 86395 IN DS 106 5 2 ae3424c9b171af3b202203767e5703426130d76ef6847175f2eed355f86ef1ce

dnssec-failed.org. 86395 IN DS 106 5 1 4f219dce274f820ea81ea1150638dabe21eb27fc

sigs:

dnssec-failed.org. 86395 IN RRSIG DS 7 2 86400 20201008152825 20200917142825 22064 org. PCvhLL6nOZ9HkBf6/jJjzntlhBgjKP+i+K//Gf4beGXM0u5SJ/8VejxatJyr2pM1s5uGil6BddQJcMMcYESHPw8LuF6PPfeYkhSQab4uArclHASk/FRE0ZRIUB0RjCqubaZjdtpIfAxS7bCsHGeG6ZJaaBGItwUx/zcA+eOyasA=

dnssec-failed.org. 86395 IN RRSIG DS 8 2 86400 20201008152825 20200917142825 63858 org. LAcPmPEfGnB+vNrLPnzI9UPWjFQZWA/pdLFf5/n6eUDXMsZRuzYnAf+JkJ13njqBXacB9o2rQArPAmxeJfe/FnomqAYpd4RjnxH1OH7vkx+/MElCKs4I/g3MlaXLf5d5vXot0jWIXbM3QYblsqlGIov44042oOnts6D/86uaxPU=

---

;; rcode: NOERROR

;; qtype: DNSKEY

rrset:

dnssec-failed.org. 3600 IN DNSKEY 256 3 5 AwEAAewq/QcrsNX3C/nAAWyNY74f/q9Rb2dGLc3LOIkQBATwzIcDTDHNRjtRDxjquImNpoDKybI2hZ2e8mNKvCK/F/QXV5LafLwSzscqwvzJxEGZUA+JuiGu6kq/8OjE6EEAdYlk4ztN6OWfwuqj4ZolBjKPXCPodYvhj8gl7kqpopqr ;{id = 44973 (zsk), size = 1024b}

dnssec-failed.org. 3600 IN DNSKEY 257 3 5 AwEAAb/f/pB/FLWoYp3j+HtldGkbUMT6caAw2rej0DZkgXVFOKn4PWi3BYjCozjEqxeramt+9b1SMuOSJ8vGKWr0YKrfyfJigsVxpsMgJ7QWcxeMACjC/oM8BPjDFBby/CgQQE63nPVX2SfDWCRhEhTOnsPZpKJvq66IHF/w+3u0IpyeplQWvO+HJ9OQPOQrstM7d/IPa7yKEtqS2nhBT0GWX2/GYhT6oE7F4vc2VF9f6MjpB/pWPzkcx636YaxG9P0QRBvzdD/Wztcbz1Scgxw5sUlIkQAzWV1mJfvXF+7NqzGcc94/kMt1VUzN2kYASRyn1ALiFPfNLz4VMUvSw5fpNS0= ;{id = 29521 (ksk), size = 2048b}

sigs:

dnssec-failed.org. 3600 IN RRSIG DNSKEY 5 2 3600 20200918175108 20200911144608 44973 dnssec-failed.org. TKL1w9mvzvrCGRyYoFD7oYyzeQHGPcankoiCc3dCheKo+rNOzY2wPAR3a6XkMh12+s/ssDsZO3L8rwv1hpgazdPqNVU0LSyaetmyWNDEOfz7Pnn8ClPhcZIg6e61CAJAhfSXU5NKrH080U7yVnbefbqQlaDQ9gHd+FLCgAbHHu0=

dnssec-failed.org. 3600 IN RRSIG DNSKEY 5 2 3600 20210102145108 20200904105108 29521 dnssec-failed.org. hoObZ8apcxKS87j6WYNDH4bUj4AY3FT306yhrvLNmnYp90TSvs/gaU/PbTL1SE14egxcFfxyzFY8aWbOlDPRC6dIYb3sJ8FBMiSCWj6ISxDu2ekAvbS4iW8r3fwWjqpkxDxMThHt77E/AtPqlGeFgaEIbGXLQsgIi3PYehEMJFfSxXvFnr0A+cLxcyZq3fNxpR7xWyshWuEt0u1WipIrfBVOCGRxHaiU9Acj9dPDcKFqDOAam6fLtFiIop74uvIQziqeRCDU2/a04j5q6sEMQbLOFq5Ux9CYrs/SsfnStPI6wK5nY5NwDETertJPtLnAjCKZDag9nbh54aCJjaHKxQ==

---

;; rcode: NOERROR

rrset:

dnssec-failed.org. 7196 IN A 69.252.80.75

sigs:

---

DNSSEC Trust tree:

dnssec-failed.org. (A)

|---dnssec-failed.org. (DNSKEY keytag: 44973 alg: 5 flags: 256)

|---dnssec-failed.org. (DNSKEY keytag: 29521 alg: 5 flags: 257)

No trusted keys found in tree: first error was: No DNSSEC public key(s)

;; Chase failed.

~ #

Queste procedure vengono eseguite per noi da Unbound il quale non ci restituisce risultati palesemente falsi, come quest’ultimo caso.

Ecco nuovamente i tre esempi autoesplicativi:

~ # drill prado.it A IN

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 51906

;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;; prado.it. IN A

;; ANSWER SECTION:

prado.it. 300 IN A 104.28.1.91

prado.it. 300 IN A 172.67.133.171

prado.it. 300 IN A 104.28.0.91

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 57 msec

;; SERVER: 127.0.0.1

;; WHEN: Fri Sep 18 12:13:04 2020

;; MSG SIZE rcvd: 74

~ #

~ # drill governo.it A IN

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 53242

;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;; governo.it. IN A

;; ANSWER SECTION:

governo.it. 1200 IN A 195.66.12.19

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 24 msec

;; SERVER: 127.0.0.1

;; WHEN: Fri Sep 18 12:12:47 2020

;; MSG SIZE rcvd: 44

~ #

~ # drill dnssec-failed.org A IN

;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 49583

;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;; dnssec-failed.org. IN A

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 11449 msec

;; SERVER: 127.0.0.1

;; WHEN: Fri Sep 18 12:09:35 2020

;; MSG SIZE rcvd: 35

~ #

Sintetizzando: se i dati sono firmati con DNSSEC e la validazione ha successo, Unbound ci restituisce il RR richiesto certificando la sua autenticità; se i dati non sono firmati, Unbound ci restituisce il RR senza certificazione di autenticità; se i dati sono firmati ma la validazione non va a buon fine, Unbound non ci restituisce il RR.

Ci riteniamo soddisfatti? In prima battuta direi così così perché siamo costretti ad accettare il fatto che chi non implementa DNSSEC vince comunque la risoluzione dei nomi.

Per guardare il lato positivo della faccenda invece, possiamo giudicare che sia meglio di niente poiché comunque coloro che realmente tengono all’affidabilità dei propri servizi riescono a regalare ai propri utenti una elevata percezione di sicurezza.

Dunque, se per gli utenti è un beneficio gratuito, è lo stesso per i fornitori di servizi?

Il costo di DNSSEC

Una prolifica letteratura si è occupata, ma lo fa ancora oggi, di DNSSEC esaminandone le molteplici sfaccettature. Tra gli argomenti oggetto di ricerca appare anche l’analisi sull’eventuale maggior dispendio di energie connesso all’implementazione, gestione e funzionamento sia dei client sia dei server coinvolti dal DNSSEC.

Ecco, a questo proposito vorrei qui riportare le conclusioni di uno studio condotto qualche anno fa dal ricercatore Geoff Huston:

“L’efficiente esercizio del DNS si poggia su una cache efficace e aggiungere DNSSEC alla miscela non altera questa osservazione. Il costo per il client di aggiungere la firma DNSSEC a un nome è efficacemente assorbita dalla cache del DNS.

Il costo per i server dei nomi è in qualche modo più grande dato che le risposte più corpose del DNSSEC implicano un carico di traffico più alto. Al giorno d’oggi, firmare un nome implicherebbe che il carico della richiesta aumentasse di una volta e mezza e che il traffico aumentasse di 8 volte. Se tutti su Internet usassero risolutori capaci di validazione DNSSEC, allora firmare un nome implicherebbe un costo sul server autoritativo dei nomi di circa 4 volte il carico di richieste e circa 12 volte il carico di traffico per le risposte.

È essenziale che le firme DNSSEC siano mantenute in modo corretto. Se le firme non sono buone, il carico di richieste è assai più pesante. Come minimo c’è da aspettarsi un carico di richieste doppio rispetto a quello per un nome correttamente firmato e un simile raddoppio nei volumi di traffico. Ma dicevo come minimo. Probabilmente sarebbe molto di più. E l’aggravio lato server non sarebbe affatto compensato. Quando la firma non è valida, i risolutori capaci di validazione DNSSEC, e i loro client, non sono in grado di risolvere il nome.”

[Per leggere l’intero articolo tradotto in italiano è possibile aprire questa pagina.]

Tornando al nostro argomento, comprendiamo assai bene che DNSSEC, rispetto al DNS tradizionale, costa e, in alcuni casi, costa anche molto in termini di risorse umane, cicli di CPU, occupazione di banda e tempi d’attesa. Ma, vorrei concludere, il beneficio è così importante che Parigi val bene una messa.

È certo che quanti più nomi a dominio ricorreranno agli scudi di DNSSEC, tanto più coerente, affidabile e sicura diventerà buona parte di Internet.

Quanto è diffuso DNSSEC?

Firma tu ché firmo anch’io. Ogni autorità deve accordarsi con quella immediatamente sovraordinata così che le zone vengano firmate a cascata come già abbiamo ampiamente illustrato.

Cominciamo dagli autoritativi e partiamo dalla zona “.”: al momento della stesura di queste pagine (settembre 2020), contiene 1.508 TLD, dei quali 1.383 sono firmati, cioè quasi il 92% del totale. 1.372 TLD hanno àncore di fiducia pubblicate come RR DS nella zona “.”.

Tra i TLD, prendiamo il .com: sotto questa gerarchia sono stati registrati oltre 147 milioni di nomi (147.653.008) dei quali quasi 2 milioni e mezzo (2.412.182) risultano firmati (1,7% circa).

Tra i ccTLD, il più virtuoso è lo svedese .se che conta 1.480.129 nomi dei quali 762.668 sono firmati (oltre il 51%).

Spostiamoci ora nella giungla delle risoluzioni dei ricorsivi. È possibile esaminare i dati presi da progetti di ricerca internazionali (segnatamente quello condotto da APNIC) che tentano di rispondere alla domanda: quanti utenti possono beneficiare della validazione DNSSEC?

A livello mondiale risulta che poco più del 25% degli utenti sia in grado di ricevere risposte contenenti dati autentici grazie a DNSSEC (cioè hanno a disposizione un risolutore ricorsivo capace di validare la catena della fiducia). Si sale al 30% in Europa e al 37% in Oceania. Quanto alle macro-regioni, abbiamo la Micronesia in testa con quasi il 62% e l’Europa Occidentale a poco più del 44%.

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:

https://dnssec.vs.uni-due.de.

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).

Pagine

domenica 25 ottobre 2020

DNSSEC: una guida ragionata all’implementazione - Parte IV (ultima)

Nessun commento:

Posta un commento

Libri consigliati

Post in evidenza

Banda e Throughput: un po' di chiarezza

Citazioni