Administrace komentářů

Dokazat by to samozrejme jit melo. Za timto ucelem jsem zvedl na resolveru debug level a nastavil jsem monitoring, ktery me mel varovat, az zacnou dotazy na frantovo.cz opet vracet servfail. K tomu doslo vcera v rannich hodinach (uzivatele nic nepoznali, protoze tentokrat problem nastal jen na jednom z resolveru - druhy frantovo.cz necachoval).

Zde je obsah cache v okamziku, kdy problem pretrvaval:

; secure frantovo.cz. 16598 NS ns.forpsi.cz. 16598 NS ns.forpsi.it. 16598 NS ns.forpsi.net. ; secure 11179 DS 36559 5 1 ( 96D37E81EE3FCE8701855B7E9696CC9BB5BC DE6E ) ; secure 11179 RRSIG DS 10 2 18000 20101030062621 ( 20101018223636 39508 cz. Esm5i+aFKuiWa5rH8J25XUw2sS6XKO7h+A2n z7P5WJpNej54eGfyz8vFOZmVHWbPcFuoMsYP LttJWO+BkrkFNVTPJ8YN7Mmg3kBIQcPRju3w eiR7UmjGA8t+qymSSexLRVjG31MEBHDdgqa1 xbCRooOljbmcJmfdzLd1Tpng1rI= ) ; pending-answer aurora.frantovo.cz. 927 AAAA 2001:15c0:66ef::18

Podstatne jsou dva nacachovane zaznamy - DS zaznam pro frantovo.cz a RRSIG (podpis) tohoto DS zaznamu podepsany klicem s tagem 39508.

A zde jsou DNSKEY zaznamy, ktere byly v te dobe poskytovany autoritativnimi servery:

frantovo.cz. 3600 IN DNSKEY 257 3 5 ( AwEAAcs9TvmBuXROwiVndYd+cfDDRVZumAIY+/150yVd nY37u3JqChesOSOf/ZPk2ExVEpIJFIk+EoUJSjO0hXUC eF990BItaQHZL5TUJz92pcVuRb0hmmUw7xtqvfvgtl4p BpEyf5BAzEKztXzba4EkRYnHGdvwk6q1hroNmaHiqXzl uponN/IM31GrxDQScT1iId5zRnF5X+Vt583Zs+QnIu4L B397o73wT7aAZ8o8eBeFeYedjiX+CW/G3oaDa21Lt4rY snyrShg9tV5u6r1RtxhX8YPpfbdzMysGfOt+SGH++6t0 SINXKi6d75SznkhmqVOkbFab7ZYhwREsDam47dc= ) ; key id = 36559 frantovo.cz. 3600 IN DNSKEY 256 3 5 ( AwEAAaaB8mVZhRPmS3LQnimXg5CJ2QV8JfHZiFuaeKwp F8MUg4t8Nu2cFrvHs8jJ5FIMbniN8YGfg3AHHT7sj9uF C04ulEpc/tGAuOSUNReyESIEFq0NbVeUaxZtJ1iaKY/H aHOoTWsTsWZY9i/CICsGey4/B7XW2hrAhcxbdi2gyzft ) ; key id = 56712

Jako platne jsou tudiz propagovany dva klice - s tagy 36559 (zone signing key) a 56712 ( key signing key ).

Resolver loguje "got insecure response; parent indicates it should be secure". Jeho postup pri overovani je nasledujici - provede tzv. "insecurity proof", to znamena, ze se zepta nadrazene autority (autoritativnich serveru pro zonu cz.), zda existuje DS zaznam pro frantovo.cz. Ten skutecne existuje:

;; ANSWER SECTION: frantovo.cz. 18000 IN DS 36559 5 1 96D37E81EE3FCE8701855B7E9696CC9BB5BCDE6E

Pak vsak resolver zjistuje, jestli existuje DS zaznam pro frantovo.cz v zone samotne, a zde pouzije nacachovane zaznamy - DS zaznam je v poradku, ale je podepsan spatnym klicem, ktery uz v zone frantovo.cz neni. Overeni tedy selze, DS zaznam se zahodi jako neduveryhodny a resolver usoudi, ze ackoliv by podle nadrazene autority mela byt zona podepsana (existuje DS zaznam), v zone samotne DS zaznam neni a tutiz se propaguje jako nepodepsana - proto chyba "got insecure response; parent indicates it should be secure". Resolver proto hlasi u vsech dotazu na tuto zonu rcode SERVFAIL.

Tento problem vznika proto, ze autoritativni servery nepouzivaji spravnou metodu key rolloveru - pri te by totiz mely nejdrive vypublikovat novy ZSK klic, podepsany tim starym, zaroven s tim vypublikovat nove RRSIG podpisy novym klicem pro vsechny zaznamy v zone, pak pockat minimalne TTL starych podpisu (nez tyto expiruji), a pak teprve stary klic a souvisejici podpisy smazat. Podle vseho vsak autoritativni servery forpsi proste v jeden okamzik nahradi stare klice i podpisy novymi, coz vede k popsanemu problemu (klice maji mesicni platnost, coz se shoduje s frekvenci vypadku).

Na problem jsem upozorni administratory firmy (F), ale zatim neprisla zadna odpoved.