Provozování podepsané domény je poněkud náročnější na údržbu. To proto, že podpisy mají časově omezenou platnost. Pokud není zóna včas znovu podepsána, stane se nevalidní. Navíc, ačkoli to není přímo vyžadováno, je vhodné čas od času vyměnit klíče, kterými jsou podpisy generovány. Celé této problematice se podrobně věnují starší články DNSSEC na autoritativním serveru a Údržba DNSSEC klíčů.
Právě k údržbě podepsané DNS zóny slouží projekt OpenDNSSEC. Z vnějšího pohledu jde o software, který na vstupu přebírá nepodepsané zónové soubory, a na výstupu generuje podepsané, přímo vhodné pro načtení autoritativním DNS serverem. Sám se přitom stará o generování a pravidelné obměny klíčů a podpisů.
Architektura OpenDNSSEC
Jednotlivé komponenty systému OpenDNSSEC popisuje následující obrázek z dokumentace:
Veškeré klíče, které OpenDNSSEC používá, jsou uloženy v hardwarovém bezpečnostním modulu (HSM). Používá se standardizované rozhraní PKCS#11, takže je možné použít zařízení od různých výrobců. Pro účely testování či malých domén, kde by bylo použití HSM zbytečný luxus, existuje podprojekt SoftHSM, implementující softwarové HSM, které ukládá klíče v databázi SQLite.
Vlastní podepisování zónových souborů má na starosti komponenta Signer Engine. Činí tak na základě objednávek komponenty KASP Enforcer. Jejím úkolem je vynucovat nastavené politiky klíčů a podpisů (Key and Signing Policy). Když to politika vyžaduje, automaticky vygeneruje nové klíče, provede výměnu klíčů a na závěr staré vymaže. V případě výměny KSK, kdy je zapotřebí vložit nové klíče do nadřazené zóny, úkoluje pomocí logů administrátora.
Před tím, než jsou podepsané zónové soubory vystaveny v systému DNS, provede KASP Auditor jejich validaci. Představuje doplňkovou ochranu před chybami v zónových souborech a implementaci předchozích komponent. Teprve v případě, že auditor shledá zónový soubor validní, v souladu politikou i zdrojovým souborem, je předán DNS serveru.
Instalace
OpenDNSSEC je k dispozici ve formě balíčků pro hlavní distribuce, instalace by tedy neměla představovat zvláštní problém. Drobnou potíž může představovat jen instalace úložiště SoftHSM, je třeba přidělit souboru s databází klíčů správná oprávnění, aby k němu mohl přistupovat jen uživatel, pod jehož účtem běží OpenDNSSEC. Můžeme použít třeba doporučený postup distribuce Gentoo. Nejprve nakonfigurujeme cestu k databázovému souboru v souboru /etc/softhsm.conf:
0:/var/lib/opendnssec/softhsm_slot0.db
Následně SoftHSM inicializujeme a změníme vlastníka databázového souboru:
# softhsm --init-token --slot 0 --label OpenDNSSEC The SO PIN must have a length between 4 and 255 characters. Enter SO PIN: 1234 The user PIN must have a length between 4 and 255 characters. Enter user PIN: 1234 The token has been initialized. # chown opendnssec:opendnssec /var/lib/opendnssec/softhsm_slot0.db
Konfigurace
Konfigurační soubory se nachází standardně v cestě /etc/opendnssec/. Hlavní konfigurační soubor conf.xml obsahuje rozumné výchozí hodnoty, takže jej nejspíše nebude nutné příliš upravovat, tedy za předpokladu, že vystačíte s použitím SoftHSM. Za zmínku dále stojí parametr Interval v konfiguraci enforceru. Určuje, jak často bude kontrolováno, zda by si zóna nezasloužila nové podepsání nebo výměnu klíče.
Nastavení politiky klíčů a podpisů se skrývá v souboru kasp.conf. Voleb je poměrně mnoho a detailní popis by zřejmě vydal na samostatný článek. Důležité je, že výchozí politika je nastavena rozumně až paranoidně, takže podpisy jsou platné jen 7 dnů (běžně se používá 30 dnů), tři dny před koncem platnosti se obnovují. Pro autentizaci popření existence záznamů se používá moderní NSEC3, takže nehrozí vyzrazení obsahu zóny procházením NSEC řetězců. Životnost klíčů ZSK je nastavena na 14 dnů, v případě KSK je to jeden rok. Součástí politiky je také nastavení hodnot TTL pro záznamy, které podepisováním vzniknou, stejně jako informace o TTL u DS záznamů nadřazené domény – to proto, aby mohl enforcer správně načasovat výměnu KSK.
Další konfigurační soubor zonelist.xml obsahuje seznam zón, které bude OpenDNSSEC obhospodařovat. Nemusíme jej však konfigurovat ručně, zóny je možné zadávat i odebírat interaktivně za běhu.
První spuštění
Pro evidenci konfigurace a stavu klíčů a podpisů u jednotlivých zón program používá databázi SQLite. Tu je třeba před prvním spuštěním vygenerovat. Nejdříve ale zkontrolujeme syntaktickou korektnost konfiguračních souborů:
# ods-kaspcheck /etc/opendnssec/conf.xml validates /etc/opendnssec/kasp.xml validates # ods-ksmutil setup *WARNING* This will erase all data in the database; are you sure? [y/N] y SQLite database set to: /var/lib/opendnssec/kasp.db fixing permissions on file /var/lib/opendnssec/kasp.db zonelist filename set to /etc/opendnssec/zonelist.xml. kasp filename set to /etc/opendnssec/kasp.xml. Repository SoftHSM found No Maximum Capacity set. RequireBackup NOT set; please make sure that you know the potential problems of using keys which are not recoverable /etc/opendnssec/conf.xml validates /etc/opendnssec/kasp.xml validates Policy default found Info: converting P1Y to seconds; M interpreted as 31 days, Y interpreted as 365 days
Příkaz setup je možné spustit pouze jednou, při dalším spuštění by celou databázi přepsal a ztratila by se informace o doposud vytvořených klíčích a podpisech. Pokud později změníme konfiguraci, je třeba změny importovat do databáze příkazem ods-ksmutil update <conf|kasp|zonelist|all>.
Je-li databáze vytvořena, můžeme spustit enforcer a signer, buď pomocí init skriptů, nebo přímo příkazem ods-control start.
Přidání zónových souborů
Pokud se OpenDNSSEC úspěšně spustí, můžeme přidat zónové soubory. Nejjednodušší je, pokud se držíme konvence, že zónové soubory se jmenují stejně jako zóna, kterou reprezentují. Nejprve soubor bez podpisu vložíme do adresáře /var/lib/opendnssec/unsigned. Pak jej zavedeme do konfigurace pomocí:
# ods-ksmutil zone add -z example.net -p default zonelist filename set to /etc/opendnssec/zonelist.xml. SQLite database set to: /var/lib/opendnssec/db/kasp.db Imported zone: example.net
Kromě zavedení zóny v databázi se také aktualizuje konfigurační soubor zonelist.xml, takže obsah konfiguračních souborů zůstává konzistentní s databází. Zóna se však ihned nepodepíše, nejprve si ji musí všimnout enforcer, který se probouzí v intervalech, konfigurovaných v souboru conf.xml (viz výše). Tuto akci můžeme urychlit restartem enforceru.
Provedeme-li později v zónovém souboru změnu, je třeba vždy požádat signer o znovupodepsání příkazem:
# ods-signer sign example.net connecting to /var/run/opendnssec/engine.sock Zone scheduled for immediate resign
Napojení na BIND
Podepsaný zónový soubor, který vznikne v adresáři /var/lib/opendnssec/signed je možné přímo předat autoritativnímu DNS serveru. V případě BINDu přidáme do konfiguračního souboru:
zone "example.net" {
type master;
file "/var/lib/opendnssec/signed/example.net";
};
Dále je důležité zajistit, aby se DNS server vždy dozvěděl, že je k dispozici nová verze podepsaného souboru. OpenDNSSEC umí při každém vystavení podepsaného zónového souboru zavolat příkaz, zadaný v konfiguračním souboru conf.xml
<NotifyCommand>/usr/sbin/rndc reload %zone</NotifyCommand>
Nezapomeňte, že po úpravě konfiguračního souboru je třeba promítnout změny do databáze příkazem ods-ksmutil update conf a také to, že daný příkaz se spouští s efektivním oprávněním uživatele, pod kterým běží signer. Aby mohl pomocí utility rndc ovládat BIND, je potřeba udělit mu práva ke čtení souboru /etc/bind/rndc.key, například přidáním souboru do skupiny opendnssec.
Spolupráce s nadřazenou zónou
Pokud OpenDNSSEC dospěje k názoru, že by bylo vhodné vyměnit KSK a tedy i podpis v nadřazené zóně, upozorní na to v syslogu:
ods-enforcerd: WARNING: KSK Retirement reached; please submit the new DS for example.net and use ods-ksmutil key ds-seen when the DS appears in the DNS.
To se týká i prvního zavedení nově podepsané zóny. Potřebný klíč připravený k publíkaci v registrech, které používají tzv. KEYSETy (například registr domény cz), získáme níže uvedeným příkazem. Pro registry, které přijímají přímo DSSETy tyto získáme přidáním přepínače --ds.
# ods-ksmutil key export --zone example.net --keystate READY
SQLite database set to: /var/lib/opendnssec/db/kasp.db
;ready KSK DNSKEY record:
example.net. 3600 IN DNSKEY 257 3 7 AwEAA…TeDj1494j/0= ;{id = 6489 (ksk), size = 2048b}
V případě rotace klíčů můžeme předchozí DS záznamy smazat. Poté, co se DS záznamy objeví v nadřazené zóně, je nutné tuto informaci předat enforceru použitím příkazu:
# ods-ksmutil key ds-seen -z example.net -x 6489 SQLite database set to: /var/lib/opendnssec/db/kasp.db Found key with CKA_ID d61a44f44ad106c767a330bf9ae43f15 Key d61a44f44ad106c767a330bf9ae43f15 made active Error: retiring a key would leave no active keys on zone, skipping...
Poslední chyba nás při první publikaci nemusí znepokojovat, enforcer se snaží automaticky vyřadit nejstaší klíč, což je však v případě publikace prvního klíče zároveň ten nejnovější. Při rotaci klíčů toto funguje korektně.
Závěrem
Vždy zkontrolujte, zda jsou podepsané soubory totožné s těmi, které nabízí DNS server a to včetně všech slave serverů. Enforcer provádí časování výměny klíčů na základě okamžiku jejich vystavení v souboru (maximální zdržení při kopírování na slave servery se konfiguruje v politice), takže pokud některý z DNS serverů nabízí starou verzi zóny, stane se zóna po čase nevalidní.
OpenDNSSEC dokáže také zavolat zvolený příkaz při potřebě publikace nových DS záznamů v nadřazené zóně. Pokud váš registrátor podporuje nějaký způsob strojové editace doménových záznamů, je možné i výměnu KSK plně automatizovat.
Další čtení
- Seriál DNSSEC a bezpečné DNS
- CZ.NIC Labs: DNSSEC za pět minut
- Lupa: NSEC3 – DNSSEC, který nic nevyzradí
- Reloading signed zones into BIND – automatické generování konfigurace BINDu při podepsání nové zóny
