Resolvery CZ.NIC nepřekládají weby Monety?

[McFly]

Čau, taky vám otevřené validující DNSSEC resolvery CZ.NICu nepřekládají weby Monety?


https://www.novinky.cz/clanek/internet-a-pc-internetove-bankovnictvi-moneta-banky-zkolabovalo-nefunguje-uz-druhy-den-40552484

Kód [Vybrat] Rozbalit

# nslookup moneta.cz 193.17.47.1
Server:         193.17.47.1
Address:        193.17.47.1#53

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

# nslookup moneta.cz 185.43.135.1
Server:         185.43.135.1
Address:        185.43.135.1#53

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

DNS ISP OK. Google DNS OK.

Chyba v CZ.NICu?

[Reklama]

[Petr Krčmář]

Chyba je na straně autoritativních serverů. Zdá se, že vracejí A záznam a rovnou k němu informaci v NSEC3, že takový záznam neexistuje. Tipoval bych na nějakou kreativitu na straně F5, který jim dělá autoritativní servery.

[Michal Šmucr]

Chyba je na straně autoritativních serverů. Zdá se, že vracejí A záznam a rovnou k němu informaci v NSEC3, že takový záznam neexistuje. Tipoval bych na nějakou kreativitu na straně F5, který jim dělá autoritativní servery.

Teď jsem na to samé koukal na DNSViz

https://dnsviz.net/d/moneta.cz/dnssec/?rr=all&a=all&ds=all&doe=on&ta=.&tk=

Tam to tu chybu popisuje tak, že nesedí RR bitmapa s těmi záznamy.
Jen to vypadá, že DNS od NIC.CZ je na to citlivější, protože třeba Quad9 nebo Cloudflare to v pohodě vrací.. možná tohle ignorují.

U DNS4EU je to trochu zvláštní. U výchozí, protected: 86.54.11.1 se to chová stejně jako u NIC.CZ, ale ta uprotected 86.54.11.100 ten záznam vrací, přičemž by obě varianty měly používat DNSSEC.

Zajímavé, zatím jsem se podobnou věcí nesetkal.

[vcunat]

No, dotazy na neexistující typy (třeba AAAA) ty autoritativní servery vrací s DNSSEC důkazy, které tvrdí například že ani A záznam neexistuje.  Takže podle toho, co je zrovna v cachi první, to vyhraje (vizte RFC 8198).  Jak odvr.nic.cz tak DNS4EU se v tomto chovají stejně, protože je to prostě obojí Knot Resolver.

Samozřejmě pozor na "routování", tedy že různé dotazy mohou skončit na různých cachích, atd.  (napovědět může +nsid parametr pro (k)dig)

[Aleš Rygl]

Nakonec DNSSEC vypnuli, odstranili DS z .cz zony. Tak to snad brzo daji dohromady.

[Reklama]

[a12]

tak proto dnes obesilali ISP s zadosti o reset cache dnsresolveru...

[vcunat]

Obesílali?  Hmm, na pohled vidím všechny TTL 1 hodinu nebo méně (včetně moneta.cz DS).  Ale možná to nějaký smysl mělo.  Spíš z principu je takové obesílání slabá záplata, pomůže jen části uživatelů.

EDIT: aha, to byla jistě ta "součinnost operátorů" v článku na Novinkách.

[Aleš Rygl]

Ano, mel jsem s tim take co docineni. Byla tu snaha zachranit situaci, ale seslo tam vic problemu, jak tu uz nekdo zminil ten NSEC3 a proto to pomohlo jen trochu.

Ale DS jeste zpet neni, jak se divam.

[Michal Šmucr]

@vcunat

Díky za odpověd a nasměrování k RFC 8198. Překvapily mě ty rozdíly v odpovědích i mezi validujícími resolvery, tohle to pěkně vysvětluje.

[vcunat]

DS zpět dát zatím jistě nechtějí, protože ty rozbité NSEC3 jim to pořád vrací.

[McFly]

Mezi námi děvčaty, v síti mého domácího ISP to stále nefunguje. Přesněji - jeden jeho NS překládá, druhý ne. Nebudu to řešit...

[ByCzech]

tak proto dnes obesilali ISP s zadosti o reset cache dnsresolveru...

Nedivím se, kreativita některých ISP ohledně cachování i mnoho dnů starých záznamů není ojedinělá věc (vůbec nejlepší je, když na jednom DNS mají záznamy updatované a na backupech dny staré - miluju).

[ByCzech]

Mezi námi děvčaty, v síti mého domácího ISP to stále nefunguje. Přesněji - jeden jeho NS překládá, druhý ne. Nebudu to řešit...

LOL, ted jsem o tom psal.