Vlákno názorů k článku DNSSEC snadno a rychle s automatickou správou v serveru BIND od Petr Menšík - Díky za článek o bindu. Mám pár postřehů: Cesty...

Díky za článek o bindu. Mám pár postřehů:

Cesty jsou zdá se cílené na výchozí layout v Debianu/Ubuntu, ale v článku to není vůbec zmíněné.

Stejně tak ISC už docela dlouho označuje tuhle verzi jako BIND9, balíček se v Debianu taky bind9 jmenuje. Na webu tomu říkají BIND 9. Asi by bylo lepší mít to v nadpisu s tou devítkou, protože je to součástí názvu produktů. My to v CentOS/Fedoře stále nezměnili, ale podle cest tenhle článek není podle té distribuce.

Jinak mě přijde ne úplně ok používat /var/cache/bind, protože minimálně klíče *musí* být zálohované. Na rozdíl od běžného nastavení s řadou sekundárních zón, které jsou opravdu v podstatě cache, vygenerované klíče patří mezi data, jejichž ztráta a přegenerování sice možná je, ale nikoliv bez viditelného výpadku. Pokud mám zálohu privátních klíčů a nepodepsaných dat, alespoň teoreticky jsem schopen z nich podepsat stejné podepsané zóny. Takže podepsaná data (nutně) zálohovat nemusím, klíče ale určitě ano. Proto bych je osobně vůbec do /var/cache kamkoliv nedával. Dělení na primární a sekundární zónové soubory jde docilit používáním plné cesty v zone optionu file, namísto relativních. Můžu tak mít v jedné konfigurací vybrané primární zóny ve /var/lib/bind a sekundáry v /var/cache/bind, stále v jediné instanci. Je to trochu relikt minulosti, že se primární i sekundární zóny nemají různý výchozí adresář pro data. Podle mě by se hodil.

Jestli se nepletu, do klíčů se ukládají timestampy změn stavů těch klíčů, pro případné obnovení je proto potřeba mít nehistorickou verzi. Neobnoví se tím počátek platnosti RRSIG na původní hodnotu, ale s tím si pravděpodobně validátory poradit zvládnou.

Jo, a pomocí příkazu named -C se dá vypsat výchozí konfigurace dané verze, včetně výchozích dnssec-policy "default" a "insecure". Jenom toho vypíše dost, musíte si to najít přes less asi uprostřed.

Pokud se rozhodnete alespoň ZSK rotovat pravidelně, doporučil bych mít pro klíče každé zóny svůj podadresář. Mít to všechno v jednom je ok pro hrstku zón, ale už u desítky zón se v tom budete hůř orientovat.

Uvítal bych, kdyby zrovna tipy na zálohu a obnovení u příštího dílu nechyběly.

Ja teda i /var/cache bezne zalohuju, i kdyz teda co se tech klicu tyce... no, strkam je taky jinam :-) Ale pointa tam je, musi byt umoznen zapis, zvlast pokud chce clovek tezit z benefitu automatickych rotaci klicu.

Ono i u tech slave zon je zadouci, aby pri nejake disaster-recovery to bylo schopne nabehnout aspon s necim (i v situaci, ze primar zrovna nebezi).

Ty klice samy o sobe co se platnosti tyce jsou pomerne "blbuvzdorne", podstatny je timestamp u RRSIG zaznamu v samotne zone. Vlastni zkusenost, ja se ted u sveho "privatu" odhodlal odhodit sve letite sign scriptiky a prejit na built-in automat... a me vychozi "rucne" generovane ZSK byly dva roky stare... takze samozrejme bez .state file (ale uz v v1.3 formatu)... popralo se to s tim.

A co se prehlednosti tyce, samotne klice jde mit uplne jinde - nez jsou samotne zony. Ja to tak mam. Mam oddelene ZSK/KSK a bonusove dva algoritmy, v ramci jineho experimentovani. A prijde mi to jako rozumne mit ty klice proste bokem - do te struktury clovek bezne nepoleze... a kdyz, tak fakt musi vedet co dela. Ona ta orientace beztak neni trivialni, protoze ze samotneho nazvu souboru neni poznat role klice... jen domena + algoritmus a ID klice... samotne detaily jsou beztak az uvnitr.