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ř.:
$ 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í.
Zobrazit příspěvky
. $GENERATE normálně funguje, program dnssec-signzone ho před podepsáním sám expanduje.
