Administrace komentářů

> 23.10. 17:28 byl do zóny přidán nový ZSK s tagem 42231
> 23.10. 18:28 byla celá zóna podepsána tímto novým klíčem

Tahle operace je dost na hraně, protože záznam DNSKEY má TTL 3600 sekund, pokud se nepoužívá double-signature metoda. Pokud by došlo k nakešování záznamu DNSKEY těsně před přidáním nového ZSK a podepsání novým klíčem (a zrušení podpisů starým ZSK) by proběhlo dříve než TTL(DNSKEY), tak dojde k selhání validace.

Máte pravdu, jisté riziko tady existuje, ale je velice malé - chyby v časování (skluz hodin, rozdílná zátěž stroje) se dostanou nejvýše do řádu sekund a je tedy málo pravděpodobné, že si příslušná cache vyžádá starý DNSKEY sekundu před publikací nového a následně se také přesně trefí s vyžádáním podpisů do okamžiku, kdy už je publikovaná nové zóna (s novými podpisy a oběma klíči) a zároveň cache obsahuje ještě starý DNSKEY. Navíc to vychází z předpokladu, že 1) cache neprovádí spekulativní přednačtení záznamů před vypršením TTL a 2) cache po selhání validace s DNSKEY sadou, které zbývá chvilka do vypršení, neprovede dotaz na čerstvý DNSKEY (kde by v tu chvíli již byly oba).

Protože je vznik celého popsaného problému silně závislý na shodě několika okolností, i v případě, že by k němu skutečně došlo (cache by prohlásila nové podpisy za nevalidní a vrátila SRVFAIL), by byl pravděpodobně "zameten pod koberec" existujícími mechanismy na straně klienta (který by automaticky poslal dotaz jiné cachi, která by se určitě do daného časování netrefila, případně by dotaz zopakoval o chvíli později, kdy už by starý DNSKEY definitivně vypršel).

Není ale asi úplně nutné pokoušet osud kvůli několika minutám, takže nejspíš mírně zvednu prodlevu před generováním nových podpisů.

> 24.10. 18:58 byl starý ZSK odstraněn

Toto časování nesmí být založeno na maximální hodnotě, ale na nejvyšším TTL, které je v konkrétní zóně.

Můžete to trochu upřesnit? Ano, v ideálním světě by starý (a možná kompromitovaný) klíč nezůstal v zóně ani o minutu déle, než by bylo nezbytně nutné, ale žádné reálné bezpečnostní riziko v tom nevidím (po uběhnutí TTL všechny podpisy vytvořené starým klíčem expirovaly a samotný klíč se tím stal jen balastem zvětšujícím sadu DNSKEY). Časování řízené aktuálně nejvyšším TTL by značně zkomplikovalo celý systém a nepřijde mi, že by přineslo nějakou podstatnou výhodu.

> Interval 24 hodin, po který jsou platné oba klíče, musí být dostačující, neboť žádný záznam nemůže mít delší TTL.

http://www.zytrax.com/books/dns/ch7/hkpng.html

max-cache-ttl sets the maximum time (in seconds) for which the server will cache positive answers (negative answers NXDOMAIN is defined by max-ncache-ttl). The default is one week (7 days). This statement may be used in view or a global options clause.

Maximální hodnota TTL je určena velikostí pole v RR záznamu a to je 2^31 (specifikace říká signed 32-bit integer).

Tady se omlouvám za zavádějící vyjádření. Tím, že "žádný záznam nemůže mít delší TTL" jsem chtěl říct "DNS systém FORPSI omezuje TTL všech vkládaných záznamů shora na 86400 sekund a nehrozí tedy nebezpečí, že by jakákoli zóna v něm obsahovala záznam s vyšším TTL." Samozřejmě to neznamená, že by nikdo na světě nesměl použít delší TTL.

Ve chvíli, kdy dojde k dalšímu selhání, tak bych doporučoval použít otevřené validující servery CZ.NICu: http://labs.nic.cz/odvr/, kde jeden ze serverů je Unbound a jeden je Bind9.7.

Ty nám v tomto případě nebudou pravděpodobně nic platné, neboť z nich nedostaneme detailní logy, historii dotazů ani obsah cache/coredump, takže stejně nic nezjistíme. Navíc od začátku prosince provozuji nezávisle jak Unbound 1.4.7, tak BIND 9.7.0 a každých 10 minut se jich ptám na www.frantovo.cz, stále jsem však nedostal jediný SRVFAIL.