Názory k článku DNSSEC snadno a rychle s automatickou správou v serveru BIND

Co to je za napad, davat perzistentni konfiguraci do /var/cache?

To je samozřejmě špatný nápad, proto to v článku ani na produkci neděláme. Perzistentní konfigurace je v /etc/bind/ a pouze pracovní adresář serveru je v /var/cache/bind/. Tak je to také popsané v článku.

Děkuji za článek, je to velmi užitečné.
Před časem jsem to sám řešil a jestli jsem to správně pochopil defaultní policy mění klíče po 90-ti dnech. Tím pádem se změní i DS záznam, že? U .cz domén je to v pohodě, ale co ostatní?
Vyřešil jsem to tak, že jsem udělal vlastní policy a změnu klíče zakázal. Ale není lepší řešení?

Nikoliv, výchozí politika klíče nemění, mění jen podpisy. Viz část csk key-directory lifetime unlimited algorithm 13.

Na nameserveru spravuji a podepisuji nadřízenou a podřízenou zónu, např. example.cz a net.example.cz. Je možné nastavit BIND tak, aby klíč z podřízené zóny automaticky vkládal do nadřízené zóny example.cz jako záznam DS?

Dá se na to použít utilita `dnssec-ds` bez ohledu na to, jestli je zóna na stejném serveru nebo není.

Myslíš jistě utilitu dnssec-cds. Ta skutečně dokáže hledat CDS záznamy v podřízených zónách a když je nalezne, buď zapíše DS záznamy do zoneletu, který je možné vložit do nadřazené zóny, nebo vygeneruje skript pro utilitu nsupdate, která změny v nadřazené zóně provede.

Trochu nepříjemné je, že je potřeba tuhle utilitu spouštět pravidelně, aby provedla změnu, která bude potřeba třeba jednou za rok. Knot DNS proti tomu dokáže přímo poslat zprávu UPDATE do nadřazené zóny v době, kdy je to potřeba.

Ondro, díky. Řeším stejný případ, doporučujete tedy použít spíše Knot DNS místo Bindu?

Oba programy jsou více méně srovnatelné a celkem robustní. Použijte ten, se kterým máte zkušenosti. Klíče v podřízených zónách neměňte. Je to nejjednodušší a dostatečně bezpečné pro naprostou většinu případů.

Ondro, nechceš prosím napsat feature request? ;-) Připadá mi to jako dobrý nápad, ale mám toho teď tolik, že si nejsem jistý, že zvládnu dobře naformulovat myšlenku jak by to mělo fungovat.

Zóny s NSEC3 lze také projít, jen se pak musí louskat hashe.
Na procházení jsem napsal utilitku.

https://github.com/unsecured-company/nsec3walker

Ano, je to tak. Ostatně je možné do jisté míry projít i zóny bez DNSSEC, protože většina doménových jmen jsou slovníková slova a není problém jich aktivním dotazováním vyzkoušet stovky až tisíce za sekundu, čehož si málokdo všimne.

Proto taky aktuální doporučení pro nasazení DNSSEC a výchozí politika počítá s použitím NSEC, protože ostatně DNS je veřejný telefonní seznam.

Jen s tim narativem "verejny seznam" by se rovnou mohlo vsude nechavat povolene AXFR jako za starych dobrych casu. Prochazeni zony s NSEC je zhruba tak stejne narocne. Proc to delat utocnikum slozitejsi a mj. konzumovat jejich zdroje, kdyz se jim data muzou naservirovat data o nejake vnitrni infrastrukture na stribrnem podnose a usetrit mu praci s mapovanim infrastruktury. No ostatne mnohe (nejen statni) instituce takto beztak funguji, tak co... pricemz nekteri "experti" to tam maji vc. veci, co by v public view byt vubec nemeli (coz se na prvni dobrou casto pozna z RFC1018 adres u A zaznamu).

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.