Akademie DNSSEC Matej Dioszegi 30.11.2011.

Prezentace na téma: "Akademie DNSSEC Matej Dioszegi 30.11.2011."— Transkript prezentace:

1 Akademie DNSSEC Matej Dioszegi matej.dioszegi@nic.cz 30.11.2011

2 Organizace ● Délka školení bez přestávek cca 4 hodiny ● Dvě přestávky ● Občerstvení ● Otázky rovnou v průběhu školení

3 Požadavky ● Znalost Linuxového prostředí ● Znalost TCP/IP ● Znalost DNS ● (Základní) znalost konfigurace Bind 9 ● Základní znalost asymetrické kryptografie

4 Obsah ● DNS – základní pojmy ● Základní principy DNSSEC ● Konfigurace validujícího resolveru ● Konfigurace autoritativního serveru ● Podepsání zóny ● Výměna klíčů ● DNSSEC nástroje ● Hledáme chyby

5 Cíle školení ● Pochopit základní principy DNSSEC ● Umět nakonfigurovat validující resolver ● Umět nakonfigurovat autoritativní server ● Umět podepsat vlastní zónu ● Umět v podepsané zóně vyměnit klíče ● Umět najít chybu, když nefunguje validace

6 Obecně ● Všechny materiály kurzu jsou dostupné na http://public.nic.cz/files/mdioszegi/kurzy/dnssec/ ● Tato prezentace ● Ukázkové konfigurační soubory ● Konfigurační soubory můžete otestovat: ● # named-checkconf /etc/bind/named.conf ● # unbound-checkconf /etc/unbound/unbound.conf ● Znovunačtení konfigurace ● # rndc reload

7 Obecně ● Přístup na root uživatele ● # sudo -s ● Standardní init.d skripty ● start/stop/restart ● Bind 9: /etc/init.d/bind9 ● Unbound: /etc/init.d/unbound

8 DNS – základní pojmy ● Domain Name Space ● Uzel ● Label ● Resource Records ● RR záznam ● RRSet ● Name/DNS Server ● Resolver ● Stub Resolver ● Validující Resolver ● Zóna ● Komunikace ● DNS zpráva ● Dotaz ● Odpověď ● EDNS0 ● Cache

9 DNS dotaz

10 DNS paket Query Response

11 Problémy DNS ● Cache poisoning ● Neustálý vývoj útok/patch ● Chybí „systémové“ řešení ● Steven Bellovin- 1995 – poprvé „poukázal“ na problém ● Kaminsky – 2008 – ani source port randomization nestačí

12 Cache poisoning zdroj: Paul Wouters, Defending your DNS in a post-Kaminsky world, Black Hat Briefings

13 Cache poisoning – random ports TXID – 16 bitov Microsoft DNS – 2500 portov ~2^11 2^16*2^11 = 2^27 ~ 134 mil. zdroj: Paul Wouters, Defending your DNS in a post-Kaminsky world, Black Hat Briefings

14 Birthday attack zdroj: Paul Wouters, Defending your DNS in a post-Kaminsky world, Black Hat Briefings

15 Birthday attack ● Birthday paradox – V skupině 23 lidí je pst. kolize (2 lidi narozeniny v 1 den) > 50 % t = u narozenin 365, u TXID 2^16 N = počet prvků v skupině

16 Cache poisoning - Kaminsky ● Předešlé útoky – když stihl správný NS odpovědět dříve než útočník uhodl TXID a port, útočník musel čekat TTL záznamu na další pokus ● Dan Kaminsky představil elegantní „řešení“ ● Není nutné při neúspěchu čekat ● Využívá odpověď s rcode NXDOMAIN a glue záznamy

17 Cache poisoning - Kaminsky TXID: 0x1234 Query: xyz1.www.banka.cz Awww.banka.cz Answer: 0 Authority: 1 Additional: 1 xyz1.www.banka.cz NS www.banka.cz www.banka.czwww.banka.cz A 1.2.3.4 ● Nestihl útočník uhodnout TXID/port u dotazu na xyz1.www.banka.cz?www.banka.cz ● Nevadí ● Zkusí okamžitě na xyz2.www.banka.czwww.banka.cz ●......

18 Kaminsky attack ● ~10 hodin na vložení falešného záznamu do cache plně zapatchovaného NS – http://labs.nic.cz/files/labs/DNS-cache-poisoning- attack-analysis.pdf

19 DNSSEC Základní principy a pojmy

20 Základní principy DNSSEC ● DNSSEC umožňuje autoritativním serverům poskytovat k „standardním“ DNS datům navíc digitální podpisy RRSetů ● Resolvery ověřující DNSSEC podpisy poskytují potvrzené odpovědi ● Klienti, kteří používají validující resolvery, získávají „správná“ data ● Odpovědi, které nejsou validní, jsou klientovi vráceny z nadřazeného resolveru s chybou „SERVFAIL”

21 Základní principy DNSSEC

22 Základní pojmy DNSSEC ● Pevný bod důvěry ● Řetěz důvěry ● Důvěryhodný klíč ● Ostrov důvěry ● Validující Resolver ● Key Signing Key (KSK) ● Zone Signing Key (ZSK) ● Podepsaná vs. nepodepsaná zóna

23 Pevný bod důvěry (Trust Anchor) ● Nakonfigurovaný klíč (nebo jeho hash), kterému důvěřujeme ● Musíme ho získat nějakou bezpečnou cestou

24 Řetěz důvěry ● Sekvence DNSSEC záznamů (DNSKEY a DS) vedoucí od Pevného bodu důvěry k uzlu v DNS stromu ● V každém uzlu/úrovni máme ověřená data

25 Důvěryhodný klíč ● DNSSEC klíč, který je důvěryhodný ● Pevný bod důvěry ● Klíč získaný přes Řetěz důvěry

26 Validující Resolver ● Posílá DNS dotazy s DNSSEC OK ● Ověřuje validitu DNSSEC podpisů v DNS odpovědích ● Má nakonfigurovaný alespoň jeden Pevný bod důvěry

27 Ostrov důvěry ● Podepsaná důvěryhodná zóna, která není bezpečně delegována z nadřazené zóny ● Může být ověřena pomocí nakonfigurovaného Pevného bodu důvěry ● Obecněji i všechny bezpečně delegované podřazené zóny

28 Ostrov důvěry root org cz nl nlnetlabs.n l ww w mai l unsigned.or g.... nic.c z.... neco.c z publicoffice......... signed.neco.c z mai l ww w Podepsané domény

29 Ostrov důvěry root org cz nl nlnetlabs.n l ww w mai l unsigned.or g.... nic.c z.... neco.c z publicoffice......... signed.neco.c z mai l ww w Podepsané domény

30 Ostrov důvěry root org cz nl nlnetlabs.n l ww w mai l unsigned.or g.... nic.c z.... neco.c z publicoffice......... signed.neco.c z mai l ww w Podepsané domény

31 Ostrov důvěry root org cz nl nlnetlabs.n l ww w mai l unsigned.or g.... nic.c z.... neco.c z publicoffice......... signed.neco.c z mai l ww w Podepsané domény

32 Key Signing Key ● DNSSEC klíč používaný pro podepsání dalších klíčů ● Silnější ● Více bitů ● Výpočetně složitější ● Více dat ● Speciální bit (SEP) v příznacích DNSSEC klíče

33 Zone Signing Key ● DNSSEC klíč používaný pro podepsání vlastního obsahu zóny ● Slabší ● Méně bitů ● Výpočetně jednodušší ● Rychlejší podpis i ověřování ● Méně dat

34 Příklad: doména onde.cz

35 Podepsaná zóna ● Obsahuje veřejní část klíčů (DNSKEY) ● RRSety jsou podepsané ● U každého RRsetu musí existovat alespoň 1 podpis pro každý použitý algoritmus (ne u delegací) ● Ke každému DN existuje NSEC záznam ● U NSEC3 – hash DN ● Výjimkou je Opt-out ● Autentické potvrzení neexistence DN alebo typu

36 Nové RR záznamy

37 DNSKEY RR záznam ● DNSSEC klíč ● RDATA obsahují ● Příznaky (Flags) ● Protocol (vždy 3) ● Algoritmus (5 - RSASHA1) ● Veřejný klíč ● IN DNSKEY 257 3 5 AwEAAd[...]kNB8Qc=

38 RRSIG RR záznam ● Digitální podpis RRSetu ● Obsahuje: ● Podepsaný RR typ ● Algoritmus ● Počet labelů v podpisovaném jméně (kvůli *) ● Původní TTL ● Datum platnosti (začátek a konec) ● Key Tag, Jméno zóny ● Digitální podpis ● INRRSIG A 5 3 600 20081203010003 20081103010003 58773 dnssec.cz. V0JXuw[...]

39 NSEC RR záznam ● Záznam vyznačující neexistenci doménového jména – pomocí vyjmenování dalšího následujícího labelu ● Zóna musí být abecedně setřízena (v každé úrovni hierarchie) ● Obsahuje: ● Další doménové jméno ● Bitová mapa existujících typů (pro vlastníka) ● INNSECudp53.cz. NS RRSIG NSEC DS

40 NSEC3 RR záznam ● Zone walking problém s NSEC ● NSEC3 mená hashuje ● NSEC3 RR tvoří řetěz v hashovaném pořadí ● NSEC3 RR dokáže existenci hierarchicky „nejbližšího“ mena a neexistenci přesnejší zhody ● Zvýšená zátěž jak pro nameserver, tak pro resolver ● Možnost vypustit z řetězu nepodepsané delegace

41 NSEC3 vs. NSEC ;; Question a.c.x.w.example. IN A ;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) ;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995 b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) ;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) x.w.example. NSEC y.w.example.com ( MX NSEC RRSIG ) H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom H(a.example) = 35mthgpgcu1qg68fab165klnsnk3dpvl H(ai.example) = gjeqe526plbf1g8mklp59enfd789njgi H(ns1.example) = 2t7b4g4vsa5smi47k61mv5bv1a22bojr H(ns2.example) = q04jkcevqvmu85r014c7dkba38o0ji5r H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995 H(y.w.example) = ji6neoaepv8b5o6k4ev33abha8ht9fgc H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s H(xx.example) = t644ebqk9bibcna874givr6joj62mlhv NSEC3NSEC QUERY ZONE - Nejdelší předek: x.w.example – shoda záznamu 2 - Bližší shoda (c.x.w.example) neexistuje – pokrývá záznam 1 - Wildcard (*.x.w.example) neexistuje – pokrývá záznam 3 - Klient se dozví: v zóně existuje jméno x.w.example

42 DS RR záznam ● Záznam o bezpečné delegaci ● V nadřazené zóne ● RDATA obsahují hash DNSKEY klíče, kterým je zóna podepsaná ● Obsahuje: ● Key Tag ● Algoritmus ● Digest Type ● Digest ● INDS17398 5 1 BBDDD[...]3502D

43 Konfigurace validujícího resolveru Bind 9.7 & Unbound

44 Povolte DNSSEC na resolveru options { dnssec-enable yes; dnssec-validation yes; }; Validace se provádí na rekurzivních, nikoli na autoritativních serverech.

45 Povolte DNSSEC na rekurzivních serverech ● BIND 9.3 pouze dnssec-enable yes; ● BIND >= 9.4 má standardně zapnutý DNSSEC ● BIND >= 9.5 má standardně zapnutou i validaci ● Unbound má validaci standardně zapnutou (module-config: „validator iterator“ vs. „iterator“) ● Nutno přidat Pevné body důvěry

46 Úkol: Zapněte DNSSEC validaci Soubor /etc/bind/named.conf nahraďte souborem named.conf.rec z materiálů Explicitně zapněte DNSSEC validaci Bind 9: /etc/bind/named.conf options { dnssec-enable yes; dnssec-validation yes; }; Unbound: /etc/unbound/unbound.conf module-config: "validator iterator"

47 Pevné body důvěry (Trust Anchors)

48 Pevné body důvěry ● Aby validace mohla někde začít, musíte do konfigurace validující resolveru vložit Pevný bod důvěry pro každý Ostrov důvěry, který budete chtít ověřovat ● Nejvyšší pevný bod důvěry bude pocházet od podepsané root zóny (".")

49 Pevné body důvěry ● Root zóna (".") je podepsána ● Vhodný začátek – https://data.iana.org/root-anchors/ ● Pevné body důvěry musíte získat bezpečným způsobem ● DNS nepatří mezi zabezpečené kanály, AVŠAK...

50 Pevné body důvěry dig udp53.cz DNSKEY @localhost udp53.cz. 14400 INDNSKEY 256 3 5 BE[...]/V1 udp53.cz. 14400 INDNSKEY 257 3 5 BE[...]1ylot7 Pomocí digu získáme DNSSEC klíče, které mohou být ověřeny pomocí dalších prostředků (web, telefon, tištěná média, atd.)

51 Pevné body důvěry ● Pro.cz používat root-anchor ● http://www.nic.cz/page/563/jak-zprovoznit-dnssec/ ● Poštovní konference – informace o změnách: ● dnssec-announce@lists.nic.cz dnssec-announce@lists.nic.cz ● https://lists.nic.cz/mailman/listinfo/dnssec-announce https://lists.nic.cz/mailman/listinfo/dnssec-announce

52 Pevné body důvěry (Bind 9) Bude zapotřebí, aby named.conf. obsahoval: trusted-keys { “udp53.cz.” 257 3 5 “BE[...]1ylot7”; “cz.” 257 3 5 “AwEAAdo9[...]MnitkuM=”; “se.” 257 3 5 “AwEAAdKc[...]UkNB8Qc=”; }; Klíč pro KAŽDOU zónu, kterou chcete ověřovat Použijeme soubor named.conf.keys z materiálů

53 Úkol: Nakonfigurujte Bind9 Nakonfigurujte Bind 9 jako validující resolver Vemte soubor named.conf.keys trusted-keys { "se." 257 3 5 "AwEAAdo9[...]MnitkuM=";.... }; Pomocí direktivy include připojte soubor named.conf.keys do named.conf include "/etc/bind/named.conf.keys"; Načtěte novou konfiguraci # rndc reload

54 Úkol: Nakonfigurujte Bind9 ● V named.conf.keys zakomentujte všechny TA mimo root ● „se.“ a „dlv.isc.org“ neaktivní trusted-keys { # „se.“ 257........ "." 257 3 5 "AwEAAagAIKl[...]RlZigUCp8=";.... };

55 Úkol: Nakonfigurujte Bind9 Ověřte si, že vám funguje validace Dotazem na „špatnou“ doménu: # dig www.rhybar.cz @localhostwww.rhybar.cz Musí vrátit RCODE=SERVFAIL Dotazem s DNSSEC OK bitem # dig +dnssec www.nic.cz @localhost # dig +dnssec www.nic.se @localhost Musí vrátit nastavený bit AD v hlavičce

56 Úkol: Nakonfigurujte Bind9 dig +dnssec nic.cz @localhost ; > DiG 9.6.1b1 > +dnssec nic.cz @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30545 ;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;nic.cz.INA ;; ANSWER SECTION: nic.cz.1800INA217.31.205.50

57 Úkol: Nakonfigurujte Bind9 ● V named.conf.keys zakomentujte všechny TA mimo „se.“ ● „.“ (root) a „dlv.isc.org“ neaktivní trusted-keys { „se.“ 257........ #"." 257 3 5 "AwEAAagAIKl[...]RlZigUCp8=";.... };

58 Úkol: Nakonfigurujte Bind9 # dig www.rhybar.cz @localhostwww.rhybar.cz Vrací odpověď bez AD (už není SERVFAIL!!!) Dotazem s DNSSEC OK bitem # dig +dnssec www.nic.cz @localhost Nevrací AD – neexistuje reťez důvěry do cz. # dig +dnssec www.nic.se @localhost Vrací AD – klíč pro „se.“ je mezi TA

59 Pevné body důvěry (Unbound) Unbound umí použít formát trusted-keys, který používá Bind 9 Direktiva: trusted-keys-file: Další možnosti: trusted-anchor-file: Obsahuje DNSKEY nebo DS v DNS formátu trusted-anchor: "RR záznam"

60 Úkol: Validující resolver Unbound ● Zastavte Bind ● Použijeme již vytvořený soubor named.conf.keys ● Pomocí direktivy trusted-keys-file nakonfigurujte Pevné body důvěry v /etc/unbound/unbound.conf ● trusted-keys-file: "/etc/bind/named.conf.keys" ● Nastartujte Unbound ● Ověřte si, že vám validace funguje

61 Root zóna ● http://data.iana.org/root-anchors/ http://data.iana.org/root-anchors/ ● DS formát – Unbound – ok – Bind – umí pracovat jenom s DNSKEY – dig +dnssec. DNSKEY – dnssec-dsfromkey / ldns-key2ds

62 Root zóna ● http://data.iana.org/root-anchors/ http://data.iana.org/root-anchors/ ● Ověřit! – gpg –verify root-anchors.asc root-anchors.xml – (--search-key, --recv-key)

63 Pevné body důvěry ● Správa jednotlivých pevných bodů důvěry je složitá ● Existuje registr DNSSEC klíčů – mechanismus DLV „Domain Lookaside Validation“

64 Domain Lookaside Validation & ITAR

65 DLV ● Při ověřování hledá resolver v nadřazené zóně záznam DS pro zónu, která je ověřována ● Pokud neexistuje, je vytvořen dotaz na záznam DLV v zóně registru DLV ● Pokud je úspěšná, je DLV RR použito jako DS pro danou zónu

66 DLV

67 Příklad DLV ● webpanel.sk je podepsaná a v DLV registru ● Je vytvořen DNSSEC dotaz na A RR jména ulib.sk ●.sk není podepsaná ● Resolver se zapnutým DLV bude hledat webpanel.sk.dlv.isc.org. DLV RR záznam ● Tento DLV RR pak bude použit jako DS pro zónu webpanel.sk.

68 Povolení DLV ● Použití DLV pro ověření je provedeno na validujícím resolveru ● Konfigurace DLV v Bind 9.7 - default: managed-keys { ● dlv.isc.org. initial-key 257 3 5 "BEAA...WrBNh"; ● }; ● options { ● dnssec-lookaside auto; #dnssec-lookaside "." trust-anchor dlv.isc.org.; ● };

69 ISC registr DLV https://dlv.isc.org/about/using

70 Úkol: Nakonfigurujte DLV registr ● Nakonfigurujte BIND 9 jako validující resolver, který používá DLV registr dlv.isc.org ● Doplňte direktivu dnssec-lookaside s hodnotou auto ● Odkomentujte v named.conf.keys klíč pro dlv.isc.org ● dig +dnssec webpanel.sk @localhost –.sk nepodepsaná, webpanel.sk v DLV

71 ITAR ● Interim Trust Anchor Repository ● https://itar.iana.org/ ● Offline registr ● DS RR pro podepsané TLD ● Po podepsaní root zóny se zmenšuje ● Konec v 1/11

72 Konfigurace autoritativního serveru

73 Připravte si adresářovou strukturu ● Umístěte všechny soubory zóny do jediného adresáře ● Bude jich mnoho ● Lepší orientace ● Podpora dalších nádstavbových nástrojů

74 Příprava na další úkoly ● Připravte si adresářovou strukturu # mkdir /var/cache/bind/zone ● Vytvořte adresář pro zónu udp53.cz # mkdir /var/cache/bind/zone/udp53.cz/ ● Skopírujte zónu udp53.cz z materiálů do vytvořeného adresáře

75 Příprava na úkoly ● Soubor /etc/bind/named.conf nahraďte souborem named.conf.auth z materiálů ● Nakonfigurujte named.conf, aby poskytoval zónu udp53.cz zone "udp53.cz." { type master; file "zone/udp53.cz/udp53.cz"; }; v options je „directory /var/cache/bind“;

76 Příprava na úkoly Obnovte konfiguraci # rndc reload Otestujte # dig +norec IN SOA udp53.cz. @localhost

77 Povolení DNSSEC na autoritativních serverech BIND >= 9.3 podpora DNSSECbis BIND >= 9.4 má DNSSEC standardně zapnutý options { dnssec-enable yes; }; NSD3 má DNSSEC standardně zapnutý pro všechny podepsané zóny

78 Zabezpečení zóny ● Pro každou zónu jsou vytvořeny dva typy klíčů ● Klíč podepisující zóny (ZSK) – používá se k podpisu dat v zóně ● Klíč podepisující klíče (KSK) – používá se k podpisu klíče podepisujícího zóny a k vytvoření „důvěryhodného vstupního bodu (SEP)“ pro zónu

79 Podepsání zóny

80 Vytvoření klíčů Vytvoření ZSK dnssec-keygen -a RSASHA1 -b 512 -n ZONE zonename Využívá algoritmus RSA SHA1 Délka 512 bitů DNSSEC klíč pro zónu (-n ZONE)

81 Vytvoření klíčů Vytvoření ZSK dnssec-keygen -a RSASHA1 -b 1024 -n ZONE zonename Vytvoří 2 soubory Kzonename+ +.key Kzonename+ +.private.key je veřejnou částí klíče,.private je soukromou částí klíče

82 Vytvoření klíčů Vytvoření KSK dnssec-keygen -a RSASHA1 -b 2048 -n ZONE -f KSK zonename Využívá algoritmus RSA SHA1 Délka 1024 bitů Větší klíč potřebuje více entropie! DNSSEC klíč pro zónu (-n ZONE) Má nastavení bitu Secure Entry Point (SEP)

83 Úkol: Vytvořte DNSSEC klíče Vytvořte dva DNSSEC klíče pro doménu udp53.cz v adresáři se zónou Použijte: -r /dev/urandom Jeden KSK (-f KSK) # dnssec-keygen -a RSASHA1 -b 1024 -n ZONE -f KSK -r /dev/urandom udp53.cz Jeden ZSK # dnssec-keygen -a RSASHA1 -b 512 -n ZONE -r /dev/urandom udp53.cz

84 Připravte zónu ● Přidejte veřejné části obou KSK a ZSK k zóně, která má být podepsána ● Direktiva $INCLUDE v souboru se zónou ● $INCLUDE Kzonename+005+.key ● Nebo přímo vložit do souboru ● # cat Kzonename+005+*.key >> zonefile

85 Úkol: Přidejte do zóny klíče Přidejte do zóny vygenerované klíče # cat Kudp53.cz*.key >> udp53.cz Nebo $INCLUDE Kudp53.cz+005+.key

86 Podepsání zóny Přidejte RRSIG, NSEC a přiřazené záznamy k zóně dnssec-signzone [-o zonename] [-N KEEP/INCREMENT/UNIXTIME] [-k KSKfile] zonefile [ZSKfile] Název zóny (zonename) je implicitně název souboru (zonefile) Pojmenujte soubor podle zóny!

87 Podepsání zóny dnssec-signzone [-o zonename] [-N KEEP/INCREMENT/UNIXTIME] [-k KSKfile] zonefile [ZSKfile] Automatické přečíslování sériového čísla -N INCREMENT automaticky inkrementuje sériové číslo během podepisování -N UNIXTIME automaticky nastaví sériové číslo na aktuální unixový čas

88 Podepsání zóny dnssec-signzone [-o zonename] [-N UNIXTIME] [-k KSKfile] zonefile [ZSKfile] Implicitně se hledají takové klíče, které jsou obsaženy v zónovém souboru KSKfile je implicitně Kzonefile+005+ s nastavením bitu SEP ZSKfile je implicitně Kzonefile+005+ bez nastavení bitu SEP

89 Podepsání zóny dnssec-signzone [-o zonename] [-N UNIXTIME] [-k KSKfile] zonefile [ZSKfile] Výstupní soubor je zonefile.signed Seřazený podle abecedy Včetně RRSIG, NSEC a DNSKEY RR záznamů Mnohem větší než předtím!

90 Úkol: Podepište zónu udp53.cz ● Podepište zónu udp53.cz ● # dnssec-signzone -N UNIXTIME udp53.cz ● Vznikne: ● /var/cache/bind/zone/udp53.cz/udp53.cz.signed

91 dnssec-signzone - výstup # dnssec-signzone -k Kudp53.cz... udp53.cz Kudp53... dnssec-signzone: warning: udp53.cz:10: using RFC1035 TTL semantics Verifying the zone using the following algorithms: RSASHA1. Zone signing complete: Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revoked udp53.cz.signed

92 Aktualizujte named.conf Nahraďte zone "udp53.cz" { type master; file "zone/udp53.cz/udp53.cz"; }; Za zone "udp53.cz" { type master; file "zone/udp53.cz/udp53.cz.signed"; };

93 Úkol: Začněte poskytovat podepsanou zónu Aktualizujte named.conf, aby poskytoval podepsanou zónu, kterou jste vytvořili Znovunačtěte konfiguraci Bind 9 # rndc reload Ověřte zda-li se podepsaná zóna správně načetla # dig IN SOA udp53.cz. @localhost # dig IN RRSIG udp53.cz. @localhost # dig +dnssec IN A udp53.cz. @localhost

94 Oznamte nadřazené zóně DNSSEC ● Pro vytvoření řetězu důvěry nyní musíte vložit DS RR záznam do nadřazené zóny ● Postupy se budou lišit podle organizací, ale musí být provedeny bezpečně ● Bude vyžadovat použití dsset- a/nebo keyset- soubor, který se vytvořil při podepsání zóny ● Pro.cz kontaktujte svého registrátora ● Registrátoři vloží DNSKEY přes EPP rozhraní

95 Nadřazená zóna bez podpory DNSSECu ● Ne všechny TLD podporují DNSSEC ● Ve skutečnosti podporuje v současnosti DNSSEC málo TLD (.cz,.se,.br,.bg,.pt,.ch,.li,.na,.nu,.org,.gov,.com...) ● Poskytněte váš DNSKEY těm stranám, u kterých chcete, aby ověřovaly vaši zónu.

96 Generování DLV RR záznamů Při podepisování zóny pro registrátora DLV přidejte přepínač “ ‑ l” (malé L) Pro DLV registr ISC: dnssec-signzone -N INCREMENT -l dlv.isc.org. udp53.cz V tomto bodě bude vytvořen soubor dlvset-udp53.cz, který je rovnou připraven k odeslání správci ISC DLV

97 Registrace v DLV ● Kontaktujte správce DLV registru pro instrukce jak prokázat vlastnictví zóny a platnost DLV RR záznamu ● Vložení vašeho DLV RR záznamu do registru DLV musí být provedeno důvěryhodným způsobem

98 Úkol: Podepište změny s DLV Přidejte do zónového souboru udp53.cz mail.udp53.cz. 600 IN A 10.0.0.10 udp53.cz. 600 IN MX 10 mail.udp53.cz. Musíme zónu znovu podepsat!

99 Úkol: Podepište změny s DLV Uvedťe název zóny (origin) -o udp53.cz Uvedťe cílový podepsaný soubor -f udp53.cz.signed Explicitně uveďte DNSSEC klíče KSK: -k Kudp53.cz.+005+ ZSK: Kudp53.cz.+005+ Vygenerujte DLV záznamy pro DLV registr dlv.isc.org -l dlv.isc.org

100 Úkol: Podepište změny s DLV Podepište zónu udp53.cz

101 Úkol: Podepište změny s DLV Podepište zónu udp53.cz # dnssec-signzone -o udp53.cz -f udp53.cz.signed -k Kudp53.cz.+005+ -N UNIXTIME -l dlv.isc.org. udp53.cz Kudp53.cz.+005+ Znovunačtěte zónu # rndc reload udp53.cz

102 BIND 9.7 ● „DNSSEC for Humans“ ● Plně automatické podepisování zóny – allow-update+ key-directory + auto-dnssec parametry zóny – named sám detekuje ZSK/KSK, podepíše a sleduje metadata použitých KSK/ZSK – Možnost vyvolat přepodepsání – rndc sign ● Metadata klíče – Publish, Active, Revoke, Delete

103 BIND 9.7 ● Vylepšený dnssec-signzone – -S – „smart signing“ – Využívá metadata klíčů k podpisu – Klíč není nutno includovat do zóny ● Relativní čas – now+2y ● Hlídání pevných bodů důvěry – RFC5011

104 Problematika pravidelné údržby

105 Pravidelná údržba zóny ● Podpisy mají životnost ● Datum „vzniku“ – 1 hodina před spuštěním ● dnssec-signzone ● Datum expirace – 30 dní po spuštění ● dnssec-signzone ● Expirované podpisy způsobí, že zóna nepůjde ověřit a pro validující resolver „zmizí“ ● Přepodepsat pokaždé, když upravíte zónu – nebo minimálně každých 30 dnů (mínus TTL) musíte znovu spustit dnssec-signzone

106 Pravidelná údržba klíče ● Klíče je zapotřebí střídat ● Nemají „datum expirace“ ● Čím déle je klíč veřejně viditelný, tím větší je pravděpodobnost, že bude prolomen ● Prolomení (zcizení) klíče může vést k potřebě „výměny“ klíče

107 Pravidelná údržba klíčů ● RFC 4641 – DNSSEC Operational Practices ● Klíč o síle 1024b stačí měnit jednou ročně ● Jsou dostupné automatické nástroje ● RIPE DISI tools (www.ripe.net/disi/)www.ripe.net/disi/ ● DNSSEC Tools (www.dnssec-tools.org)www.dnssec-tools.org ● ZKT (www.hznet.de/dns/zkt/)www.hznet.de/dns/zkt/ ● OpenDNSSEC

108 Výměna (rollover) klíčů

109 Dva způsoby výměny klíčů ● Předčasné publikování (pre-publish) ● Dvojitý podpis (double signature)

110 Předčasné publikování ● Používá se pro výměnu ZSK ● Do zóny se vloží další klíč ● Nutné explicitně specifikovat ZSK klíč používaný k podpisu ● Po uplynutí TTL se může začít podepisovat novým klíčem ● Po uplynutí TTL můžeme starý ZSK odstranit

111 Předčasné publikování (výměna ZSK) ---------------------------------------------------------------- initial new DNSKEY new RRSIGs DNSKEY removal ---------------------------------------------------------------- SOA0 SOA1 SOA2 SOA3 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY11 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) ---------------------------------------------------------------- DNSKEY TTLMAX ZONE TTL 1 – KSK 10 – starý ZSK 11 – nový ZSK

112 Úkol: Vyměňte ZSK – fáze 1 Vygenerujte nový ZSK Přidejte nový ZSK do zóny Podepište zónu udp53.cz.signed starým klíčem (explicitně uveďte kterými klíči podepisujete) Musíte uvést i používaný KSK

113 Úkol: Vyměňte ZSK – fáze 1 Vygenerujte nový ZSK # dnssec-keygen -a RSASHA1 -b 512 -n ZONE -r /dev/urandom udp53.cz. Přidejte nový ZSK do zóny Podepište zónu udp53.cz starým klíčem (explicitně uveďte kterými klíči podepisujete) # dnssec-signzone -o udp53.cz -f udp53.cz.signed -N UNIXTIME -k Kudp53.cz.+005+ udp53.cz Kudp53.cz.+005+

114 Úkol: Vyměňte ZSK – fáze 1 Ke každému RRsetu by měl existovat pouze jeden podpis s keytagem starého ZSK, DNSKEY bude mít podpisy dva – starý ZSK a KSK Znovunačtěte zónu # rndc reload udp53.cz

115 Úkol: Vyměňte ZSK – fáze 2 (Virtuálně) počkejte až se zóna zpropaguje na nové nameservery plus TTL DNSKEY záznamů Podepište zónu novým klíčem, starý zůstává v zóně

116 Úkol: Vyměňte ZSK – fáze 2 (Virtuálně) počkejte až se zóna zpropaguje na slave nameservery plus TTL DNSKEY záznamů Podepište zónu novým klíčem, starý zůstává v zóně: # dnssec-signzone -o udp53.cz -f udp53.cz.signed -N UNIXTIME -k Kudp53.cz.+005+ udp53.cz Kudp53.cz.+005+

117 Úkol: Vyměňte ZSK – fáze 2 Ke každému RRsetu by měl existovat pouze jeden podpis s keytagem nového ZSK, DNSKEY bude mít podpisy dva – nový ZSK a KSK Znovunačtěte zónu # rndc reload udp53.cz

118 Úkol: Vyměňte ZSK – finále Opět (virtuálně) počkejte až se zóna zpropaguje Odstraňte starý klíč ze zóny Přepodepište!

119 Úkol: Vyměňte ZSK – finále Opět (virtuálně) počkejte až se zóna zpropaguje Odstraňte starý klíč ze zóny Přepodepište! # dnssec-signzone -o udp53.cz -f udp53.cz.signed -N UNIXTIME -k Kudp53.cz.+005+ udp53.cz Kudp53.cz.+005+ Znovunačtěte zónu # rndc reload udp53.cz

120 Dvojitý podpis ● Používá se u KSK ● Všechny klíče jsou podepsány dvěma (a více) KSK klíči ● Nadřazená zóna dostane oba dva (a více) klíče

121 Dvojitý podpis (změna KSK) ------------------------------------------------------------ ---- initial new DNSKEY DNSKEY removal ---------------------------------------------------------------- SOA0 SOA1 SOA2 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2) DNSKEY1 DNSKEY1 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY2 DNSKEY2 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG2(DNSKEY) RRSIG2(DNSKEY) ---------------------------------------------------------------- DNSKEY/MAX ZONE TTL 1 – starý KSK 10 – ZSK 2 – nový KSK

122 Dvojitý podpis (změna KSK) – spolupráce s nadřazeným -------------------------------------------------------------------- initial new DNSKEY DS change DNSKEY removal -------------------------------------------------------------------- Parent: SOA0 --------> SOA1 --------> RRSIGpar(SOA0) --------> RRSIGpar(SOA1) --------> DS1 --------> DS2 --------> RRSIGpar(DS) --------> RRSIGpar(DS) --------> Child: SOA0 SOA1 --------> SOA2 RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2) --------> DNSKEY1 DNSKEY1 --------> DNSKEY2 DNSKEY2 --------> DNSKEY10 DNSKEY10 --------> DNSKEY10 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY) RRSIG2 (DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) -------------------------------------------------------------------- 1 – starý KSK 10 – ZSK 2 – nový KSK DNSKEY TTL

123 Úkol: Vyměňte KSK Vygenerujte nový KSK Vložte nový KSK do zóny Podepište zónu udp53.cz pomocí obou KSK a nového ZSK

124 Úkol: Vyměňte KSK Vygenerujte nový KSK # dnssec-keygen -a RSASHA1 -b 1024 -n ZONE -f KSK -r /dev/urandom udp53.cz Vložte nový KSK do zóny Podepište zónu udp53.cz pomocí obou KSK a nového ZSK # dnssec-signzone -o udp53.cz -f udp53.cz.signed -N UNIXTIME -k Kudp53.cz.+005+ udp53.cz Kudp53.cz.+005+

125 Úkol: Vyměňte KSK Ke každému RRsetu by měl existovat pouze jeden podpis s keytagem ZSK, DNSKEY bude mít podpisy tři – ZSK, starý KSK a nový KSK Znovunačtěte zónu # rndc reload udp53.cz

126 Úkol: Vyměňte KSK „Pošlete“ nový klíč do nadřazené zóny „Počkejte“ až se nový klíč zpropaguje Odstraňte starý KSK Podepište zónu udp53.cz pomocí nového KSK

127 Úkol: Vyměňte KSK „Pošlete“ nový klíč do nadřazené zóny „Počkejte“ až se nový klíč zpropaguje Odstraňte starý KSK Podepište zónu udp53.cz pomocí nového KSK # dnssec-signzone -o udp53.cz -f udp53.cz.signed -N UNIXTIME -k Kudp53.cz.+005+ udp53.cz Kudp53.cz.+005+

128 Bind 9.7 – automatizace ● Zatím neumí vygenerovat nové klíče – auto-dnssec: allow | maintain | create ● Allow – povolí zónu podepsat – rndc sign zonename – nsupdate update add zone DNSKEY ● Maintain – Nečeká na sign command – Obnovuje podpisy, mění klíče na základě metadat ● Create – Rezervováno – Bude umět vygenerovat nové klíče a provést key roll

129 BIND 9.7 - klíče ● Nové atributy, uchované v textové podobě – Nesouvisí s protokolem, pouze pro potřeby BINDu – Publish, Activate, Revoke, Inactivate, Delete

130 Bind 9.7 - automatizace ● Pozor na: – práva ke klíčům – Privátní část musí byt čitelná pro uživatele pod kterým beží BIND – Zápis do adřesárů – BIND bude vytvářet update journal

131 OpenDNSSEC ● http://www.opendnssec.org/ http://www.opendnssec.org/ ● Signing + key-rolling + audit ● Konfigurováno v 3 (4) xml ● Potřeba HSM – SoftHSM – SW emulace HSM

132 OpenDNSSEC -postup ● Init HSM – Závisí na HSM ● ODS Setup – ods-ksmutil setup – Připraví DB pro OpenDNSSEC metdata ● Nastavení v xml – conf.xml – obecná nastavení OpenDNSSEC, cest a HSM – kasp.xml – Key And Signature Policy – klíče, podpisy – zonelist.xml – nastavení zón, vstupní/výstupní soubory – zonefetch.xml – pro AXFR ● ods-control start

133 OpenDNSSEC - postup ● Podrobné video návody/školení: – http://www.opendnssec.org/documentation/training/

134 Testování a ladění DNSSECu

135 Testování DNSSECu ● Nyní, když distribuujete podepsané DNSSEC RR záznamy, funguje to? ● DNSSEC může být laděn pouze pomocí příkazů dig nebo drill a date ● Vizualizace (http://dnsviz.net/)

136 Dotazování na DNSSEC ● DNS odpověď, na dotaz koncového klienta, který je podepsán a zvalidován, obsahuje požadovaný RRset ● DNS odpověď, na dotaz koncového klienta, který není podepsán a zvalidován, obsahuje požadovaný RRset

137 Dotazování na DNSSEC ● DNS odpověď, na dotaz koncového klienta, který je podepsán a není validní (tj. data byla změnana, nebo podpis nesedí), vrátí RCODE=SERVFAIL ● Pro aplikace (a uživatele) se bude doména jevit jako „neexistující“ ● Příznak CD v hlavičce umožní, aby koncový klient dostal v DNS odpovědi i špatně zvalidovaná data

138 Případy SERVFAIL ● Chybí podpis pro některý použitý alg. ● Podpis je mimo životnost ● DS/DNSKEY mismatch ● Insecure odpověď od zóny kde se očekává DNSSEC – tj. nadřazená má pro ni DS záznam – Úkol: Jak resolver zjistí, že delegovaná zóna není podepsaná?

139 výstup dig – bez DNSSECu dig ;; [..] status: NOERROR ;; flags: qr rd ra; Správná odpověď; odpověď (qr), požadovaná rekurze (rd), rekurze k dispozici (ra)

140 výstup dig – bez DNSSECu dig www.dnssec.cz A ;; [..] status: NOERROR ;; flags: qr rd ra; Z validujícího resolveru – tohle jsou garantovaná správná data

141 výstup dig – bez DNSSECu dig www.dnssec.cz A ;; [..] status: NOERROR ;; flags: qr rd ra; Ale jak víte, že váš resolver provádí validaci?

142 výstup dig – s DNSSECem dig +dnssec www.dnssec.cz A ;; [..] status: NOERROR ;; flags: qr rd ra ad Jako předtím, ale tentokrát autentizované!

143 Dotazování na DNSSEC ● Pro vrácení příznaku AD musí mít resolver provádějící ověření pevný bod důvěry, který může být zpětně vystopován (pomocí DS RR záznamů) ● Pokud řetěz důvěry nevede k pevnému bodu důvěry, nebude příznak AD nastaven, ale RRSIG záznamy budou i tak vráceny

144 výstup dig – DNSSEC dig +dnssec www.dnssec.cz A www.dnssec.cz. 3600 IN A217.31.205.50 www.dnssec.cz. 3600 IN RRSIGA 5 3 600 20081203010003 20081103010003 58773 dnssec.cz. V0JXuwsLAEjwXnigUMiqIRUzNVEGy4OzrjA48XJfzfXBti5UftB7kLcA jVZOl5CsobucSm5jFNfo4FSh8jhgD0CLEPnxiqfCeZ/TvHdlr3OnlecP IqJDTqBuvA8e4z3GO8bM3Yff+DBOQgORZ2cC7xGnfEMWWrCHnyRjmV6t 678= Pokud je AD nastaveno, validující resolver má pevný bod důvěry, pokud ne, pořád máme data, která můžeme ověřit sami

145 Dotazování na DNSSEC ● Pokud víme, že komunikujeme s validujícím resolverem a dostaneme zpět SERVFAIL, může se jednat o nevalidní podepsaná data ● Pokud je to tak, nastavení bitu CD v dotazu způsobí, že resolver i tak zašle nevalidní data

146 výstup dig – DNSSEC dig +dnssec +cd www.rhybar.cz A www.rhybar.cz. 3600 IN A217.31.205.50 www.rhybar.cz. 3600 IN RRSIGA 5 3 3600 20080627122225 20080617122225 46704 rhybar.cz. XXXXXXXXXX XXXXXXXXXX Neplatný záznam RRSIG (XXXXXXXXXX), ale s příznakem +cd, proto dostaneme odpověď

147 výstup dig – DNSSEC dig +dnssec +cd www.rhybar.cz A www.rhybar.cz. 3600 IN A217.31.205.50 www.rhybar.cz. 3600 IN RRSIGA 5 3 600 20081030080058 20080930080058 5172 rhybar.cz. XVkut4l9mw2MhodZFIOD2L57AU2u+I6wGVlK1fr6w5locFC5NIe8ukw7 9jYdOCH3WwFgSMscumIz1sGqRPrN/CrhXiU0ymFGFju9x/k10lv6SGS6 lslgnZluet04CyibGQ2HBnwTx7qK3j+bNzxKLvjpn7DY9f+YKB8F2Ftw NOc=

148 výstup dig – DNSSEC dig +dnssec +cd www.rhybar.cz A www.rhybar.cz. 3600 IN A217.31.205.50 www.rhybar.cz. 3600 IN RRSIGA 5 3 600 20081030080058 20080930080058 5172 rhybar.cz. XVkut4l9mw2MhodZFIOD2L57AU2u+I6wGVlK1fr6w5locFC5NIe8ukw7 9jYdOCH3WwFgSMscumIz1sGqRPrN/CrhXiU0ymFGFju9x/k10lv6SGS6 lslgnZluet04CyibGQ2HBnwTx7qK3j+bNzxKLvjpn7DY9f+YKB8F2Ftw Noc= Data v podpisu ukazují, že podpis je expirovaný Porovnejte s aktuálním datem

149 Dotazování na DNSSEC ● Všimněte si, že je snadné zkontrolovat datum na podpisech ● Je mnohem těžší (není v lidských silách?) najít chybu v klíči samotném ● Předchozí příklad je krajně nepřirozený (XXX?)‏

150 Dotazování na DNSSEC ● Další problém, který může nastat je chybějící nebo jiný hash nebo klíč ● Chybí DS nadřazené zóně ● Chybí DNSKEY v aktuální zóně ● DS v nadřazené zóně není stejný jako DNSKEY v podřazené zóně ● Není těžké určit ani tuto chybu

151 výstup dig – DNSSEC dig +dnssec +cd www.udp53.cz www.udp53.cz. 3600 IN A192.168.154.2 www.udp53.cz. 3600 IN RRSIGA 5 3 3600 20080627122225 20080617122225 46704 udp53.cz. XEkXkv9MCRiGbxO9T0dkNY+3y5EZRB6s6YOk0pFAVUL/y8VDeJphc8yb K6E/YLvraItdGvIvpy4P1OuIY09BGQ== Podpis byl vytvořen s klíčem 46704

152 výstup dig – DNSSEC dig +cd +multi udp53.cz DNSKEY udp53.cz. 14400 IN DNSKEY 256 3 5 ( BEAAAAO2oQi7U9m9i495S/XoAk+j8QxxnBHon6fa7nlN 7xoqrSr/xzy3+IerFS1KgJz1gJGbTsGV0WI1/bvAzIEK Uh+p ) ; key id = 46704 DNSKEY v zóně existuje Pokud ne, nepůjde ověřit!

153 výstup dig – DNSSEC dig +cd +multi udp53.cz DNSKEY udp53.cz. 14400 IN DNSKEY 256 3 5 ( B[...]p ) ; key id = 46704 udp53.cz. 14400 IN DNSKEY 257 3 5 ( B[...]J ) ; key id = 64249 ZSK DNSKEY v zóně existuje Připojený KSK je 64249

154 výstup dig – DNSSEC dig +norec @a.ns.nic.cz udp53.cz DS ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29385 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 DS v nadřazené zóně neexistuje

155 výstup dig – DNSSEC dig +norec @a.ns.nic.cz udp53.cz DS ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29385 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 Server bude vracet odpovědi, ale bez příznaku „AD“ Neexistuje řetěz důvěry až k pevnému bodu důvěry Není zaregistrovaný DS záznam v doméně.cz

156 Další možné problémy DNSSEC ● „Chytrý“ firewall/home gateway ● Neumí EDNS0 ● Zahazuje UDP větší než 512 byte ● Zahazuje neznámé RR typy ● Modifikuje obsah RR záznamů ● Zahazuje neznámé příznaky DNS paketu

157 DNSSEC plugin ● http://www.dnssec-validator.cz/

158 Cíle školení ● Pochopit základní principy DNSSEC ● Umět nakonfigurovat validující resolver ● Umět nakonfigurovat autoritativní server ● Umět podepsat vlastní zónu ● Umět v podepsané zóně vyměnit klíče ● Umět najít chybu, když nefunguje validace

159 Reference ● https://www.nic.cz/dnssec/ https://www.nic.cz/dnssec/ ● http://www.nlnetlabs.nl/dnssec_howto/ http://www.nlnetlabs.nl/dnssec_howto/ ● http://www.opendnssec.org ● RFC1034, 1035 (DNS) ● RFC2181 (DNS Clarification) ● RFC2671 (EDNS0) ● RFC4033, RFC4034, RFC4035 (DNSSEC) ● RFC5011 (Trust Anchor Update) ● RFC5155 (NSEC3)

160 160 Děkuji za pozornost Matej Dioszegi matej.dioszegi@nic.cz Kde získat informace o dalších aktivitách sdružení CZ.NIC? Web Blog Email Konference www.nic.cz blog.nic.cz kontakt@nic.cz nic-news@nic.cz