Jak začít s DNSSEC

[reyny]

1. Ked som si vygeneroval kluce pre zonu, tak obsah suboru dsset-my.example.tld (v nom su 2 DS zaznamy, asi pre KSK a ZSK??) mam poslat spravcovi zony example.tld, alebo mu mam poslat (aj) nieco ine?

2. Vychadza z otazky 1. a to, ze co realne spravca example.tld zony urobi s tymi zaznamamy co som mu poslal pre moju domenu - to co je v ddset-my.example.tld (len ich doplacne k NS glue zaznamom pre moju zonu a zonu example.tld podpise svojimi klucmi?)

3. V tom dsset-my.example.tld ak su zaznamy pre KSK a ZSK, znamena to, ze pri kazdej zmene KSK/ZSK kluca(ov) mam tento subor poslat spravcovi example.tld ?

3. Co znamenaju u DS zaznamov tie cisla co su hned za DS napr. IN DS 60814 5 1 - cislo 5 a cislo 1 su jasne, ale co je to 60814 ? Niekto tam ma 17398 alebo 59916, od coho to zalezi ?

4. Ma zmysel si pridavat DLV zaznamy k zone, ak nadradena zona podporuje DNSSEC a DS zaznamy? 5. Ak mam sekundarny nameserver pre zonu, ktory nie je v mojej administracii, tak mam vygenerovat pre master server TSIG kluc a nejak ho zabezpecene dorucit spravcovi sekundarneho dns servera a je dine co je treba, tak on definuje tento kluc v konfiguracii a to mu umozni robit AXFR z mojeho master servera (samozrejme pri dodrzani vsetkych dalsich konfiguracnych veci)? Alebo mu mam okrem TSIG kluca poslat este nieco ine (pripadne existuje nejaky iny mechanizmus)?

6. Ak je system robeny tak, ze DNS zaznamy sa vyhladavaju v SQL alebo LDAP backende priamo, znamena to, ze DNSSEC nejde nasadit, pretoze akakolvek zmena (pridanie/odobratie zaznamu) znamena znovu-podpisanie zony? A jedina moznost je pri kazdej zmene urobit nejaky medziskript, ktory dumpne data(zonu) z sql, podpise ich a znovu naportuje do sql uz podpisane a bind cita z sql tieto podpisane zaznamy?

7. Ak spravca example.tld ma vo svojej zone napr. 500 delegovanych subzon, tak ked sa zmeni kluc ktorejkolvej z tych 500 subzon, tak zakazdym mu spravca subzony posle DS zaznamy a musi ich zmenit v example.tld, alebo existuje nejaky dalsi mechanizmus, ktory ulahci pracu spravcovi example.tld?

Dakujem za pomoc, cital som clanky na nic.cz aj root.cz a aj na inych serveroch, ale nikde som sa nedostal poriadne k odpovediam na tieto veci.

[Reklama]

[Ondřej Caletka]

Předně disclaimer: Moc tomu (taky) nerozumím, takže moje odpovědi budou spíš mými názory, než něčím, na čem se dá stavět

1. Ked som si vygeneroval kluce pre zonu, tak obsah suboru dsset-my.example.tld (v nom su 2 DS zaznamy, asi pre KSK a ZSK??) mam poslat spravcovi zony example.tld, alebo mu mam poslat (aj) nieco ine?

Ano, nejspíš by to mělo stačit. Někteří správci ale místo DS záznamů požadují DNSKEY záznamy, ze kterých si otisky spočítají sami.

2. Vychadza z otazky 1. a to, ze co realne spravca example.tld zony urobi s tymi zaznamamy co som mu poslal pre moju domenu - to co je v ddset-my.example.tld (len ich doplacne k NS glue zaznamom pre moju zonu a zonu example.tld podpise svojimi klucmi?)

Ano, správce DS záznamy přidá k NS záznamům a celé to podepíše. Např.:

Kód: [Vybrat]

$ dig +dnssec root.cz NS @a.ns.nic.cz
; <<>> DiG 9.4.3-P4 <<>> +dnssec root.cz NS @a.ns.nic.cz
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5969
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;root.cz.                       IN      NS

;; AUTHORITY SECTION:
root.cz.                18000   IN      NS      ns.iinfo.cz.
root.cz.                18000   IN      NS      ns6.adminit.cz.
root.cz.                18000   IN      DS      21523 5 1 F43D1648847C8FFA5B58ED8A1811C8233F400616
root.cz.                18000   IN      RRSIG   DS 5 2 18000 20100411144749 20100328190439 40775 cz. cmOfOPLadMryBsBRxMdy2RZQxtnjF0hmHfR9D4r+8Ma40TM/4iqGulMe iFcv5jCwnQ9rL1FaE6hMxeqx8RkwqESAeVpdIgM4eUajRCOSsNUYFdLP 27zhHg2FoHFrz/G5PiNHHKxeo7/WQO99XHS1bFnfsmrx5D7IKitjVapt 9tI=

;; ADDITIONAL SECTION:
ns.iinfo.cz.            18000   IN      A       91.213.160.5

;; Query time: 3 msec
;; SERVER: 194.0.12.1#53(194.0.12.1)
;; WHEN: Thu Apr  1 13:13:15 2010
;; MSG SIZE  rcvd: 299

 Pozor, nesmí se stát, že budou DS záznamy publikovány v nepodepsané zóně. V takovém případě to validátor vyhodnotí jako pokus o podvrh.

3. V tom dsset-my.example.tld ak su zaznamy pre KSK a ZSK, znamena to, ze pri kazdej zmene KSK/ZSK kluca(ov) mam tento subor poslat spravcovi example.tld ?

V DSSET by měly být jen otisky KSK klíče (dvěma různými algoritmy). Pokud se vám tam zatoulal i ZSK klíč, něco je špatně. Je to právě proto, aby změna ZSK klíče mohla projít bez oznamování správci. Při update KSK klíče ale takové oznámení je potřeba.
 

3. Co znamenaju u DS zaznamov tie cisla co su hned za DS napr. IN DS 60814 5 1 - cislo 5 a cislo 1 su jasne, ale co je to 60814 ? Niekto tam ma 17398 alebo 59916, od coho to zalezi ?

Viz zde: http://www.root.cz/clanky/jak-funguje-dnssec/
Jde o ID klíče (keytag), které se používá pro rychlou identifikaci, který že klíč se v daném podpisu/otisku skrývá.

4. Ma zmysel si pridavat DLV zaznamy k zone, ak nadradena zona podporuje DNSSEC a DS zaznamy?

Myslím, že ne, pokud je některá z nadřazených zón v DLV (třeba TLD cz. tam je).i

5. Ak mam sekundarny nameserver pre zonu, ktory nie je v mojej administracii, tak mam vygenerovat pre master server TSIG kluc a nejak ho zabezpecene dorucit spravcovi sekundarneho dns servera a je dine co je treba, tak on definuje tento kluc v konfiguracii a to mu umozni robit AXFR z mojeho master servera (samozrejme pri dodrzani vsetkych dalsich konfiguracnych veci)? Alebo mu mam okrem TSIG kluca poslat este nieco ine (pripadne existuje nejaky iny mechanizmus)?

U přenosu zóny by to mělo být stejné jako bez DNSSEC – všechny klíče a podpisy jsou předem zaznamenané v zónovém souboru, sekundární server nemusí nic přepočítávat.

6. Ak je system robeny tak, ze DNS zaznamy sa vyhladavaju v SQL alebo LDAP backende priamo, znamena to, ze DNSSEC nejde nasadit, pretoze akakolvek zmena (pridanie/odobratie zaznamu) znamena znovu-podpisanie zony? A jedina moznost je pri kazdej zmene urobit nejaky medziskript, ktory dumpne data(zonu) z sql, podpise ich a znovu naportuje do sql uz podpisane a bind cita z sql tieto podpisane zaznamy?

Myslím si, že nejjednodušší řešení je při každé změně/jednou za čas/nejpozději po měsíci dumpnout databázi do zónového souboru, ten podepsat a načíst bindem.

Dokonce i pokud je zóna vyrobena staticky a často se nemění, je třeba tak jednou měsíčně zónu znovu podepsat – podpisy mají omezenou platnost, standardně na 1 měsíc, aby se znesnadnilo prolomení hrubou silou.

7. Ak spravca example.tld ma vo svojej zone napr. 500 delegovanych subzon, tak ked sa zmeni kluc ktorejkolvej z tych 500 subzon, tak zakazdym mu spravca subzony posle DS zaznamy a musi ich zmenit v example.tld, alebo existuje nejaky dalsi mechanizmus, ktory ulahci pracu spravcovi example.tld?

Myslím, že přesně tak to funguje. Je to v podstatě obdobné, jako když kterákoli z 500 subzón změní nameserver. Doporučuje se měnit KSK klíče (a tedy DS záznamy) tak jednou ročně, takže to není zas tak často.

Dakujem za pomoc, cital som clanky na nic.cz aj root.cz a aj na inych serveroch, ale nikde som sa nedostal poriadne k odpovediam na tieto veci.

Snad jsem trochu pomohl. Uvítám další doplnění/upřesnění.

[trysk]

Ja som chvilu premyslal nad DNSSEC a potom, co som mal tiez niekolko takychto otazok a nenasiel som na ne odpovede, tak som sa na to vykaslal. Ako to sledujem v poslednej dobe, tak zda sa, ze sa opat lady pohli, ale tych odpovedi je stale malo:(
Co sa tyka jednotlivych odpovedi od Ondreje, tak ja by som mal par dalsich otazok:
1. Ako spocitam s DNSKEY zaznamom prislusny DS? Nikde som zatial ziadny jednoduchy navod nenasiel.
3. Jedna sa o keytag kluca ale v tom clanku nie je nic viac napisane. Ako to cislo ziskam, ako viem, ze ake mam pre ten moj DS zaznam toto cislo zadat? Ako spominal kolega v povodnej otazke, u roznych zon toto cislo pre DS zaznam je rozne.
4. Mam tomu rozumiet tak, ze pre vsetky podzony v ramci .cz ma DLV register zmysel len ak som spravca subdomeny 3. urovne a spravca hlavnej zony (2.urovne) DNSSEC nepodporuje? Tj. niekde v "ceste" k mojej subdomene je nejaka subdomena(zona), ktora nepodporuje DNSSEC?
5. Znamena to, ze TSIG je len nejake dalsie zabezpecenie pre prenos z master serveru na sekundar, ale nie je nevyhnutne pre vseobecnu funkcnost DNSSECu?
Vdaka:)

[Ondřej Caletka]

1. Ako spocitam s DNSKEY zaznamom prislusny DS? Nikde som zatial ziadny jednoduchy navod nenasiel.

Určitě by to nějak šlo pomocí openssl base64 dekódovat DNSKEY, přidat k němu jméno vlastníka a vytvořit příslušný hash (Přesný postup je v RFC4034 na staně 16), ale není to potřeba. Příkaz dnssec-signzone vytvoří jak keyset, tak dsset.

EDIT: K vygenerování DS záznamu z DNSKEY záznamu je možné použít utilitku ldns-key2ds z příkladů použití knihovny ldns. Na Gentoo je to v balíku ldns-utils (USE=examples).

3. Jedna sa o keytag kluca ale v tom clanku nie je nic viac napisane. Ako to cislo ziskam, ako viem, ze ake mam pre ten moj DS zaznam toto cislo zadat? Ako spominal kolega v povodnej otazke, u roznych zon toto cislo pre DS zaznam je rozne.

Číslo keytag získáte vygenerováním klíče, např:

Kód: [Vybrat]

$ dnssec-keygen -r /dev/urandom -a RSASHA1 -b 512 -n ZONE example.com.
Kexample.com.+005+54507=> keytag je 54507

4. Mam tomu rozumiet tak, ze pre vsetky podzony v ramci .cz ma DLV register zmysel len ak som spravca subdomeny 3. urovne a spravca hlavnej zony (2.urovne) DNSSEC nepodporuje? Tj. niekde v "ceste" k mojej subdomene je nejaka subdomena(zona), ktora nepodporuje DNSSEC?

Přesně tak. Vlastníte-li zónu neco.nekde.cz a chcete nasadit DNSSEC, zatímco operátor zóny nekde.cz DNSSEC nasadit odmítá, nezbývá vám, než publikovat klíče v DLV registru.

5. Znamena to, ze TSIG je len nejake dalsie zabezpecenie pre prenos z master serveru na sekundar, ale nie je nevyhnutne pre vseobecnu funkcnost DNSSECu?

Domnívám se, že ano, ale podrobnostmi nemůžu sloužit.

[trysk]

Vdaka za nakopnutie.
Este by ma zaujimalo, ci
1. sa robi aj podpisovanie reverznych zon (ci to ma nejake prakticke vyuzitie/zmysel)
2. a ako to riesit, ak su tie zaznamy v zone automaticky generovane cez $GENERATE (predpokladam, ze to nejde, jedine zrusit $GENERATE a vsetko vypisat staticky a tak podpisat).
3. Otazkou este ostava, ak sa robi classless delegacia reverzu, ze ako je v tomto pripade na tom DNSSEC a classless reverz (ale to snad je v pohode)

[Reklama]

[Ondřej Caletka]

Vdaka za nakopnutie.
Este by ma zaujimalo, ci
1. sa robi aj podpisovanie reverznych zon (ci to ma nejake prakticke vyuzitie/zmysel)

Podepisování reverzních záznamů technicky možné je, třeba PTR záznamy na doménu dnssec.cz. podepsané jsou. Ale praktické využití mi tak trochu uniká.

2. a ako to riesit, ak su tie zaznamy v zone automaticky generovane cez $GENERATE (predpokladam, ze to nejde, jedine zrusit $GENERATE a vsetko vypisat staticky a tak podpisat).

Také jsem to předpokládal, ale nebyl jsem líný to vyzkoušet  . $GENERATE normálně funguje, program dnssec-signzone ho před podepsáním sám expanduje.

3. Otazkou este ostava, ak sa robi classless delegacia reverzu, ze ako je v tomto pripade na tom DNSSEC a classless reverz (ale to snad je v pohode)

Nevidím v tom žádný problém. Máte-li třeba ve své správě 192.168.23.64/27, jednoduše si vytvoříte a podepíšete zónu 64/27.23.168.192.in-addr.arpa. a předáte DSSET správci zóny 23.168.192.in-addr.arpa. Odpovědností tohoto správce také je publikovat a podepsat záznamy typu

Kód: [Vybrat]

65.23.168.192.in-addr.arpa. IN CNAME 65.64/27.23.168.192.in-addr.arpa.
66.23.168.192.in-addr.arpa. IN CNAME 66.64/27.23.168.192.in-addr.arpa.