Domain Name System Security Extensions
DNSSEC (zkratka pro Domain Name System Security Extensions) je v informatice sada specifikací IETF, které umožňují zabezpečit informace poskytované systémem DNS v sítích IP (tj. na Internetu) proti podvržení (tzv. spoofing) a úmyslné manipulaci. Klient (resolver) může pomocí elektronického podpisu ověřit původ dat, jejich integritu (neporušenost) nebo platnost neexistence záznamu, ale nezajišťuje zašifrovaný přenos dat (tj. utajení) a nezaručuje jejich dostupnost.
Příklad podvržení DNS
[editovat | editovat zdroj]Běžný DNS slouží k překladu doménových jmen na adresy IP (a zpět), ale nemá žádnou ochranu proti napadení. Pokud je do webového prohlížeče zadána adresa www.banka.cz, může být přeložena na podvrženou IP adresu, přičemž v adresním řádku prohlížeče bude stále www.banka.cz, takže uživatel nepostřehne, že prohlížeč ve skutečnosti zobrazil podvrženou stránku (viz Phishing). Tomuto útoku se lze bránit tak, že www.banka.cz použije pro komunikaci zabezpečený protokol HTTPS, avšak ne každý uživatel může tento rozdíl postřehnout (navíc i toto se dá obejít, více viz HTTPS).
Jak DNSSEC funguje?
[editovat | editovat zdroj]DNSSEC používá asymetrické šifrování (jeden klíč pro zašifrování a druhý klíč na dešifrování). Podobný princip se používá pro šifrování a elektronické podepisování elektronické pošty (OpenPGP, S/MIME). Držitel domény, která používá DNSSEC, vygeneruje privátní a veřejný klíč. Svým privátním klíčem pak elektronicky podepíše technické údaje, které o své doméně do DNS vkládá. Pomocí veřejného klíče, který je uložen u nadřazené autority jeho domény, je pak možné ověřit pravost tohoto podpisu. I na úrovni domény .cz (tzv. národní doména, top-level doména, TLD) jsou technická data v DNS elektronicky podepsána a veřejný klíč k tomuto podpisu je opět správcem registru (sdružením CZ.NIC) předán nadřazené autoritě (celosvětové kořenové servery DNS). Vytváří se tak hierarchie, která zajistí důvěryhodnost údajů, pokud není v žádném svém bodě porušena a všechny elektronické podpisy souhlasí.
Grafické znázornění
[editovat | editovat zdroj]
Na obrázku vpravo je grafická reprezentaci validace DNSSEC. K doméně si musíme najít záznam typu DS u rodiče. Ten následně validovat pomocí rodičovského ZSK (který je podepsaný rodičovským KSK) a pokud rodič není kořenový server, pak tento proces opakovat. Kořenový server nad sebou již nikoho nemá, bere se tedy jeho KSK klíč jako validní.
Můžete si všimnout, že vedle kořenového serveru je větev s tzv. záznamem DLV. Jedná se o dodatečný bezpečnostní záznam pro ty domény, které by chtěly být DNSSEC validní, avšak jejich rodič DNSSEC nepodporuje. Tímto, místo DS záznamu u rodiče, je možno najít záznam potřebný pro validaci KSK domény na oficiálních serverech DNSSEC.
Jako další věc, která vás může zaujmout, je DNSKEY, který zdánlivě nic nepodepisuje, ale přesto je na serveru uložen. Některé domény mají více klíčů většinou z důvodu jejich omezené platnosti (každý klíč je platný pouze pro určité časové období, toto období je uvedeno přímo u klíče). V případě, že se blíží konec platnosti jednoho klíče, je třeba mít již nový připravený, aby správce mohl dát svému rodiči nový, platný klíč a změna klíčů tak proběhla takříkajíc hladce.
Prvky používané v DNSSEC
[editovat | editovat zdroj]DNSKEY
[editovat | editovat zdroj]Každá doména, pokud používá DNSSEC, má 2 typy podpisových klíčů. Každý klíč má veřejnou a privátní část. Jelikož DNSSEC je založen na asymetrickém šifrování, jsou data zašifrována privátní částí (není dostupná veřejnosti) a lze je rozšifrovat pouze veřejnou částí klíče.
- Zone Signing Key (ZSK)
- Slouží k podpisu vlastních dat (tedy dat této domény, která server DNS poskytuje v odpovědích na dotazy klientů), čímž zajistí, že pokud jsou podvržena, jste schopni to zjistit
- Key Signing Key (KSK)
- Slouží pro podepsání ZSK, hash veřejné části tohoto klíče je zároveň uložen u rodičovské domény. Také se označuje jako DNSKEY-SEP (Secure Entry Point)
Resource Record Signature(RRSIG)
[editovat | editovat zdroj]Pokud sloučíme všechny záznamy daného typu a následně z nich vytvoříme otisk a tento otisk pak zašifrujeme pomocí privátní části ZSK (nebo KSK), dostaneme RRSIG záznam pro daný typ (např. RRSIG over AAAA). Chceme-li tedy ověřit, že daný záznam je autentický (nebyl změněn třetí stranou), pak použijeme právě RRSIG pro porovnání otisků.
Delegation Signer (DS)
[editovat | editovat zdroj]Údaj u rodičovské domény obsahující hash veřejné části KSK (viz dále) potomka, který je rodičem podepsán. Díky tomuto údaji jsme schopni ověřit autenticitu potomka. Podrobné informace o tomto údaji lze nalézt v RFC 3658.
Řetězec důvěry
[editovat | editovat zdroj]Jedná se v podstatě o seznam záznamů, které byly použity pro validaci domény DNSSEC. Kořenová doména má veřejnou část svého KSK záznamu na oficiálních stránkách, tento klíč pak validuje přes RRSIG její ZSK, který validuje DS záznam o potomku, který validuje KSK potomka a takto tento řetězec pokračuje, až se dostaneme na konec (za předpokladu, že je testovaná doména validní).
Automatická správa klíčů (CDS a CDNSKEY)
[editovat | editovat zdroj]Aby se usnadnila správa klíčů v nadřazené zóně, byly ve standardech RFC 7344 a RFC 8078 přidány dva nové typy DNS záznamů – CDS a CDNSKEY. Provozovatel nadřazené zóny může procházet zóny podřízených domén, a pokud v nich najde některý z uvedených typů záznamů, sám do zóny přidá DS záznam. Přidání DS záznamu může být odloženo v čase – např. provozovatel TLD .cz CZ.NIC posílá před automatickým přidáním DS záznamu několik e-mailových upozornění provozovateli domény, aby mohl reagovat, pokud by CDS nebo CDNSKEY záznam byly přidány omylem[1].
Automatická správa klíčů je implementována v TLD .cz[2] a .ch.
Historie DNS(SEC)
[editovat | editovat zdroj]- 1973 až 1983 – centralizovaný systém.
- 1983 – John Postel a Paul Mockapetris sepisují základy DNS (RFC881,882,883), první DNS server – Jeeves
- 1986 – DNS jako IETF standard: RFC1034 a RFC1035
- 1988 – DNS se začíná prosazovat, první verze BINDu
- 1990 – Steven Bellovin objevuje vážnou chybu v DNS, publikování této chyby odloženo na 1995, Autentizace přístupů pomocí jména počítačů (rsh, rlogin)
- 1995 – Steven Bellovin publikuje svojí zprávu z roku 1990, IETF začíná diskutovat o zabezpečení DNS
- 1997 – publikováno RFC2065 – předchůdce RFC2535
- 1999 – publikováno RFC2535 – první verze DNSSEC, BIND 9 implementuje DNSSEC
- 1999 až 2001 – nasazení DNSSECu stagnuje
- 2001 – ukazuje se, že DNSSEC je nevhodný k nasazení: podepsání záznamů vyžadovalo komplexní komunikaci s nadřazeným serverem, změna klíče u nadřazeného serveru vyžadovala změnu ve všech podřízených zónách, pro vyřešení problémů byla navržena nová verze (draft), která definovala DS záznam a zjednodušila tak komunikaci
- 2002 až 2003 – implementace v BIND 9, první testu ukazují, že 2535bis je použitelné pro nasazení
- 2004 – podpora 2535bis v BIND 9.3 a NSD2, čeká se na standardizaci
- 2005 – publikováno jako RFC4033, RFC4034 a RFC4035, Švédsko jako první podepisuje svoji zónu (doména .se)
- 2007 – na konferenci v Tallinnu se RIPE domlouvá na otevřeném dopise pro ICANN s výzvou k podpisu kořenové zóny
- 2008 – ICANN zveřejňuje svůj záměr podepsat kořenovou zónu v dokumentu DNSSEC @ ICANN[3]
- 2009 – ICANN a Verisign vydávají dokument o postupu podpisu kořenové zóny a požadavky na audit celého procesu[4] a 1. prosince začíná proces podepisování, průběžně se sleduje možný výskyt problémů
- 2010 – dokončen proces podepisování kořenové zóny[5]
Použití
[editovat | editovat zdroj]Mezi inovátory patří Brazílie (.br), Bulharsko (.bg), Česká republika (.cz), Portoriko (.pr) a Švédsko (.se), kteří používají DNSSEC pro své top-level domény. RIPE NCC podepsalo všechny reverzní zóny (tzv. in-addr.arpa záznamy), které byly ověřeny IANA.[6] ARIN také podepisoval reverzní zóny.[7] Prvním ISP byl ve Švédsku TDC. V ČR byl prvním registrátorem, který DNSSEC začal nabízet, Web4U a v současné době je zároveň největším registrátorem DNSSEC domén v celosvětovém měřítku.[8] V roce 2013 vláda ČR přijala usnesení, podle kterého od 1. 7. 2015 musí orgány veřejné správy zabezpečit všechny jimi držené domény technologií DNSSEC. Tím se Česká republika stala pravděpodobně první zemí na světě, která se rozhodla pro povinné zabezpečení všech domén veřejné správy.[9]
Všechny projekty s DNSSEC jsou uvedeny na adrese http://www.dnssec.net/projects. Jsou také znázorněny na mapě v Google Maps.[10]
Nástroje
[editovat | editovat zdroj]DNSSEC potřebuje software na straně serveru a také na straně klienta. Zde jsou příklady nástrojů který DNSSEC podporují:
- BIND hodně populární nástroj DNS server. Verze 9.3 implementuje nově DNSSEC-bis (DS záznamy) i když nepodporuje NSEC3 záznamy. BIND 9.6 byl představen v prosinci 2008 a má plnou podporu pro NSEC3 záznamy.
- Drill zvládá také DNSSEC Domain Information Groper -jako nástroj v balíku s ldns.
- Drill extension for Firefox přidává do Mozilla Firefox schopnost zjistit, zda doména může být ověřena pomocí DNSSEC.
- DNSSEC-Tools je SourceForge jejímž cílem je poskytnout snadno použitelné nástroje pro podporu všech typů správců a uživatelů využívající DNSSEC. Nabízí nástroje pro správce autoritativní zóny, autoritativního serveru a Rekurzivního serveru, stejně jako knihovny a nástroje pro vývojáře aplikací patchů pro rozšíření stávající běžné aplikace.
- Zone Key Tool Archivováno 25. 3. 2018 na Wayback Machine. je software určený pro snadnou údržbu zón DNSSEC. Je primárně určen pro prostředí s malým a středním počtu zón a poskytuje plně automatický podpis klíče rolovací zóny stejně jako automatické odstupující zóny.
- Unbound je DNS server, který byl napsán od základu na DNSSEC.
- ve Windows 7, Windows Server 2008 R2 a novějších je stub resolver, který sice DNSSEC respektuje, odpovědi ale nevaliduje.[11][12][13]
- Android DNSSEC nepodporuje, pro rootnutá zařízení lze použít DNSCrypt[14] nebo lze pro konkrétní aplikaci použít vlastní knihovnu[15]
- mysqlBind GPL OSS na DNS ASP nyní také podporuje DNSSEC.
- OpenDNSSEC je určen DNSSEC signatářem nástroj pomocí PKCS#11 pro rozhraní s Hardwarovými ochrannými moduly.
Reference
[editovat | editovat zdroj]- ↑ https://www.root.cz/clanky/druha-faze-automatizovane-spravy-dnssec-klicu/
- ↑ https://www.root.cz/clanky/domena-cz-spousti-jako-prvni-automatickou-spravu-dnssec-klicu/
- ↑ http://www.icann.org/en/announcements/dnssec-paper-15jul08-en.pdf – DNSSEC @ ICANN
- ↑ http://www.ntia.doc.gov/DNS/DNSSEC_Requirements_102909.pdf – Testing and Implementation Requirements for the Initial Deployment of DNSSEC in the Authoritative Root Zone
- ↑ http://www.root.cz/clanky/hotovo-dns-je-podepsano/ – Hotovo: DNS je podepsáno
- ↑ RIPE NCC DNSSEC Policy. www.ripe.net [online]. [cit. 30-12-2009]. Dostupné v archivu pořízeném dne 22-10-2007.
- ↑ https://www.arin.net American registry for internet numbers
- ↑ http://blog.nic.cz/2010/03/02/dnssec-chrani-vice-nez-90-000-domen-cz/
- ↑ http://www.nic.cz/page/1821/vlada-schvalila-povinnost-zavedeni-dnssec-a-rozsirila-podporu-ipv6-/
- ↑ http://www.xelerance.com/dnssec/ Archivováno 9. 1. 2010 na Wayback Machine. – World Wide DNSSEC Deployment
- ↑ Understanding DNSSEC in Windows [online]. Microsoft, October 7, 2009. Dostupné online.
- ↑ DNS Security Extensions (DNSSEC) [online]. Microsoft, October 21, 2009. Dostupné online.
- ↑ https://www.dns-oarc.net/files/workshop-2006/Microsoft-DNSSEC.pdf
- ↑ https://dnscrypt.org/#dnscrypt-android
- ↑ https://github.com/rtreffer/minidns/issues/7
Externí odkazy
[editovat | editovat zdroj]
Obrázky, zvuky či videa k tématu DNSSEC na Wikimedia Commons
Odborné články
[editovat | editovat zdroj]- www.lupa.cz-zde probírají v seriále DNSSEC z obou úhlů pohledu.
- www.root.cz- zde to probírají více do detailů, ve více článcích.
Organizace
[editovat | editovat zdroj]- DNSSEC.CZ - informační stránky k DNSSEC od CZ.NIC
- DNSSEC - DNSSEC informacní stránka o DNSSEC
- DNSSEC-Tools Project
- DNSSEC Deployment Coordination Initiative Archivováno 4. 4. 2018 na Wayback Machine.
- DNSSEC Deployment Team
Standardy DNSSEC
[editovat | editovat zdroj]- RFC 2535 Domain Name System Security Extensions
- RFC 3833 A Threat Analysis of the Domain Name System
- RFC 4033 DNS Security Introduction and Requirements (DNSSEC-bis)
- RFC 4034 Resource Records for the DNS Security Extensions (DNSSEC-bis)
- RFC 4035 Protocol Modifications for the DNS Security Extensions (DNSSEC-bis)
- RFC 4398 Storing Certificates in the Domain Name System (DNS)
- RFC 4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
- RFC 4641 DNSSEC Operational Practices
- RFC 5155 DNSSEC Hashed Authenticated Denial of Existence
- RFC 7344 Automating DNSSEC Delegation Trust Maintenance
- RFC 8078 Managing DS Records from the Parent via CDS/CDNSKEY
V tomto článku byl použit překlad textu z článku Domain_Name_System_Security_Extensions na anglické Wikipedii.
