Jistě jste si všimli, že vás, naše čtenáře, pravidelně informujeme o dění okolo podpisu kořenové zóny (naposledy zde). Máme za sebou úspěšně první i druhou KSK ceremonii a poslední krok, který dle harmonogramu zbývá, je zveřejnění pravého KSK klíče (až doposud byla kořenová zóna podepsaná pomocí mechanismu DURZ).
A dnešního dne bude celý tento proces, který trval několik měsíců, završen publikováním pravého KSK klíče (teď si na pozadí představte bouchání šampaňského a jásot :)).
Pravý klíč pro kořenovou zónu má následující hash:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkw9t5sACgkQoZmhm3FA9yZfkwCeOo3dGa5Nr1ux4WmDpRIrKjoM
iREAoKtYh03ZK+k5brhikmb+9u5iqOZU
=ZfNp
-----END PGP SIGNATURE-----
Tento DS záznam byl získán z dokumentu, který byl vytisknut na první KSK ceremonii:
DS záznam KSK klíče pro kořenovou zónu je podepsán GPG klíčem CZ.NICu 7140F726, který by měl být podepsán mým osobním klíčem a klíčem CSIRT CZ.NIC. Tento klíč můžete získat například ze server pgp.mit.edu:
gpg --keyserver pgp.mit.edu --recv-key 7140F726
Následující sekce bude platná až po publikaci tohoto klíče do kořenové zóny, která proběhne dnes 15. července 2010 mezi 21.30 – 01.30 středoevropského letního času.
Pokud budete chtít začít validovat pomocí klíče kořenové zóny, tak toto provedete změnou konfigurace vašeho rekurzivního DNS serveru (připomínám, že je zapotřebí rekurzivní server Unbound nebo Bind minimálně ve verzi 9.6-ESV nebo libovolné vyšší).
Přesný popis zveřejnění klíčů naleznete v dokumentu DNSSEC Trust Anchor Publication for the Root Zone. Důležité informace jsou tyto:
- Klíč bude zveřejněn ve dvou formátech:
- v XML obsahující hash DNSKEY klíče ve formátu DS záznamu
- v CSR (Certificate Signing Request) ve formátu PKCS#10
- URL XML souboru bude: https://data.iana.org/root-anchors/root-anchors.xml
- Podpisy souboru trust-anchors budou uloženy v:
Konfiguraci serveru Unbound provedete pomocí direktivy trust-anchor:
trust-anchor: ". IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5"
Druhou variantou je uložení DS záznamu do souboru např. /etc/unbound/root.ds
a nastavení directivy trust-anchor-file:
(nebo auto-trust-anchor-file:
)
trust-anchor-file: "/etc/unbound/root.ds"
Konfiguraci serveru Bind9 je podobná, jen formát záznamu je odlišný. Nepoužívá se přímo DNS záznam, ale rovnou DNSKEY.
Do konfigurace Bind 9.6 vložíte následující blok s konfigurací:
trusted-keys {
"." 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=";
};
Konfigurace pro Bind 9.7 je obdobná, ale použije se konfigurační direktiva managed-keys:
, která automatickou aktualizaci klíče v případě, že bude DNSSEC klíč změněn mechanismem popsaným v RFC5011:
managed-keys {
"." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=";
};
Po provedení změn musíte znovu načíst konfiguraci a měli byste mít zapnutu validaci pomocí kořenové zóny. Podotýkám, že bych zatím nevypínal validaci pomocí služby ITAR, která v současnosti obsahuje 26 pevných bodů důvěry. Oproti tomu kořenová zóna v čase psaní tohoto blogpostu obsahuje pouhých sedm bezpečných delegací:
# dig @xfr.lax.dns.icann.org . axfr | awk '/^[a-zA-Z0-9-]+\.[[:space:]]/ { print $1, $4; }' | grep DS | sort -u
bg. DS
br. DS
cat. DS
cz. DS
na. DS
tm. DS
uk. DS
Ověření validace můžete například provést takto:
# dig +adflag IN NS . @adresa_vašeho_resolveru
Nyní vypadá výsledek přibližně takto:
$ dig +adflag IN NS . @127.0.0.1
; <<>> DiG 9.7.0-P1 <<>> +adflag IN NS . @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7104
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
[...seznam NS záznamů...]
;; ADDITIONAL SECTION:
[...seznam IP adres nameserverů...]
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 14 15:45:11 2010
;; MSG SIZE rcvd: 492
Po podpisu kořenové zóny do hlavičky přibude příznak AD:
$ dig +adflag IN NS . @127.0.0.1
; <<>> DiG 9.7.0-P1 <<>> +adflag IN NS . @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7104
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15
[...]
Aktualizováno: Přidána konfigurace pro Bind 9.7.
Ondřej Surý
Pokud by si někdo chtěl přečíst jak jednoduše se bude DNSSEC konfigurovat v nadcházející verzi nejrozšířenější komerční Linuxové distribuce: http://www.redhat.com/promo/summit/2010/presentations/taste_of_training/Summit_2010_DNSSEC.pdf
Ověřil jsem že po přidání klíče kořenové zóny do /etc/named.conf v RHEL 6 beta 2 vše vypadá funkční (je použit BIND 9.7) – v příští beta verzi (a samozřejmě i ve finálních verzích) už by ten klíč měl být předvyplněný automaticky.
Možná je to hloupý dotaz, ale nikde jsem nevyčetl jak z těch souborů co si stáhnu na https://data.iana.org/root-anchors/ dostanu trust-anchor ve tvaru v jakém patří do konfiguráků…
např.: AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW….
zkoušel jsem base64 na Kjqmt7v.crt, ale vyšel mi jiný a delší tvar… jsem z toho trochu zmatený… rád bych věděl, jak si to sám vygenerovat z iany (ne že bych všemu blogu nevěřil, ale nevěřím :-)
Aha, tak už jsem to pochopil :-) iana z mě neznámých důvodů ten klíč vůbec nešíří, ale jenom jeho checksumy a podpisy. Ale nebylo by od věci ukázat několik metod, jak pomocí nich ověřit klíč získaný třeba z „host -t DNSKEY .“ nebo z digu. Například pomocí bashe, gpg a sha256sums. Děkuji.