Comunicazione urgente ai validatori DNSSEC

https://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record

Read Full Post »

DNSSEC resolver for dummies

Quasi, almeno…

Per semplificarvi la vita, partite installando bind >=9.7

Se usate debian, lo trovate precotto tra i backports.

Da questa versione, infatti, bind implementa il supporto ad RFC5011, ovvero il rollover automatico delle trust anchor.

Tutto quel che dobbiamo fare, pertanto, è fornire al nostro resolver la KSK della root-zone, indicandola come “managed“.

Questa è la parte fastidiosa: preleviamo la KSK dalla root-zone stessa e la smanacciamo per creare la direttiva di configurazione che serve a bind (raccomando di leggere il P.S. in coda a questo post).

Eseguiamo quindi la seguente query:

zarathustra:~ skull$ dig +multiline +noall +answer DNSKEY .
.                       86400 IN DNSKEY 256 3 8 (
AwEAAb1gcDhBlH/9MlgUxS0ik2dwY/JiBIpV+EhKZV7L
ccxNc6Qlj467QjHQ3Fgm2i2LE9w6LqPFDSng5qVq1OYF
yTBt3DQppqDnAPriTwW5qIQNDNFv34yo63sAdBeU4G9t
v7dzT5sPyAgmVh5HDCe+6XM2+Iel1+kUKCel8Icy19hR
) ; key id = 41248
.                       86400 IN DNSKEY 257 3 8 (
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
) ; key id = 19036

In risposta ad essa, otteniamo due record, relativi rispettivamente alla ZSK (riconoscibile dal flag 256) e alla KSK (flag 257).

Scartiamo la prima e teniamo solamente la KSK, riformattandola per ottenere un blocco siffatto:

managed-keys {

“.” initial-key 257 3 8 ”

AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= “;
};

Ora editiamo il nostro fido named.conf, inserendo il blocco così generato nella configurazione globale, mentre tra le opzioni inseriremo la direttiva necessaria al look-aside verso i trust-anchor ancora su DLV:

options {

[…]

dnssec-lookaside auto;

[…]

}

Configurazione terminata. Riavviate named e andate per la vostra strada…

Come verificare che DNSSEC stia funzionando come atteso?

Facile: basta verificare che i dati relativi a zone già firmate vengano correttamente autenticati, come ad esempio il sito del NIC Catalano:

zarathustra:~ skull$ dig +dnssec http://www.nic.cat @dns2.spin.it

; <<>> DiG 9.6.0-APPLE-P2 <<>> +dnssec http://www.nic.cat @dns2.spin.it
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36096
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.nic.cat.                   IN      A

;; ANSWER SECTION:
http://www.nic.cat.            300     IN      A       195.253.31.9
http://www.nic.cat.            300     IN      RRSIG   A 10 3 300 20100901234408 20100802230001 15875 nic.cat. YaB/ZfC1qQ9LxK9CeiJCcc2jmw/5yDNqfKHeMcOhbUeIFc7cTl2Gp7KZ Erf5cvYRyZBKi9TbeBhgJ8PTUo75PW1WyqzASElkJHftxBSqo5aYwOWZ nYVFHpcPwKvTP+9RcjMHxem8gJjg9KfAGaZyQq0c1srEDXopOwtH4hQi dXU=

;; AUTHORITY SECTION:
nic.cat.                300     IN      NS      ns8.knipp.net.
nic.cat.                300     IN      NS      ns4.knipp.de.
nic.cat.                300     IN      NS      anycast1.irondns.net.
nic.cat.                300     IN      RRSIG   NS 10 2 300 20100901234408 20100802230001 15875 nic.cat. lbHUU6uIfjn0F+Cd/PoqnOEao/h6xHV2irmeL804AZSo5n0c28jvzn16 eaWM9NL1iRmvqQ+iRFVecHD3azQEdkKchRbIJym2UAwMfpMDzimohs0u BPcgnSgs1ErRjD/HrMBa0P96x92GCGQedcCL3D6Aszu3Sd6d4ZVyMSPr iDA=

;; ADDITIONAL SECTION:
ns4.knipp.de.           81793   IN      A       195.253.6.33
ns4.knipp.de.           81793   IN      AAAA    2a01:5b0:0:29::21
ns4.knipp.de.           81793   IN      RRSIG   A 5 3 86400 20201231120000 20100730103103 25716 knipp.de. r0sj/sNRLzVAXbWzbuGxkMzlo2aRN94SGM9ARDFi281IbOakNNF1CpMq KyuOXc0iMGPkkqcG4XCSNZHNLfa/Nsb2z86Zpeo88656+05qrtwACD6+ rnobtip9mBtYsR3m9Dwhdt7sbUmInOaverKtjMx7lvaFJoh7q942z+Yk t3w=
ns4.knipp.de.           81793   IN      RRSIG   AAAA 5 3 86400 20201231120000 20100730103103 25716 knipp.de. dZElZS3BaJ+1WbYAJmHAXyvXa8WHVgL+7fAznLV17K9YX8oYM//7G/Yb Xw6bhCANA2zuc3L6FtSXDN4vlm1IfkxLp36yTT2jjHUvk9dl6S2k4Y0t 8HTp0HocRym7s/xKjd12lRGmiigPIEO1MWFYGlJh6XNMHy+K6FEAEKSQ s7s=

;; Query time: 390 msec
;; SERVER: 2a02:9a8:1::ff03#53(2a02:9a8:1::ff03)
;; WHEN: Mon Aug  9 17:58:35 2010
;; MSG SIZE  rcvd: 854

La presenza, nella risposta ottenuta, del flag “ad” (Authenticated Data) indica che siamo a cavallo…

Ora siete della partita DNSSEC (almeno per il vostro resolver…)

PS: I più svegli avranno notato come non abbia effettuato alcuna verifica della validità della KSK prima di portarla in produzione.

Ovviamente, la verifica la ho fatta, ma non la documento qui perchè

1. Preferisco essere conciso
2. Vi renderei le cose troppo facili 😉

Una hint, però, la dò: dnssec-dsfromkey(8) vi può produrre l’hash SHA256 della KSK, da confrontare con quello pubblicato da IANA (nel file XML)

Read Full Post »