Po podpisu kořenové zóny bude stačit v konfiguraci validujícího resolveru mít pouze klíč pro kořenovou zónu. V ideální případě všechny ostatní domény budou podepsány tak, že k použitým klíčům povede řetěz důvěry od kořenového klíče. V současnosti však kořenová zóna podepsána není a proto je zapotřebí tuto situaci nějakým způsobem vyřešit. Pokud pomineme možnost DNSSEC validaci vůbec nepoužívat, tak nám zbývají tři cesty, jak vytvořit řetěz důvěry.
Způsob první – Jednotlivé klíče
Způsob první už jsme si ukázali v předchozích článcích. Do konfigurace validujícího resolveru přidáme jednotlivé klíče – pevné body důvěry – pro všechny domény (resp. ostrovy důvěry), které chceme validovat. Tento způsob je nejjednodušší, lze jej použít i na doménová jména, která nejsou veřejná, a administrátor má věci pevně pod kontrolou. Z výhod plynou i nevýhody – je zapotřebí se o individuální klíče pečlivě starat. Pokud by administrátor zapomněl nakonfigurovat nové klíče v případě jejich výměny na autoritativním serveru, došlo by k zneplatnění všech podpisů a doména by se jevila jako nedostupná. Tento systém je také velmi nepraktický – pokud bychom přidávali klíč pro každé doménové jméno, brzy by mohlo dojít k tomu, že bychom v konfiguraci validujícího resolveru měli klíčů příliš mnoho a údržba by přestala být zvladatelnou.
Způsob druhý – Domain Lookaside Validation
S druhým způsobem přišla společnost ISC – autor DNS serveru Bind. Mechanismus DLV funguje tak, že se validující resolver podívá „bokem“. V praxi to funguje tak, že nejprve se validující resolver snaží vytvořit řetěz důvěry mezi podpisem a nakonfigurovanými pevnými body důvěry – tedy hledá DS záznam v nadřazené zóně. Pokud DS záznam není v nadřazené zóně nalezen, připojí ke jménu validované domény název DLV registru a hledá DLV RR záznam pro tuto nově vzniklou kombinaci. V případě nálezu DLV záznamu je výsledek dotazu použit stejně, jako kdyby měl validující resolver k dispozici DS záznam v nadřazené zóně.
Komunikace validujícího resolveru s DLV registrem může vypadat například takto:
1. Zóna .cz je podepsaná a v DLV registru
2. Je vytvořen DNSSEC dotaz na A záznam jména www.dnssec.cz a je poslán kořenovým nameserverům
3. Není nalezen DS záznam v kořenové zóně pro zónu .cz
4. Validující resolver se zapnutou DLV validací bude hledat DLV záznam cz.dlv.isc.org
;; ANSWER SECTION:
cz.dlv.isc.org. 3319 IN DLV 7978 5 1 (
9B6C3898470914CDDA98D0CC001688CB32C17A09 )
cz.dlv.isc.org. 3319 IN RRSIG DLV 5 4 3600 20090228094531 (
20090129094531 9912 dlv.isc.org.
GyjKws8ZveMSbDqL/DboeC7MHQmiqTiZDijMoaZd3B2k
n9UxJPXlG9TPxDH2Ve5EgNOEPIV1Bm5YUzJ64JQFwF/l
iIBsAMIFu5k41hj5oODsTuLryrUcKMBMCgJfJWBDxi02
BXcRxfXUbbbCmI5fwEOFRsgDar/aKB6iVW3/Weg= )
5. Tento DLV záznam bude použit jako DS záznam pro zónu cz
6. Je vytvořen DNSSEC dotaz na A záznam jména www.dnssec.cz a je poslán autoritativním serverům pro zónu .cz
7. V zóně .cz je nalezen DS záznam pro zónu dnssec.cz
8. Tento DS záznam je použit pro validaci podpisu A záznamu v zóně dnssec.cz.
Konfigurace DLV registru pro DNS server Bind 9.3.3 a vyšší vypadá takto:
options {
// zapneme DLV validaci
dnssec-lookaside . trust-anchor dlv.isc.org.;
};
trusted-keys {
dlv.isc.org. 257 3 5
"BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2
brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+
1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
QktUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt
TDN0YUuWrBNh";
};
V sekci options řekneme, od jakého místa v DNS hierarchii se má použít alternativní validace přes DLV registr a jaký DLV registr budeme používat. V současné době je v provozu pouze jeden DLV registr – provozuje ho společnost ISC na adrese dlv.isc.org. Aby mohly být DLV záznamy považovány za důvěryhodné, je zapotřebí, aby k nim také vedla cesta přes řetěz důvěry. Proto je zapotřebí do konfigurace přidat aktuální klíč DLV registru. Pozor! Klíč použitý v příkladu byl aktuální v době psaní tohoto článku, a tento klíč se v pravidelných intervalech mění. Platný klíč vždy najdete na adrese secure.isc.org/ops/dlv/. Na stejné adrese také najdete podrobný popis toho, jak používání DLV registru nakonfigurovat.
Pro DNS server Unbound 1.1.0 a vyšší je konfigurace ještě jednodušší, ze stránek secure.isc.org/ops/dlv/ si stáhneme aktuální klíč pro zónu dlv.isc.org:
$ wget -O /etc/unbound/dlv.isc.org.key http://ftp.isc.org/www/dlv/dlv.isc.org.key
Na výše zmíněných stránkách je dostupný i PGP podpis tohoto klíče a je velmi vhodné si jej ověřit.
Do konfigurace unbound.conf pak přidáme jednu řádku v sekci server:
# dlv-anchor-file: "/etc/unbound/dlv.isc.org.key"
Načteme novou konfiguraci a DLV validace je tímto zapnuta.
Velká výhoda DLV registru je množství domén, které začnete validovat ve chvíli, kdy DLV registr začnete používat. Mezi nevýhody bych uvedl – žádná kontrola nad tím, jaké klíče chcete nebo nechcete validovat, a provoz jediného DLV registru není v rukou autorit, které mají na starosti správu kořenové zóny, ale konsorcia ISC. DLV registr také není příliš škálovatelný – DLV klíče sice lze rozdělit do více podzón, neexistuje automatizované rozhraní pro přidávání/měnění/mazání klíčů z DLV registru. I přes to všechno je DLV registr dobrým způsobem, jak začít s validací DNSSEC podpisů – v ideálním případě musíte hlídat pouze jeden klíč v konfiguraci. Bohužel v DLV registru nejsou ani všechny podepsané TLD domény – např. švédská doména .se v DLV registru uložena není, a pokud ji chcete validovat, musíte přidat její klíč do konfigurace ručně.
Způsob třetí – IANA
Třetí způsob v sobě zahrnuje celkem dvě metody – nicméně obě jsou provozovány organizací IANA, která je (zjednodušeně řečeno) zodpovědná za obsah kořenové zóny. IANA již nějakou dobu provozuje testovací prostředí na podepisování kořenové zóny a toto testovací prostředí je veřejně přístupné. Naleznete jej na adrese ns.iana.org/dnssec/status.html. Na těchto stránkách lze také najít ukázkovou konfiguraci pro Bind 9:
options {
...
dnssec-enable yes;
dnssec-validation yes;
...
};
zone "." {
type hint;
file "dnssec.root";
};
trusted-keys {
"." 257 3 5 "AwEAAff8EiNa/S3wovNzPUmuBqe1pSjnNoen
cXDNMpmjTgngGMPct+8KDKxM6FwvPSRx15gN
RyRQfzSPU0WshDNkBV2TMtVpzqn/dsurbmTo
ixRzLyLK2Kd2adg5o5yS/gaTgCo0HVBmIruS
N3FVI2ugCWJBFLkFGHLvMJ0BTSYVqWGwQIzp
EPKCbKN+L9nrLcvJRCWG59Yq6BUsSEKlzSK3
jMhYQs6y5IiCGAVol+3VyjN93/lXkeUG6u7d
lQsyiY9fxfeUvmn004y0TjAgjZqdwKZB0K9M
A7qcALG3Tw2TXEdQsn9aY3DzNii3YEBidzER
mY7n4hIUri1r59MnuNJq2x0=";
"." 257 3 5 "AwEAAb+qUOkdZKCP0Qn/4TxJy2XD07xOckKj
wwAHOE/Hn3rLGy0RpmVYCOrmJbVtfyC6i8SQ
sRRKj6YUVlNg7EJ9gjK6rTiDlYMxSc0hFsoG
I8qfAfmsjwClVh86rSIJvruvbcRsQURp/gvJ
EdOaEHlA3JEIHS3cRR5AjKeF1IQdsGYtJMBM
2VMtrgHKgOPZjzfM6bPyg+H9uMBwOm2HkSiE
geAw2vXEHp0eNM2sOxUQMYYPkoywa28oxP4v
dUI7ht4I8etlq3gNCEuBJjV4347ZQ0VHIwDw
JSVmYBzc4f3REfEZS7h6fR33wPVQIw9NNi9p
Cy7JRqzEGwHVft/re6SRqE0=";
};
Soubor dnssec.root pak bude obsahovat následující obsah:
. 3600 IN NS ns.iana.org. ns.iana.org 3600 IN A 208.77.188.32
Touto konfigurací způsobíme přepsání konfigurace kořenových nameserverů na pouhý jeden. V případě výpadku toto serveru by (po vypršení záznamů ve vyrovnávací paměti resolveru) přestalo DNS být dostupné. Proto je tato konfigurace vhodná pouze pro testovací účely.
Žhavou novinkou chladného měsíce ledna je spuštění beta verze Interim Trust Anchor Repository na adrese itar.iana.org. ITAR je dočasné úložiště klíčů pro kořenovou zónu do doby než bude podepsaná kořenová zóna a DS záznamy budou uloženy přímo v ní. Z toho plynou určitá omezení – klíče do ITARu můžou vkládat pouze TLD operátoři. V současné době je ITAR v testovacím provozu a obsahuje klíče pro tři TLD – švédskou, brazilskou a také tu naši českou. Použití klíčů z ITAR registru pro DNS server Bind je v současnosti poněkud krkolomné, protože ITAR negeneruje soubor ve formátu trusted-keys, tudíž jeho použití znamená trochu toho skriptování na konverzi z DS záznamů do konfigurace Bindu. Master soubor je poskytován i ve speciálně naformátovaném souboru XML, který bude velmi snadné přes XSLT transformaci dostat do požadovaného formátu ve formě trusted-keys {}; direktivy.
Unbound podporuje formát souboru anchors.mf. Tento soubor je ke stažení na výše uvedených stránkách (včetně synchronizace přes protokol rsync):
$ rsync -rvP rsync://rsync.iana.org/itar/ /etc/unbound/itar/ $ cd /etc/unbound/itar/ && gpg --verify anchors.mf.sig anchors.mf gpg: Signature made Sun 01 Feb 2009 01:45:06 AM CET using DSA key ID 81D464F4 gpg: Good signature from "IANA Trust Anchor Repository <itar@iana.org>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 1642 571A 578F 0DF2 6F82 785F F47D FB30 81D4 64F4
Zapnutí validace se provede následující direktivou:
trust-anchor-file: "/etc/unbound/itar/anchors.mf"
Opět i o této službě platí, že je zatím vhodná k použití pouze v testovacím provozu. V případě použití v produkčním prostředí bych doporučil spíše ruční kontrolu nově stažených klíčů a následné úpravy v konfiguraci DNS serverů dělat také ručně. Nicméně předpokládám, že v průběhu první poloviny tohoto roku dojde ke stabilizaci a spuštění repozitáře ITAR do produkce.
To je pro dnešek vše a v příštím díle seriálu o technologii DNSSEC se dostaneme k již avizovanému hledání problémů v DNSSEC validaci.
Autor je technickým ředitelem sdružení CZ.NIC.
ČLÁNKY DO MAILU