Dotaz: DNSSEC smrt domény?

[xkucf03]

Ahoj,

mám problém s DNSSEC – u svého registrátora, říkejme mu (F), jsem pro svoje domény aktivoval DNSSEC a nějakou dobu vypadalo všechno OK. Ale pak jsem náhodou zjistil, že když se na svoji doménu dotáži DNS serverů svého domácího ISP, říkejme mu (V), dostanu

** server can't find frantovo.cz: SERVFAIL

dost zvláštní je, že u žádných jiných DNS serverů jsem na tuto chybu nenarazil – jen u serverů firmy (V). Zkoušel jsem Googlí DNS servery, OpenDNS, DNS v mojí serverovně, ve škole, validator.w3.org, monitoring-serveru.cz – kdokoli kromě (V) je schopný moje domény přeložit správně. Jiné domény chráněné pomocí DNSSEC (např. nic.cz) pomocí serverů (V) ale přeložit jdou.

Psal jsem na podporu (F) i (V), obě firmy tvrdily, že za to může ten druhý, v prvním kole to dopadlo tak, že (V) restartovali svoje DNS servery a překlady najednou fungovaly. Včera jsem ale zjistil, že servery (V) opět nepřekládají (jiné DNS servery moje domény vesele překládají celou dobu), tak jsem zase psal oběma firmám, ať si to vyříkají mezi sebou, že je mi jedno, kdo za to může, ale ať to spraví. (V) odepsali, že za to může (F) a přeposlali mi „odpověď techniků“, kterou posílali už minule (že je to prý DNSSEC smrt domény). (F) zatím neodpověděli.

Nemám potřebu stranit ani jedné firmě, je mi to celkem jedno čí je to vina – ale rád bych, aby to (opět) začalo fungovat. Kdo za to podle vás může? Koho mám víc prudit, aby to opravil?

Díky, Franta

P.S. IMHO je podle:

drill -D frantovo.cz @ns.forpsi.cz

podpis stále platný – nebo ne?

---

---

Odpovědi

[xHire]

Doména frantovo.cz je podepsaná správně -- můj resolver ji zvaliduje bez problémů. Ovšem Google Public DNS, ani OpenDNS nejsou vhodné referenční DNS resolvery, co se týče DNSSECu (ony totiž vůbec nevalidují!). Podobně to asi bude i s tvým resolverem v serverovně, s tím ve škole, u w3c i u monitoring-serveru.cz.

Pokud má (V) problémy s validací podle DNSSECu, těžko říct, čím to může být. Každopádně bych se v tomto případě klonil k tomu, že viníkem je (V).

Mimochodem, pokud chceš příklady mrtvých domén pro testování, tak vím o rhybar.cz, voipex.cz a pravnik-nonstop.cz. První je záměrně mrtvá, další dvě jsou příklady z praxe (řekněme „mrtvé nezáměrně”; každá z těch dvou je navíc mrtvá jinak).

[xkucf03]

Např. Google toho rhybáře taky nepřeloží:

$ nslookup rhybar.cz 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
*** Can't find rhybar.cz: No answer

Zatímco OpenDNS ano:

$ nslookup rhybar.cz 208.67.222.222
Server:         208.67.222.222
Address:        208.67.222.222#53

Non-authoritative answer:
Name:   rhybar.cz
Address: 67.215.65.132

Nicméně server ve škole validuje, v serverovně taky a můj vlastní doma taky – tyhle servery moji doménu přeloží a na rhybáře odpoví SERVFAIL. DNS servery (V) odpoví SERVFAIL jak na rhybáře, tak na moji doménu.

Na druhou stranu třeba takovou doménu www.nic.cz jsou u (V) schopní v pohodě přeložit, takže úplně rozbité to nemají. Problém se tedy týká situace, kdy je doména registrovaná u (F) a používají se DNS servery (V) – při jiné kombinaci registrátora a DNS serverů jsem na problém nenarazil.

[xkucf03]

sorry, to s tím Googlem a OpenDNS ignorujte – www.rhybar.cz Google přeloží, rhybar.cz neexistuje, ale OpenDNS ho přeloží na tu svoji sračku (vyhledávač) stejně jako každou neexistující doménu, dělají v tom akorát bordel

[Mrkva]

Nevím, jestli to má souvislost, ale když se pokusím zeptat na svojí (nepodepsanou) doménu (mrkva.eu) rekurzivního DNS, co mi běží na localhostu, dostanu tohle:

mrkva@Destiny:~$ dig mrkva.eu

; <<>> DiG 9.7.1-P2 <<>> mrkva.eu
;; global options: +cmd
;; connection timed out; no servers could be reached

V syslogu se objeví:

Oct 10 12:26:31 Destiny named[23730]: error (no valid RRSIG) resolving 'mrkva.eu/DS/IN': 91.200.16.100#53
Oct 10 12:26:31 Destiny named[23730]:   validating @0x7f3e2c002400: QBQ65Q6097OCPPR0EUCQNSC1FHE073UA.eu NSEC3: no valid signature found
Oct 10 12:26:31 Destiny named[23730]: error (no valid RRSIG) resolving 'mrkva.eu/DS/IN': 195.66.241.178#53
Oct 10 12:26:31 Destiny named[23730]: error (no valid DS) resolving 'mrkva.eu/A/IN': 81.0.238.27#53

Pokud zakomentuji dnssec-enable yes;, dnssec-validation yes; a klíč pro kořenovou zónu, všechno se provede v pořádku

[Honza Jaroš]

Tohle vypadá, že něco podělali správci nameserverů pro celou doménu .eu. Protože pokud chápu výstup z digu dobře, je doména v tuhle chvíli podepsaná, ale nameservery podpis nevracejí...

dig +dnssec NS eu. @a.nic.eu

; <<>> DiG 9.7.1 <<>> +dnssec NS eu. @a.nic.eu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23762
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;eu.                IN    NS

;; ANSWER SECTION:
eu.            86400    IN    NS    l.nic.eu.
eu.            86400    IN    NS    m.nic.eu.
eu.            86400    IN    NS    l.eu.dns.be.
eu.            86400    IN    NS    a.nic.eu.
eu.            86400    IN    NS    p.nic.eu.
eu.            86400    IN    NS    x.nic.eu.
eu.            86400    IN    NS    y.nic.eu.
eu.            86400    IN    RRSIG    NS 7 1 86400 20101103131607 20101004131607 61808 eu. cybO2yGftibcoVoIQAOvIgS90XSq57rb3Rmt7DfVZdNn1U9e0b65TEne Vx2Imlxdhydm9e7YW6R1CA/AdDkD6o6i65N6VWng97pHv2aDnV5mNzg6 dWIINL/i1piZ2y+mI6D999n9fpjxi0+LjPddIY20wfNUnwDL8AwZkL/Y bNA=

;; Query time: 21 msec
;; SERVER: 91.200.16.100#53(91.200.16.100)
;; WHEN: Sun Oct 10 12:57:30 2010
;; MSG SIZE  rcvd: 318

dig +dnssec a a.nic.eu @a.nic.eu

; <<>> DiG 9.7.1 <<>> +dnssec a a.nic.eu @a.nic.eu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1505
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;a.nic.eu.            IN    A

;; ANSWER SECTION:
a.nic.eu.        259200    IN    A    91.200.16.100

;; AUTHORITY SECTION:
nic.eu.            86400    IN    NS    l.nic.eu.
nic.eu.            86400    IN    NS    p.nic.eu.
nic.eu.            86400    IN    NS    a.nic.eu.

;; ADDITIONAL SECTION:
l.nic.eu.        259200    IN    A    195.66.241.178
p.nic.eu.        259200    IN    A    195.47.235.130

;; Query time: 22 msec
;; SERVER: 91.200.16.100#53(91.200.16.100)
;; WHEN: Sun Oct 10 13:02:14 2010
;; MSG SIZE  rcvd: 131

[xkucf03]

To museli podělat nedávno, protože ještě před pár dny moje doména rozpad.eu fungovala a teď už nefunguje. Asi už se ta EU fakt rozpadá :-P

.eu domény se dají přeložit třeba pomocí 8.8.8.8 (Google), ale validující DNS servery vrací SERVFAIL.

[Honza Jaroš]

No právě. Já mám zákazníka se servery v doméně .eu a ještě teď v týdnu jsem se k němu dostal, aniž bych si musel na bindu vypnout DNSSEC validaci. A Zabbix, přes kterého si monitoruju dostupnost jejich SMTP serverů, mi začal hlásit chybu někdy před dvěma hodinama...

Zatím se snažím pochopit, v čem je vlastně problém, s DNSSEC začínám a nejsem si jist, jestli to, co jsem napsal výše, není blbost...

[Honza Jaroš]

Jestli není problém tady?

~ # dig NS eu. +dnssec @a.root-servers.net. | grep RRSIG
eu.            86400    IN    RRSIG    DS 8 1 86400 20101017000000 20101009230000 40288 . Uxo05H0wnsn6trAtxso3PbOqtKb3nq+8YGynd+J5d3W4oqxjpAIB/G5B 7hcN4/nbp514JBZQOZZpd6CNwFGyKt2teMfrsPBynpPpBqFrOtOlip+y VlDNiNRnXdBZuP6MRkOkfPVdZ/pPPznmq+iotozTwLTJNhpfOYiw1Uxu OQM=

~ # dig NS eu. +dnssec @a.nic.eu. | grep RRSIG
eu.            86400    IN    RRSIG    NS 7 1 86400 20101103131607 20101004131607 61808 eu. cybO2yGftibcoVoIQAOvIgS90XSq57rb3Rmt7DfVZdNn1U9e0b65TEne Vx2Imlxdhydm9e7YW6R1CA/AdDkD6o6i65N6VWng97pHv2aDnV5mNzg6 dWIINL/i1piZ2y+mI6D999n9fpjxi0+LjPddIY20wfNUnwDL8AwZkL/Y bNA=

Pokud to dobře čtu, tak na kořenových naserverech mají novější podpis než na serverech domény eu...

[Daniel Ryšlink]

Tady se Vám podařilo udělat hned několik velmi poučných chyb:

V obou případech se ptáte na NS záznam domény eu - v prvním případě rootovského nameserveru, v druhém případě autoritativního nameserveru, na který je doména eu. delegována. Potíž je ale se šablonovitým použitím příkazu grep; kořenový nameserver vám na dotaz vrátí odpověď s prázdnou ANSWER sekcí (protože NS záznam k eu. nezná), ale poskytne informaci o serverech, na které je zóna eu. delegována v AUTHORITY sekci. V této sekcjou jsou také DS záznamy pro eu. včetně podpisu - a právě tento podpis DS záznamu Váš grep zachytil kvůli řetězci 'ns' v podpisu samotném (Uxo05H0wnsn6...).

V druhém případě už grep zachytil skutečně podepsaný NS záznam domény eu., ale odlišnost od podpisu v minulém případě nás nepřekvapí - jedná se o různé záznamy podepsané různými klíči. Měl by vás hned zarazit fakt, že podpis má KEYTAG jiného klíče (40288 vs. 61808).

Stejný záznam může být totiž podepsán více klíči, což pak odpovídá více RRSIG záznamů s různými KEYTAGy. Je to dokonce nezbytné při rolloveru nových klíčů. Pokud totiž chcete použít k podepisování záznamů nový klíč, musíte ho nejdřív podepsat tím starým, a zároveň připojit podpisy ostatních záznamů tímto novým klíčem, počkat, až se vypublikuje (tzn. nejméně po dobu TTL záznamů), a teprve poté, když jsou záznamy podepsané dvěma klíči (novým a starým) najednou, teprve tehdy můžete ten starý odebrat.

Pokud to neuděláte, způsobíte tzv. DNSSEC smrt, protože resolver, který věřil starému klíči, náhle nachází zónu podepsanou jiným klíčem, kterému nevěří, a výsledkem je servfail až do expirace starých podpisů a KEYSETů. Resolver, který doménu předtím neresolvil (a nemá nacachované staré klíče), přitom samozřejmě bude zónu resolvit bez problémů, což právě v tomhle případě není důkaz, že byl rollover proveden správně.

Níže je o tom pěkné povídání, tak si ho prosím přečtěte, a dejte ho pokud možno přečíst také svému registrátorovi domén, aby se podobné incidenty nemusely opakovat.

Firmy nezvládají DNSSEC a domény umírají

[Daniel Ryšlink]

Omlouvám se, uvedený odkaz v minulém příspěvku popisuje podobný, ale jiný typ problému (přechod od podepsané zóny k nepodepsané). Relevantní materiál najdete, pokud si vygooglujete "DNSSec key rollover", článků a diskusí na toto téma je hodně.

[xkucf03]

Tahle odpověď je ve vlákně o .eu doméně, tak nevím, jestli se týká i mého problému a jestli je Daniel Ryšlink z (V), nicméně: znamená to, že (F) dělá svoji práci špatně? Jak se to dá dokázat?

[Daniel Ryslink]

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.

[Daniel Ryšlink]

Musim se jeste opravit - "Pak vsak resolver zjistuje, jestli existuje DS zaznam pro frantovo.cz v zone samotne" - tohle je nesmysl, v zone samotne DS zaznam neni, nemelo by to smysl. Trvam ovsem na puvodni premise, ze problem je zpusoben tim, ze byly predcasne odstraneny stare klice, takze pri overovani podpisu pouzije resolver podpis DS zaznamu z cache a zjisti, ze klic, kterym byl zaznam podepsan, neni v DS zaznamech u nadrazene autority uveden jako platny.

[Tomáš Trnka]

Což o to, teorie je to hezká, ale daný problém nevysvětluje ani trochu.

Jak je vidět z Vašeho příspěvku, cesta z nadřazené zóny cz ke KSK frantovo.cz je v pořádku (nacachovaný DS je podepsán klíčem 39508, což je současný ZSK CZ.NICu, a míří na klíč 36559, což je KSK frantovo.cz (již několik měsíců je a dalšího třičtvrtě roku ještě bude, zde nedošlo k vůbec žádné změně)).

Naznačujete, že by mohlo jít o nezvládnutou rotaci ZSK. DNS systém FORPSI by podle všeho (kódu, testů a funkčnosti ostatních zón/rekurzivních NS) měl provádět rotaci správným způsobem (i když všichni dobře víme, že každý program obsahuje chyby). Druhý a výrazně pádnější argument je, že v době výskytu problému k žádné rotaci klíčů v dotčené zóně nedocházelo. ZSK zóny frantovo.cz byl rotován až více než den poté, co jste tento příspěvek napsal. Konkrétně:

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

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

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.

Jediné rozumně znějící vysvětlení tohoto chování je chyba v BINDu.

[Foo Bar]

> 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.

> 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ě.

> 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).

Nicméně vyřazení starého ZSK již další den by u záznamu www.frantovo.cz neměl způsobovat problémy, jelikož TTL u www.frantovo.cz je jen jedna hodina.

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.

[Tomáš Trnka]

> 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.

[Foo Bar]

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ů.

Bezva.

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.

Objasním:

;; ANSWER SECTION:
maxttl.rfc1925.org.	2147483647 IN	TXT	"2^32"
maxttl.rfc1925.org.	2147483647 IN	RRSIG	TXT
  10 3 2147483647 20110125025021 20110118125724 53043 rfc1925.org. 
  luNcubW+WaYWiMpXy+DWfk0/RB71XUo6VcGK8lZ9zFTmw68fpQw/i1xe 
  4sQ3WXkKwbLJves7kZ5GY+aO0my5twdn9CZ0RosqcrKY/mEgkzGRM7Fg 
  U7tm5uK8dijoaJg5n/ZBlF8HfbEzmzkvBDs7GDI0rnGu5pRyhLS2AnrL
  lJY=

TTL podpisů je shodné s TTL záznamu. Tudíž resolver si uloží do cache RRSIG(ZSK1), který tam zůstane (teoreticky) 2^31 sekund. Nicméně pokud mezitím dojde k výměně ZSK1 za ZSK2 a vyřazení ZSK1 ze zóny (po jednom dni), tak jste v situaci, kdy po vypršení záznamu DNSKEY z cache resolveru máte v cache uložen RRSIG-ZSK1, ale v DNSKEY už máte jen ZSK2 => podpis je bogus.

Každopádně jsme se pravděpodobně špatně pochopili. Já mluvím o minimální hodnotě a vy o maximální. Tj. čas odstranění nemusíte snižovat, pokud je větší nebo roven největšímu TTL v zóně. Nicméně bych opět doporučil nechat tam nějakou rezervu.

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.

Spíš jde o "triangulaci". A pokud budeme vědět, že k problému dochází i na našich ODVR, tak není problém výše uvedené zajistit. Kdyžtak mi napište na pracovní email (ondrej.sury@nic.cz), a domluvíme se. (Předchozí text je přínosný i pro ostatní "early adopters", proto jsem jej umístil zde.)

[xkucf03]

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.

Na nich překlad funguje:

$ nslookup frantovo.cz 217.31.204.131
Server:         217.31.204.131
Address:        217.31.204.131#53

Non-authoritative answer:
Name:   frantovo.cz
Address: 83.167.252.161

$ nslookup frantovo.cz 217.31.204.130
Server:         217.31.204.130                                    
Address:        217.31.204.130#53

Non-authoritative answer:
Name:   frantovo.cz
Address: 83.167.252.161

Ale na serverech mého poskytovatele (Volný.cz) zase nefunguje:

$ nslookup frantovo.cz 212.20.96.34
Server:         212.20.96.34
Address:        212.20.96.34#53

** server can't find frantovo.cz: SERVFAIL

$ nslookup frantovo.cz 212.20.96.38
Server:         212.20.96.38
Address:        212.20.96.38#53

** server can't find frantovo.cz: SERVFAIL

Překlad pomocí mého vlastního validujícího DNS serveru taky funguje. Zatím se mi nepodařilo s jistotou lokalizovat problém. SERVFAIL vrací jen servery Volný.cz. Jednou se mi ztratil* e-mail směřující ze Seznamu do mojí domény, ale nevím na 100% jestli to souvisí s DNSSEC. Jako by servery, na které chodí dotazy na danou doménu často (můj a NIC) odpovídaly správně a servery dotazované méně často (Volný?) trpí chybou… ale to je asi blbost. Kdo máte validující DNS server, tak prosím vyzkoušejte, jestli se vám tuhle doménu podaří přeložit.

*) resp. odesílateli přišla zpráva, že e-mail nebyl doručen:

5.4.3 smtp; no valid MX record
Nepodařilo se zjistit emailový server odesílatele. 
Permanent Failure - Routing server failure

(jen pro pořádek: MX záznamy jsem už hodně dlouho neměnil)

[Foo Bar]

Rozumím tomu správně tak, že včera opět došlo k selhání validace?

[xkucf03]

Ano a nejen včera – poslední dobou víckrát, posílal jsem to mailem na Forpsi i Volný. Zatím žádné zlepšení, pořád SERVFAIL. Nepřekládají se ani jiné domény, co mám u stejného registrátora, ale třeba nic.cz přeložit schopní jsou.

[Foo Bar]

Můžete se ve chvíli, kdy dostáváte SERVFAIL, poslat na ten selhávající server tyto tři dotazy:

dig +cd +dnssec +multi IN DS frantovo.cz @<server>
dig +cd +dnssec +multi IN DNSSEC frantovo.cz @<server>
dig +cd +dnssec +multi IN AAAA www.frantovo.cz @<server>

A poslat výstup mě na mail (nebo sem). Tím bychom měli chytnout, co má server aktuálně v cache.

Díky.

[xkucf03]

$ dig +cd +dnssec +multi IN DS frantovo.cz @212.20.96.34

; <<>> DiG 9.7.1-P2 <<>> +cd +dnssec +multi IN DS frantovo.cz @212.20.96.34
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17086
;; flags: qr rd ra ad cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;frantovo.cz.           IN DS

;; ANSWER SECTION:
frantovo.cz.            5728 IN DS 36559 5 1 (
                                96D37E81EE3FCE8701855B7E9696CC9BB5BCDE6E )
frantovo.cz.            5728 IN RRSIG DS 10 2 18000 20110129204456 (
                                20110118070609 34702 cz.
                                CFR5o4hEbcTrPOj/r5RZ3efvH4l7BXEKnQ+q9pMuR0DT
                                04cAGyEYhUN7p5j4O+fNsqegpauv8fyj1Vc9mVWaAJxg
                                w/SY1UHuYmeVFG6UJOL75X9nLLMR7fybWwB3GmJHxwMR
                                T5FEff5JVG4dgcm7DoTk5TjY7FYFkEvhU1IMc+g= )

;; Query time: 10 msec
;; SERVER: 212.20.96.34#53(212.20.96.34)
;; WHEN: Wed Jan 19 12:35:13 2011
;; MSG SIZE  rcvd: 238












$ dig +cd +dnssec +multi IN DNSSEC frantovo.cz @212.20.96.34

; <<>> DiG 9.7.1-P2 <<>> +cd +dnssec +multi IN DNSSEC frantovo.cz @212.20.96.34
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27118             
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;DNSSEC.                        IN A

;; AUTHORITY SECTION:
.                       10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. (
                                2011011900 ; serial
                                1800       ; refresh (30 minutes)
                                900        ; retry (15 minutes)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
.                       10800 IN RRSIG SOA 8 0 86400 20110126000000 (
                                20110118230000 21639 .
                                uzhT8av0vtVR90iVAuYBKdCPPOHgh8XSeCQ/DZXPb/xo
                                I4Xjw1CndAIne8zoDcK5Tn84ZWo3aWrIj5JevufEAvvr
                                IGKlftKwzL8D32NpCLnhFzyaI4lVHfElFcnjQL30IOD0
                                3URh5qbh+REP52ySyzFBZlq2KuswQpcMX/gKEBI= )
.                       10800 IN RRSIG NSEC 8 0 86400 20110126000000 (
                                20110118230000 21639 .
                                Q9mcrU3yXu7UgA0Zql/MZH8jphxiyPQ49snxT9UZgtPK
                                phDtdZzZa+6BG29jzfeGxVZoR1huzr8QGpYsIRk06CjS
                                JdU9zRhyT00dC2jqra0ih4silWL9w08yGP+EmY7mPqLV
                                UHQAZ+EdAy9dwKupi2H+YBXC16atoKeoiYQ7oYM= )
.                       10800 IN NSEC ac. NS SOA RRSIG NSEC DNSKEY
dm.                     10800 IN RRSIG NSEC 8 1 86400 20110126000000 (
                                20110118230000 21639 .
                                YaKvBE95X5XnJ6C6luHtoknLou87cRQiZtO8TQdM6ZsN
                                yV1PSRjgdlU9l+Ten8dxeYUzMNhJoA7QxETheGQRPepH
                                dZuB/CgLKNh5CTOuW+vQqX69StEIrj88gUL4cZcO83dD
                                BuR9i+hNQmrEFrgwiu5ZfQnGOtXNxK+WaFVglak= )
dm.                     10800 IN NSEC do. NS RRSIG NSEC

;; Query time: 17 msec
;; SERVER: 10.0.0.8#53(10.0.0.8)
;; WHEN: Wed Jan 19 12:35:13 2011
;; MSG SIZE  rcvd: 635

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45215
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;frantovo.cz.           IN A

;; ANSWER SECTION:
frantovo.cz.            1800 IN A 83.167.252.161

;; AUTHORITY SECTION:
frantovo.cz.            5728 IN NS ns.forpsi.it.
frantovo.cz.            5728 IN NS ns.forpsi.cz.
frantovo.cz.            5728 IN NS ns.forpsi.net.

;; ADDITIONAL SECTION:
ns.forpsi.cz.           1545 IN A 81.2.209.185
ns.forpsi.it.           721 IN A 62.149.230.87
ns.forpsi.net.          1376 IN A 81.2.194.130

;; Query time: 22 msec
;; SERVER: 212.20.96.34#53(212.20.96.34)
;; WHEN: Wed Jan 19 12:35:13 2011
;; MSG SIZE  rcvd: 181










$ dig +cd +dnssec +multi IN AAAA www.frantovo.cz @212.20.96.34

; <<>> DiG 9.7.1-P2 <<>> +cd +dnssec +multi IN AAAA www.frantovo.cz @212.20.96.34
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15440
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.frantovo.cz.       IN AAAA

;; ANSWER SECTION:
www.frantovo.cz.        1800 IN CNAME frantovo.cz.
frantovo.cz.            1800 IN AAAA 2a01:430:2e::161

;; AUTHORITY SECTION:
frantovo.cz.            5727 IN NS ns.forpsi.it.
frantovo.cz.            5727 IN NS ns.forpsi.cz.
frantovo.cz.            5727 IN NS ns.forpsi.net.

;; ADDITIONAL SECTION:
ns.forpsi.cz.           1544 IN A 81.2.209.185
ns.forpsi.it.           720 IN A 62.149.230.87
ns.forpsi.net.          1375 IN A 81.2.194.130

;; Query time: 30 msec
;; SERVER: 212.20.96.34#53(212.20.96.34)
;; WHEN: Wed Jan 19 12:35:14 2011
;; MSG SIZE  rcvd: 211

[Tomáš Trnka]

Ten druhý dotaz měl zřejmě být na DNSKEY a nikoli DNSSEC, můžete to prosím ještě doplnit?

[Foo Bar]

Pardon, ten druhý dotaz měl být "IN DNSKEY" a nikoli "IN DNSSEC". Můžete tenhle dotaz prosím udělat znovu? Jinak už od pohledu je něco špatně, protože odpověď na "IN DS" (tedy záznamy ze serverů pro zónu .CZ) korektně obsahují podpis (+DNSSEC), zatímco ke všem ostatním dotazům, na které se resolver ptá už přímo autoritativních serverů pro frantovo.cz, již ty RRSIGy jsou pryč a to je pravděpodobně příčina toho selhání.

Přikláním se k tomu, že se jedná o nějakou chybu bindu.

Můžete prosím ještě zkusit poslat:

dig CH TXT version.bind. @212.20.96.34

Jestli to něco vrátí?

[xkucf03]

Pardon, ten druhý dotaz měl být "IN DNSKEY" a nikoli "IN DNSSEC".

$ dig +cd +dnssec +multi IN DNSKEY frantovo.cz @212.20.96.34

; <<>> DiG 9.7.1-P2 <<>> +cd +dnssec +multi IN DNSKEY frantovo.cz @212.20.96.34
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19395
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;frantovo.cz.           IN DNSKEY

;; ANSWER SECTION:
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 (
                                AwEAAbLOC2rmhsbt1GaJKF4k9ydyzKG2vLm1ctu+vgrJ
                                8Xyr54ll9QthLm4wZ6jfGaVfS4LoB8JDNbErLsMjeknh
                                nEhmocQYjoyWu3q7iGoka6iP1RZGJ3s6/cw4oKyc6e/j
                                LFHWtT6vE9qjyyFcgIrMs4h8b9NE4qzNFWO6+bvQod1P
                                ) ; key id = 34308

;; Query time: 31 msec
;; SERVER: 212.20.96.34#53(212.20.96.34)
;; WHEN: Wed Jan 19 13:03:34 2011
;; MSG SIZE  rcvd: 464

Můžete prosím ještě zkusit poslat: dig CH TXT version.bind. @212.20.96.34

dig CH TXT version.bind. @212.20.96.34

; <<>> DiG 9.7.1-P2 <<>> CH TXT version.bind. @212.20.96.34
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45588
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;version.bind.                  CH      TXT

;; ANSWER SECTION:
version.bind.           0       CH      TXT     "ns2.vol.cz"

;; AUTHORITY SECTION:
version.bind.           0       CH      NS      version.bind.

;; Query time: 10 msec
;; SERVER: 212.20.96.34#53(212.20.96.34)
;; WHEN: Wed Jan 19 13:05:30 2011
;; MSG SIZE  rcvd: 67

Přikláním se k tomu, že se jedná o nějakou chybu bindu.

Na které straně? Když jsem si před časem psal s lidmi z Volný.cz, tak prý používají stejnou verzi jako já (BIND 9.7) a stejnou konfiguraci (v named.conf.options)

[Tomáš Trnka]

Přikláním se k tomu, že se jedná o nějakou chybu bindu.

Na které straně? Když jsem si před časem psal s lidmi z Volný.cz, tak prý používají stejnou verzi jako já (BIND 9.7) a stejnou konfiguraci (v named.conf.options)

Na straně autoritativních serverů FORPSI určitě ne, neboť tam žádný BIND není (běží na djbdns). Je ale možné, že nějaká odchylka chování autoritativních serverů od RFC (či od toho, jak si BIND představuje, že má svět fungovat) spouští nějakou chybu v BINDu u Volného. Navíc "verze 9.7" je poměrně široký pojem...

[Foo Bar]

Byl byste schopný a ochotný pustit na všech třech ns.forpsi.{it,cz,net} serverech dnscap[1] a chvíli sbírat dotazy a odpovědi, který jdou od resolverů Volného? To je v tuto chvíli dle mého jeden z nejjednodušších způsobů, jak lokalizovat, kde vzniká problém.

1. https://www.dns-oarc.net/tools/dnscap

[Foo Bar]

Na které straně?

Jedna zásadní chyba je, že výpisy dotazů, které jste poslal neobsahují žádný RRSIG. Což může být buď nějaká chyba v Bindu na straně Volného, nebo něco, co vzniklo v kombinaci s implementací DNSSEC/EDNS0 v djbdns.

Bind 9.7 může být: 9.7.0, 9.7.0-P1, 9.7.0-P2, 9.7.1, 9.7.1-P1, 9.7.1-P2, 9.7.2, 9.7.2-P1, 9.7.2-P2 nebo 9.7.2-P3. Jednotlivé verze se navíc mohou lišit distribuci od distribuce aplikovanými záplatami.

Obecně jsem kontroloval release notes u všech těchto (vanilla) verzí a ač tam nějaké opravy týkající se DNSSECu byly, tak se mi nezdá, že by některá z nich měla způsobovat toto chování.

Navíc se obávám, že porovnávat vaší domácí instalaci lze jen těžko porovnávat s instalací u Volného, protože se bude řádově lišit v zátěži, počtu záznamů v cache, atp. Nicméně můžete zkusit nasimulovat zátěž na vašem lokálním bindu pomocí dnsperf/resperf[1] a do toho se ptát na frantovo.cz.

O.S.

1. http://www.nominum.com/resources/measurement-tools

[xkucf03]

P.S. a domény kolegy (shadow.cz) je na tom úplně stejně.

Rád bych našel alespoň jeden další DNS server, který bude vracet SERVFAIL – zatím je totiž ten problém potvrzený jen v kombinaci Forpsi-Volný, nikde jinde jsem ho nepozoroval.

[Honza Jaroš]

Díky za informace. Že tam vlastně budou klíče podepsané klíči mi pak došlo taky, jen jsem to tu už pak nechtěl dál rozpitvávat. Výměna klíčů je hezky popsána na webu CZ.NIC, až to budu někdy dělat, budu postupovat podle jejich návodu.

Každopádně stále marně pátrám po tom, co se vlastně včera s doménou .eu dělo, přes dvě hodiny prostě nešla přes DNSSEC ověřit. Jak v takovémhle případě postupovat, když chci zjistit, kde přesně vznikl problém? Poradíte?

[Honza Jaroš]

Ha, tak jsem se konečně dopracoval k utilitě "drill", o níž jsem až dosud jen slyšel, protože jsem jí jak blbec hledal v jiném balíčku, než ve kterém byla. A ejhle, výstupy trasování DNSSEC jsou najednou srozumitelné a nechá se z nich poznat, kde došlo k chybě (alespoň soudě podle rhybar.cz).

Příště si budu dávat větší pozor na hlášky typu "Při odstraňování problémů s nastaveními DNSSEC můžete použít „dig“ i „drill“ z distribuce BIND", jednak bych pak nehledal drill v bind-tools, jednak bych se ho nesnažil nahradit digem... :-/

[Mrkva]

No, překlad podepsaných .eu domén (tedy třeba eurid.eu) zdá se funguje. Ale zbytek .eu vypadá mrtvě.

[Oskar]

Mě už funguje všechno. Ale ještě před hodinou nefungovalo nic...

[Honza Jaroš]

Jo, mně už taky. A RRSIG záznamy jsou pořád stejné, takže problém byl jinde. Jsem zvědavý kde, snad se to někde dočtu...

[Mrkva]

Jojo, mě už taky - docela by mě zajímalo, kdo co pohnojil..

[Jaromír Kuba]

Já měl problém s přístupností na některé domény, pokud jsem měl na resolveru povolen ITAR. Neptejte se, proč, to ani laňka neví. Teď, když je už podepsaný kořen, je všechno v pořádku, ITAR, ani DLV nepoužívám a resolver korektně zvaliduje všechno. Přístup na Vaši doménu OK.

[Shadow]

Hmm... svoje domény mám u (F) a validující DNS server doma je úspěšně validuje, včetně té tvojí. U (F) asi chyba nebude, jsou-li podpisy správné, což patrně jsou. Prudil bych (V), ať už je to kdokoliv.

[xkucf03]

Tak jsi na tom stejně jako já – na tvoje stránky se dostanu, protože používám vlastní DNS servery, ale když zkusím ty (V), tak mi na www.shadow.cz odpoví SERVFAIL stejně jako na ty moje domény.

Oni mi napsali (už při první stížnosti) tohle:

Na resolveru neni v nastaveni validace co zkazit - v BINDu 9.7, ktery pouzivame se nastavi

dnssec-enable yes; dnssec-validation yes;

a jako trust anchor se nastavi nyni jiz podepsana root zona:

managed-keys { "." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= "; };

Jedina moznost by byla implementacni chyba v BIND 9.7, coz je velmi malo pravdepodobne.

Na NIC.cz venovan cely seminar nazvany "DNSSEC smrt" (na kterem stezovatel evidentne nebyl), kde se detailne probiraly problemy vznikle nespravne provedenym rolloverem DNSSEC klicu. Korektni je nejdriv vypublikovat novy klic, podepsany starymi klici, potom podepsat vsechny zaznamy obema klici, pockat, a pak teprve ty stare klice zrusit.

Uspesne pouziti nejake validacni utility neznamena, ze je domena v poradku - pokud totiz vlivem nespravneho rolloveru zustaly v cache resolveru klice, kterymi uz aktualni zaznamy nejsou podepsany, a naopak nove, k podepisovani pouzivane klice nebyly spravne propagovany popsanym zpusobem, resolver bude korektne zaznamy odmitat.

Obratit se na NIC.cz je dobry napad, jiste je o teto problematice radi pouci.

Taky mi přijde, že na tom není co zkazit. Svůj BIND mám nastavený stejně jako oni – akorát s tím rozdílem, že mně to funguje a jim ne. A to ten BIND nemusím restartovat – u nich to funguje jen chvíli po restartu.

[Shadow]

Já doma používám Unbound, nastavené to mám de facto úplně stejně (trust anchor root zóny a povolená validace), a taky mi to bezproblémů funguje. Jak moc velký ISP je (V)?

[xkucf03]

Momentálně jim to funguje – moje doména přeložit jde, zatímco na www.rhybar.cz jejich DNS server odpoví SERVFAIL.

[xkucf03]

Přišla mi odpověď:

z nasi strane k zasahu nedoslo. Doufejme, ze bude tedy vse v poradku.

Tak tedy doufám Ještě by to chtělo někoho třeba z CZ.NIC nebo nějakého věštce, aby situaci vysvětlil.

[xkucf03]

Tak problém se objevil znovu. Tentokrát jsem na to přišel tak, že Seznam.cz mi nemohl odeslat e-mail:

# You message for <....@frantovo.cz> from 2010/12/02 could not be delivered.
# It's attached below.
# 
# Důvod / Reason:
# ---------------
# 
# 5.4.3 smtp; no valid MX record
# 
# Nepodařilo se zjistit emailový server odesílatele. 
# Permanent Failure - Routing server failure

Problém tedy nemají jen DNS servery (V), ale i Seznamu a je tedy téměř jisté, že za to může (F).

[Foo Bar]

Jinak, jak je tenhle výpis starý? Unbound měl svého času problémy, pokud byla příliš malá paměť pro cache a došlo mu v ní místo. Řešili jsme to tenkrát se Seznamem a vyřešilo se to nastavením Unboundu, aby měl k dispozici více paměti. Thread v mailing listu[en]: http://unbound.net/pipermail/unbound-users/2010-April/001149.html

[xkucf03]

Tohle bylo později: 2.12.2010.

[Daniel Ryšlink]

Nove skutecnosti:

v dnssec.log BINDa se objevuje toto (debug level 9) - kazdy dotaz vygeneruje nasledujici hlaseni:

24-Jan-2011 10:46:34.761 dnssec: debug 3: validating @0x11cff000: frantovo.cz NS: starting 24-Jan-2011 10:46:34.761 dnssec: debug 3: validating @0x11cff000: frantovo.cz NS: attempting insecurity proof 24-Jan-2011 10:46:34.761 dnssec: debug 3: validating @0x11cff000: frantovo.cz NS: checking existence of DS at 'cz' 24-Jan-2011 10:46:34.761 dnssec: debug 3: validating @0x11cff000: frantovo.cz NS: checking existence of DS at 'frantovo.cz' 24-Jan-2011 10:46:34.761 dnssec: debug 3: validating @0x11cff000: frantovo.cz NS: insecurity proof failed 24-Jan-2011 10:46:34.761 dnssec: info: validating @0x11cff000: frantovo.cz NS: got insecure response; parent indicates it should be secure

Prohledaval jsem cache na resolverech, a kupodivu tam momentalne neni k frantovo.cz ani jeden cachovany RRset (muzu Vam poskytnout cache, ale je to 300MB, prijde mi to zbytecne). Je mozne, ze by problemem byla neexistence DS zaznamu na autoritativnich nameserverech pro frantovo.cz? (Pripadne spatne podepsany DS zaznam?) Nevim, jake dalsi relevantni informace bych dal mohl shromazdit.

Autoritativni server pro cz. odpovi nasledujici:

# dig +dnssec @a.ns.nic.cz frantovo.cz ds

;; ANSWER SECTION: frantovo.cz. 18000 IN DS 36559 5 1 96D37E81EE3FCE8701855B7E9696CC9BB5BCDE6E frantovo.cz. 18000 IN RRSIG DS 10 2 18000 20110202212048 20110122200610 34702 cz. ve+gQVXIoGrF7uE3HHr4UNWkfFkr745NvK+cYu9OxBeshy/ZK9rtsH2T 5sxolTfTuqQrkyf143uT/r/Qf3KCNdx/BFRrWEbgSq5B9SF+VR41g94Q 2qkDd0ezR8cjJ5Mm8vPjBMUtRT4iWAWhqP3gzl1xpgj7HOjHBJqAWmF0 Ljg=

Ptam-li se autoritativnich serveru pro frantovo.cz, spojeni timeoutuje:

# dig +dnssec @ns.forpsi.cz frantovo.cz ds

; <<>> DiG 9.7.1-P2 <<>> +dnssec @ns.forpsi.cz frantovo.cz ds ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached

# dig +dnssec @ns.forpsi.it frantovo.cz ds

; <<>> DiG 9.7.1-P2 <<>> +dnssec @ns.forpsi.it frantovo.cz ds ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached

# dig +dnssec @ns.forpsi.net frantovo.cz ds

; <<>> DiG 9.7.1-P2 <<>> +dnssec @ns.forpsi.net frantovo.cz ds ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached

Predbezne to tedy vypada tak, ze pricinou problemu je skutecnost, ze resolver neni schopen ziskat DS zaznam z autoritativnich serveru Forpsi, ackoliv tento existuje na autoritativnich serverech pro cz. (Zaznamy v logu tomu odpovidaji).

[Foo Bar]

Dobrý den,

DS záznam se umisťuje pouze do nadřazené zóny, tj. jeho neexistence je v pořádku.

Nicméně jste tím možná uhodil hřebíček na hlavičku - ten timeout už v pořádku není, na dotaz IN DS frantovo.cz @ns.forpsi.cz by DNS server měl odpovědět NSEC záznamem. Timeout může být pravděpodobně důvod, proč selhává validace.

Zajímavé je, že ten timeout vzniká pouze v případě DS záznamů. Pro neznámé neexistující záznamy funguje NSEC v pořádku.

$ dig +multi +dnssec +norec type168 frantovo.cz @ns.forpsi.cz

; <<>> DiG 9.7.2-P3 <<>> +multi +dnssec +norec type168 frantovo.cz @ns.forpsi.cz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38568
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;frantovo.cz.		IN TYPE168

;; AUTHORITY SECTION:
frantovo.cz.		3600 IN	SOA ns.forpsi.net. admin.forpsi.net. (
				2011012201 ; serial
				3600       ; refresh (1 hour)
				1800       ; retry (30 minutes)
				2592000    ; expire (4 weeks 2 days)
				3600       ; minimum (1 hour)
				)
frantovo.cz.		3600 IN	RRSIG SOA 5 2 3600 20110221124801 (
				20110122124801 34308 frantovo.cz.
				kyQechu6Yeg3x1DdYewzNp3MMC6WNqIN+kN68+CHLX6S
				aTlox1ej0H2GItfrUKoL81d8eP5A8TwoO+zyZoDXqik1
				HSLjGoSpxLLVteD6SuCWMY2JdfgC45wRPHGsAoFud1Of
				BV3rinRiv0a4pvcFw8fdcGYAavlw47Or+MoeymY= )
frantovo.cz.		3600 IN	NSEC *.frantovo.cz. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY
frantovo.cz.		3600 IN	RRSIG NSEC 5 2 3600 20110221124801 (
				20110122124801 34308 frantovo.cz.
				NAFk+qj9+9vIs3S7iz2p1Ae2WsLRaMUj3wNqm1go9INB
				MwIpaANypOcTU0bod62BItZjoqhwlymxyyQkhq2fR5U2
				kqBjtYASM1z7wFrjc2PJEeGZIHL0e4GAN08M/I3g/q1Q
				3FvHDkN6BNdKytQ5EX/1pojSqr1uIdvsqAEMIHs= )

;; Query time: 4 msec
;; SERVER: 81.2.209.185#53(81.2.209.185)
;; WHEN: Mon Jan 24 11:33:20 2011
;; MSG SIZE  rcvd: 473

Pro DS dostávám také timeout.

$ dig +dnssec +norec DS frantovo.cz @ns.forpsi.cz

; <<>> DiG 9.7.2-P3 <<>> +dnssec +norec DS frantovo.cz @ns.forpsi.cz
;; global options: +cmd
;; connection timed out; no servers could be reached

Jako další postup bych navrhoval, aby Forpsi opravilo djbdns, aby se choval korektně i v případě DS záznamů, a uvidíme, zda-li to pomůže. Odpověď na dotaz na DS by měl vypadat například takto (tedy standardně):

$ dig +multi +dnssec +norec IN DS ubuntu.cz @tanuki.ubuntu.cz.

; <<>> DiG 9.7.2-P3 <<>> +multi +dnssec +norec IN DS ubuntu.cz @tanuki.ubuntu.cz.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46478
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;ubuntu.cz.		IN DS

;; AUTHORITY SECTION:
ubuntu.cz.		3600 IN	SOA tanuki.ubuntu.cz. hostmaster.ubuntu.cz. (
				1295607893 ; serial
				86400      ; refresh (1 day)
				7200       ; retry (2 hours)
				3600000    ; expire (5 weeks 6 days 16 hours)
				3600       ; minimum (1 hour)
				)
ubuntu.cz.		3600 IN	RRSIG SOA 5 2 3600 20110127235750 (
				20110121100453 24151 ubuntu.cz.
				gKIkr2ZiLeFgZnp4NWccMRClLgIRckop5FeuZ1Frcqsg
				cJBG3v22TgK7nlRnIMBAt39Vwz7RsRXAY/fsFl2P7s13
				raf4iAz3NMxzFxbgoYWeVbKiYaqsD182ePO3oX5ZdvnO
				+4kII5ErlfuUgC24zS+jinrNmn21GGjT+VGXhdM= )
ubuntu.cz.		3600 IN	NSEC *.ubuntu.cz. A NS SOA MX RRSIG NSEC DNSKEY
ubuntu.cz.		3600 IN	RRSIG NSEC 5 2 3600 20110128015446 (
				20110121100453 24151 ubuntu.cz.
				JGFM/opAfvi8aLUSk20mBt2Hojm5jam5f9SRcW5fYy8R
				dPMRgqFj1VdM7tFGAsh1Tc8pAuz+kZ/FUbMrpOJqK8K2
				dC9lObeicmGnIXX2D5OB4Rtt+9bz22LqZX9hql9Ssn3l
				pcsURtHv/T1s2JUgU8C7sNoyaO8P51PAVpSveQ4= )

;; Query time: 3 msec
;; SERVER: 2001:1488:d91f:cd70::cd72#53(2001:1488:d91f:cd70::cd72)
;; WHEN: Mon Jan 24 11:35:19 2011
;; MSG SIZE  rcvd: 464

Nakonec ten problém nemusí souviset úplně nutně s DNSSECem. Pokud bind dostává timeouty, tak může server dát na interní blacklist jako vadný a tato chyba se může projevit takto. (Ale to pouze spekuluju.)

[Tomáš Trnka]

Máte pravdu, nějak mi nejspíš uniklo RFC4035 3.1.4.1 (přestože mi to připadá povědomé, takže to možná implementované je, ale nějak špatně). Timeouty jsou důsledkem toho, že autoritativní server zjistí, že se ho cache ptá na záznam, který nespadá do jeho oblasti autority (protože pro to DS je autoritativní nadřazená zóna), proto si o inteligenci dané cache pomyslí něco nelichotivého a dotaz zahodí na zem jako neplatný. Výše uvedená část RFC to upravuje (že se má NSECem prokázat neexistence záznamu, i když ten vlastně existuje, jen je třeba zeptat se jinde), ale to naše DNS zjevně neví...

Prapříčinou je ale tedy zjevně nějaká drobná chyba v BINDu, která ho vede k tomu, ptát se na DS do podřízené zóny, což je z principu nesmysl (a proto s tím nejspíš u ostatních cachí není problém, protože ty prostě tento dotaz neprovedou a nenarazí na tu chybu v djbdns DNSSECu). Každopádně to opravím a pak se uvidí...

[Foo Bar]

Obecněji by to šlo zahrnout i pod sekci 3.1.3.1.

   If the zone contains RRsets matching <SNAME, SCLASS> but contains no
   RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
   include the NSEC RR for <SNAME, SCLASS> along with its associated
   RRSIG RR(s) in the Authority section of the response (see Section
   3.1.1).

Ale máte pravdu, že v sekci 3.1.4.1 jsou definované pravidla přesně pro tenhle případ:

   If all the above conditions are met, however, the name server is
   authoritative for SNAME but cannot supply the requested RRset.  In
   this case, the name server MUST return an authoritative "no data"
   response showing that the DS RRset does not exist in the child zone's
   apex.

IMHO z implementačního hlediska nevidím důvod, proč by se zrovna dotaz na DS měl zpracovávat jinak než všechny ostatní dotazy na neexistující triplety (NAME,CLASS,TYPE). Podle mě by stačilo odstranit ten 'IF' a mělo by to začít fungovat dle RFC :).

On se ten BIND může ptát na DS záznam z nějakých verifikačních důvodů. V resolverech je spousta takových kliček na zjišťování, zda-li je všechno v pořádku.

Tak snad to pomůže.

[Tomáš Trnka]

Nuže, v tuto chvíli již na všech třech uzlech běží opravené djbdns (s implementací RFC 4035 3.1.4.1), jsem zvědav, pomůže-li to něčemu.

IMHO z implementačního hlediska nevidím důvod, proč by se zrovna dotaz na DS měl zpracovávat jinak než všechny ostatní dotazy na neexistující triplety (NAME,CLASS,TYPE). Podle mě by stačilo odstranit ten 'IF' a mělo by to začít fungovat dle RFC :).

Ten důvod existuje, a je dost podstatný. Pro to DS je autoritativní nadřízená zóna, a je tedy třeba nejdřív se dívat tam (přestože normálně se autorita hledá „zdola nahoru“). Pokud byse tohle speciálně neošetřilo, vedlo by to k ostudným selháním DNSSECu, pokud je server autoritativní pro obě zóny. Jen si představte, že by třeba a.ns.nic.cz na dotaz IN DS nic.cz vrátil (podle běžných pravidel) NSEC, protože by prohledával zónu nic.cz a ne cz

[Foo Bar]

Nuže, v tuto chvíli již na všech třech uzlech běží opravené djbdns (s implementací RFC 4035 3.1.4.1), jsem zvědav, pomůže-li to něčemu.

Díky, taky jsem zvědav :).

Pokud byse tohle speciálně neošetřilo, vedlo by to k ostudným selháním DNSSECu, pokud je server autoritativní pro obě zóny.

Máte samozřejmě pravdu. Moc jsem přemýšlel v ostrých zone cutech.

[xkucf03]

Tak bohužel pořád stejný výsledek:

$ nslookup frantovo.cz 212.20.96.34
Server:         212.20.96.34
Address:        212.20.96.34#53

** server can't find frantovo.cz: SERVFAIL

$ nslookup frantovo.cz 212.20.96.38
Server:         212.20.96.38
Address:        212.20.96.38#53

** server can't find frantovo.cz: SERVFAIL

$ dig +cd +dnssec +multi IN DS frantovo.cz @212.20.96.34

; <<>> DiG 9.7.1-P2 <<>> +cd +dnssec +multi IN DS frantovo.cz @212.20.96.34
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30014
;; flags: qr rd ra ad cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;frantovo.cz.           IN DS

;; ANSWER SECTION:
frantovo.cz.            12068 IN DS 36559 5 1 (
                                96D37E81EE3FCE8701855B7E9696CC9BB5BCDE6E )
frantovo.cz.            12068 IN RRSIG DS 10 2 18000 20110212030031 (
                                20110131000605 34702 cz.
                                EA3tqcxxPXBiZc48kxbcWFfrR4LJwRkmvmWqtX2NXz5c
                                9n6aPSGOCmyOKKybUcoObqSK0J+eVsR8htWiu86hCTVJ
                                g2kmFBR+AmNJ1GVTpvksasASUctc6PxeMNBY5I5ZGdSG
                                oAuQ01xL8lOmfnplfImW304B8IirTxPmSLTZrKg= )

;; Query time: 12 msec
;; SERVER: 212.20.96.34#53(212.20.96.34)
;; WHEN: Tue Feb  1 19:29:31 2011
;; MSG SIZE  rcvd: 238

$ dig +cd +dnssec +multi IN DNSKEY frantovo.cz @212.20.96.34

; <<>> DiG 9.7.1-P2 <<>> +cd +dnssec +multi IN DNSKEY frantovo.cz @212.20.96.34
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61748
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;frantovo.cz.           IN DNSKEY

;; ANSWER SECTION:
frantovo.cz.            3600 IN DNSKEY 256 3 5 (
                                AwEAAcxttqHIHG+gDd8PVf0eW6bRV0j0FZFRDSwh71+S
                                aL+6bOLyEJ2pTxi4bmA+YGICBBBQjAQX9UB7bkPv5B15
                                sQYSKldUOCC6OajJERCJX3yvPL0i/mJr9sG4fQGIFM4R
                                k+lulcqoJCMDR6921lgkw4dBgAk9lk36srkYaaafxbqX
                                ) ; key id = 16656
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

;; Query time: 88 msec
;; SERVER: 212.20.96.34#53(212.20.96.34)
;; WHEN: Tue Feb  1 19:25:08 2011
;; MSG SIZE  rcvd: 464

$ dig CH TXT version.bind. @212.20.96.34

; <<>> DiG 9.7.1-P2 <<>> CH TXT version.bind. @212.20.96.34
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46811
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;version.bind.                  CH      TXT

;; ANSWER SECTION:
version.bind.           0       CH      TXT     "ns2.vol.cz"

;; AUTHORITY SECTION:
version.bind.           0       CH      NS      version.bind.

;; Query time: 10 msec
;; SERVER: 212.20.96.34#53(212.20.96.34)
;; WHEN: Tue Feb  1 19:25:29 2011
;; MSG SIZE  rcvd: 67

$ dig +cd +dnssec +multi IN AAAA www.frantovo.cz @212.20.96.34

; <<>> DiG 9.7.1-P2 <<>> +cd +dnssec +multi IN AAAA www.frantovo.cz @212.20.96.34
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1234
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.frantovo.cz.       IN AAAA

;; ANSWER SECTION:
www.frantovo.cz.        1800 IN CNAME frantovo.cz.
frantovo.cz.            1800 IN AAAA 2a01:430:2e::161

;; AUTHORITY SECTION:
frantovo.cz.            12015 IN NS ns.forpsi.cz.
frantovo.cz.            12015 IN NS ns.forpsi.net.
frantovo.cz.            12015 IN NS ns.forpsi.it.

;; ADDITIONAL SECTION:
ns.forpsi.cz.           325 IN A 81.2.209.185
ns.forpsi.it.           325 IN A 62.149.230.87
ns.forpsi.net.          320 IN A 81.2.194.130

;; Query time: 34 msec
;; SERVER: 212.20.96.34#53(212.20.96.34)
;; WHEN: Tue Feb  1 19:30:23 2011
;; MSG SIZE  rcvd: 211

[Foo Bar]

Tak bohužel pořád stejný výsledek:

Dal bych tomu pro jistotu čas rovný alespoň tomu, aby mohly vyexpirovat všechny relevantní záznamy v cache.

Pokud se to bude chovat stejně i dnes, tak bez dumpů provozu toho na dálku asi už moc nevykoukám.

[xkucf03]

ani dneska to není lepší

[xkucf03]

Pokud by někoho zajímal výsledek:

Dobry den,

spolu s techniky z Volny.cz jsme v minulych tydnech resili nefungujici DNSSEC domen u FORPSI, pokud sel dotaz pres ns.vol.cz kese.

Nakonec se nam podarilo odhalit pricinu problemu. Problem zpusobila smycka CNAME zaznamu zcela jine domeny, ktera nema s DNSSEC nic spolecneho, nicmeme na zaklade generovane chyby usoudi BIND (9.7.2-P3 i 9.7.3) ze cilovy NS server neumi EDNS0 rozsireni. V tom dusledku pak neni funkcni overeni DNSSEC a domeny s DNSSEC jsou invalidni, nebot BIND si uchova informaci o EDNS0 neschopnosti NS serveru po nejaky cas (flush kese to vyresi ihned).

ns.vol.cz pouzivaji BIND 9.7.2-P3

Pricina smycky byla na nasi strane odstranena. Prozatimni testy kesi BIND vraci vzdy platne DNSSEC domeny.

PS: Unbound kesovaci a validuji resolver se nechova jako BIND a DNSSEC domeny tam fungovali vzdy i kdyz doslo k vyvolani chyby se smyckou.

S přáním pěkného dne Milan Leszkow

Vypadá to dobře, překlady už několik dní fungují. Takže díky (ale že to trvalo).

[Shadow]

Tak to je dobrá zpráva, díky za info.