přejít na obsah přejít na navigaci

Linux E X P R E S, Automatická správa sad klíčů pro DNSSEC

IT Systems - Alza Media (Publero)

Automatická správa sad klíčů pro DNSSEC

klice_1.png

Jaromír Talíř ukázal na konferenci IT 16.2, jaké jsou aktuální možnosti pro automatickou správu sad klíčů pro technologii DNSSEC.


reklama

V době konání konference Internet a Technologie 16.2 se podíl používání DNSSEC u českých domén blížil k 50 %, v dalších dnech byla tato hranice překročena. Zkrátka DNSSEC je už dnes zcela běžnou záležitostí. To se ale nedá říct o dalších věcech, které s tím souvisejí. Jaromír Talíř na konferenci hovořil o automatické správě sad klíčů, protože to je něco, o čem zatím obecně chybí byť jen povědomí.

Jaromír Talíř při své přednášce Jaromír Talíř při své přednášce

Režie DNSSEC

DNSSEC bohužel neznamená, že se jen něco nainstaluje, zapne a je hotovo. Právě naopak, je to nový způsob práce, přinášející nové povinnosti. Každý DNS záznam musí být podepsán a tento podpis má – zcela záměrně – jen omezenou životnost (standardně 30 dní). Podpisy na záznamech je tedy potřeba pravidelně obnovovat.

To lze dělat automaticky a také se to tak běžně dělá. Ovšem i klíče, kterými se záznamy podepisují (zone signing key, ZSK), je potřeba obměňovat – v rámci tzv. bezpečnostní hygieny (s přechody na kvalitnější algoritmy a delší klíče, ale i „pro jistotu“, aby se stejné klíče nepoužívaly příliš dlouho; eliminují se tím rizika vyplývající z toho, že se klíče mohly i jen teoreticky dostat do neoprávněných rukou).

Není to tak dávno, co to s tou automatizací těchto činností nebylo až tak úplně jednoduché. Nyní jsou ale k dispozici nástroje, například OpenDNSSEC, „in-line“ podepisování v serveru BIND nebo podpora v serveru Knot DNS.

Součástí obměny klíče je zcela nezbytně jeho propagace do nadřazené zóny. Řetězec důvěry od kořene ke koncovým záznamům musí být nepřerušený, nadřazená zóna tedy musí znát klíče všech podřízených zón. A tady už nastává komplikace – nadřazenou zónu totiž může spravovat (a na rozhraní mezi doménami 2. úrovně a TLD také spravuje) někdo jiný než zóny pod ní.

Propagace klíčů do nadřazené zóny

„V tradičním modelu správy domén, který se označuje jako 3R model (registry–registrar–registrant, tedy registr–registrátor–držitel domény), chybí DNS správce,“ otevírá tuto problematiku Jaromír Talíř. „Tedy člověk, který provozuje DNS server pro konkrétní doménu a stará se například o to podepisování klíčů. A zatímco existují poměrně stabilizované vazby například mezi registrátorem a registrem, kde je protokol EPP, mezi držitelem a registrátorem je [komunikace] prostřednictvím nějakých webových formulářů.“

Schéma propagace klíčů do nadřazené zóny (zdroj: prezentace Jaromíra Talíře) Schéma propagace klíčů do nadřazené zóny (zdroj: prezentace Jaromíra Talíře)

Správcem DNS bývá často přímo registrátor – tam je situace poměrně jednoduchá. Ale někdy je správce někdo jiný, ten pak musí kontaktovat držitele domény a zajistit, například pomocí zmíněného formuláře, propagaci veřejného klíče nebo jeho otisku „nahoru“. Proto je žádoucí se této ruční práce zbavit.

Dlouho pro to nic neexistovalo. V září 2014 byl ale dokončen dokument RFC 7344, který specifikuje automatizaci těchto procesů. Přidává nové typy záznamů: CDS a CDNSKEY. Ty mají stejný obsah jako záznamy DS a DNSKEY, ale slouží k provedení jejich změn. Změny se pak detekuji buď na základě periodického procházení nebo na vyžádání.



Podpora v serverech a v registru

Plnou podporu v tuto chvíli nemá žádná běžná implementace serverů. BIND 9.11 má podporu částečnou (s jistým úsilím použitelnou), obsahuje automatizační nástroj dnssec-keymgr. Na přidání do Knot DNS se pracuje, mělo by být hotovo v první polovině roku 2017. OpenDNSSEC podporu nemá a zatím není známo, kdy ji mít bude.

Podpora je ovšem potřeba i na straně registru, tedy v případě české národní domény v systému FRED, na kterém registr běží. Ta není tak úplně triviální. „Když jsme registr vytvářeli, dali jsme tam takový relativně nový koncept, který nebyl až tak rozšířený v té době – a to, že jsme vytvořili speciální objekt nazvaný NSSet, který sdružoval nameservery, které jsou přiřazené k té doméně. A když jsme v roce 2008 implementovali DNSSEC do tohoto systému, použili jsme stejný koncept,“ vysvětluje Jaromír Talíř.

Registrační systém FRED a DNSSEC (zdroj: prezentace Jaromíra Talíře) Registrační systém FRED a DNSSEC (zdroj: prezentace Jaromíra Talíře)

Vznikl tak objekt KeySet (sada klíčů) a ten je navázán na doménu. Usnadňuje to práci velkým hosterům, kteří mají i tisíce domén, které potřebují podepisovat. Administrativní změny tak lze provádět jediným příkazem. KeySet obsahuje několik klíčů (DNSKEY), kontakty na správce klíčů, lze ho sdílet mezi více doménami a delegační záznamy se generují na straně registru. KeySet má určeného registrátora, ale lze ho převádět (jako třeba domény nebo kontakty), registrátor ho spravuje přes rozšíření EPP.

Scénáře nasazení RFC 7344

Existuje několik scénářů, jak automatizaci nasadit. Jednak mohou vše zajišťovat registrátoři (bez vazby na registr), v dalším scénáři se může o rotaci klíčů starat registr a dělat změny v objektech registrátorů a konečně ve třetím scénáři se registr (CZ.NIC) stane sám registrátorem pro tento druh objektů.

Při použití prvního scénáře mohou registrátoři zavést podporu už teď, beze změny implementace registru. CZ.NIC plánuje pohovořit s registrátory na společném setkání, kde se ukáže, jak se registrátoři k tomuto scénáři staví.

Druhý scénář by znamenal nutnost změny pravidel pro registrace domén, protože v současné verzi za obsah objektů odpovídají registrátoři. Z hlediska technického by bylo potřeba implementovat podporu v systému FRED, přičemž by měl registrátor možnost nastavit u sady klíčů příznak, kterým by delegoval pravomoc rotace klíčů na CZ.NIC.

Scénáře nasazení RFC 7344 (zdroj: prezentace Jaromíra Talíře) Scénáře nasazení RFC 7344 (zdroj: prezentace Jaromíra Talíře)

Třetí scénář je podobný tomu, jak jsou již dnes řešeny kontakty u služby mojeID, kde je CZ.NIC speciálním registrátorem a uživatel služby má možnost provádět změny přes Doménový prohlížeč. Registrátor domény ovšem musí mít možnost KeySet přidat nebo změnit.

Implementace v systému FRED

Pro systém FRED v tuto chvíli existuje prototypové řešení, které využívá knihovnu jazyka Python z balíčku fred-client a nástroj dnspython. Bude potřeba vyřešit sdílené sady klíčů (pro více domény), a také počáteční vložení klíče, resp. smazání klíče. To RFC 7344 vůbec neřeší; vznikl ale už draft specifikace, takže řešení je na cestě. CZ.NIC plánuje, že během roku 2017 bylo na straně registru měla být hotova funkční podpora pro rotaci klíčů.

Celou přednášku můžete vidět na videozáznamu.

Nahoru

(Jako ve škole)
 

Top články z OpenOffice.cz

Přidat téma diskuse

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích a pravidlech najdete v nápovědě.
Diskuzi můžete sledovat pomocí RSS kanálu rss



 
 

Lukáš Jelínek

Lukáš Jelínek

Šéfredaktor LinuxEXPRESu a OpenOffice.cz. Vystudoval FEL ČVUT v oboru Výpočetní technika. Žije v Kutné Hoře a podniká v oblasti informačních technologií. Ve volném čase rád fotografuje, natáčí a stříhá video a také se věnuje (v Čechách poměrně málo známému) powerkitingu.


  • Distribuce: Debian, Kubuntu
  • Grafické prostředí: KDE
  • Hodnocení autora: ***

| proč linux | blog