Dotaz: Unbound problém s DNS servery ČEZu

[xxl]

Narazil jsem na problém, že Unbound nedokáže zjistit potřebné údaje z DNS serverů ČEZu. Především MX.

Dokáže to právě jednou - po startu stroje. Potom to má nějakou dobu v keši, ale poté, co uplyne TTL, už znovu údaje nezjistí. Restart unboudu nepomůže.

Vypadá to, že je tam problém v komunikaci. Unbound posílá dotazy, ale ČEZ je ignoruje.

Bind ani knot-resolver tyto problémy nemají, mají jinak formulované dotazy. Dig přímo na jejich nameservery funguje, pokládá dotazy také jinak, než unbound.

Přišel jsem na to v unbound verzi 1.22, pak jsem nainstaloval 1.23-1 a skončil jsem u verze z gitu. A vyzkoušel jsem i verzi 1.17. Nefunguje ani jedna.

Ale ono to dřív úplně bez problémů fungovalo. Normálně s nimi komunikujeme, proto se taky na to přišlo, když to fungovat přestalo.

Dokáže někdo, kdo se v tom vyzná, říct, proč to nefunguje?

---

---

Odpovědi

[X]

Ten rozdil v dotazech je jaky?

[xxl]

To nedokážu přesně popsat, protože to už je na mě už poněkud složité. Ale když se ptám 'dig cez.cz. mx +dnssec' a poslouchám tu komunikaci, která probíhá se servery ČEZu, tak unbound pošle dotaz po udp na mx a okamžitě vzápětí pošle také dotaz na dnssec. Hned se také ptá druhého nameserveru. Dostane po udp nějakou odpověď a pak se ptá po tcp, ale na ten dotaz už odpověď nepřijde. Opakuje dotazy, zkouší další nameservery, po ipv4 po ipv6, ale odpovědi nechodí.

Když pustím knot-resolver a položím mu stejný dotaz, tak ta komunikace se servery ČEZu je trochu jiná. knot zvolí jeden se z nameserverů a vyřídí s ním veškerou komunikaci. A ten sled paketů je prostě jiný.

Když položím dotaz digem přímo nameserveru ČEZu, tak se ta komunikace podobá té, co dělá knot.

Ale znamená to, že se nejedná o žádnou ip blokaci nebo něco takového, ale spíš to, že ty jejich servery nemají rády agresivní způsob validace, kterou provádí unbound.

[X]

Celou tu komunikaci bych odchytil tcpdumpem do pcap souboru a rozebral ve Wiresharku. Tam buede prehledne videt vsechno co se deje.

[xxl]

No však to jsem udělal. Ale nezmoudřel jsem z toho. Prostě to nefunguje. Můžeš si to jednoduše vyzkoušet. Nahoď si unbound na 127.0.0.1, dej si to do do resolv.conf a pusť si 'watch dig cez.cz. mx'. A běž si udělat kafe. Po 5 nebo 10 minutách to přestane fungovat.

[otrok]

Muzeme k tobe vyslat tym 50 lidi, aby to vyresili, abys nemusel hnout prstem? Dekujeme moc (muzou privezt i hodnotne dary)

[xxl]

Aspoň sis to vyzkoušel? Nevyzkoušel. A evidentně tomu ani nerozumíš.

Já to vyřešit umím. Ale chci vědět, proč to nefunguje.

[otrok]

Vydrz, uz jsem to otestoval na prvnich trech linuxovych distribucich. Jedu dal jak fretka.

[xxl]

Kecáš.

Jinak bys už musel přijít na to, že například na Debianu Trixie to nefunguje.

[otrok]

Fakt si myslis, ze si nekdo bude neco instalovat a odchytavat, aby uhodl tvoje prostredi, kdyz ty nejsi ochotny sem dat neco, co uz mas?

[xxl]

Evidentně tady jenom frajeříš, protože kdybys někde unbound používal, tak by tě mohlo zajímat, jestli nemůžeš mít problém i ty a stačilo by ti ověřit na tvé instalaci, že TOBĚ to funguje. Ale tebe to patrně nezajímá.

--

Čistá instalace Debianu Trixie s veřejnými ipv4/6 adresami, bez firewallu, se spuštěným unboundem na 127.0.0.1. resolv.conf nastavený na 127.0.0.1. 'dig cez.cz. mx +dnssec; unbound-control reload; dig cez.cz. mx +dnssec'. A máš to, vytimeoutuje se to. Ale ani ten unbound nemusíš pouštět, stačí mít nainstalovaný unbound-host a ověřit si to tím - 'unbound-host -vddD -t mx cez.cz.'. Akorát to bude dýl trvat. Zato uvidíš, jak ty servery ČEZu neodpovídají. A upozorňuji, že poprvé po spuštění mašiny to funguje. Pak už ne.

Čistá instalace Debianu Trixie s ipv4 adresou za dvěma NATy, atd. Chová se to úplně stejně.

Kdybys chtěl vědět, co je tam za kernel, tak 6.12.41. A unbound je 1.22.

Kromě toho jsem to zkoušel na různých jiných Debianech, s různými kombinacemi kernelu a unboundu. Taky jsem zkoušel unbound 1.17, 1.23, z posledního gitu...

Nikde to nefunguje. Nicméně to dřív na těch různých kombinacích debianu fungovalo, protože kdyby to nefungovalo, tak by se na to přišlo běžným používáním, jako se na to přišlo teďka.

Akorát jsem zjistil, že na Debianu Bullseye, nějaká zkušební zapomenutá instalace, kernel 6.0.12 a unbound 1.13, to funguje.

[Peter Golis]

... stačí mít nainstalovaný unbound-host a ověřit si to tím ... Zato uvidíš, jak ty servery ČEZu neodpovídají ...

Nechcem sa ti zbytočne pliesť do života, ale ty si naozaj myslíš že namotáš niekoho aby si sám u seba nasimuloval prostredie ktoré je podobné tvojmu, a získal tak aspoň približné logy ktoré ty nechceš poskytnúť na riešenie tvojho problému?

[xxl]

Příloha:

• unbound_problem_info.tar.gz (16335 bytů)

Tady máš to, co vrací unbound-host.

[X]

Nemam to ted jak otestovat. Jaky je rozdil, kdyz to porovnas na urovni paketu s funkcni situaci?

[MMMMMMMMM]

Mám starší server s unbound-1.6.6-5.el7_8.x86_64, překlad MX u ČEZu funguje bez problému.

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.16 <<>> cez.cz. mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49506
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cez.cz.                                IN      MX

;; ANSWER SECTION:
cez.cz.                 125     IN      MX      10 smtp12.cez.cz.
cez.cz.                 125     IN      MX      10 smtp22.cez.cz.
cez.cz.                 125     IN      MX      10 smtp21.cez.cz.
cez.cz.                 125     IN      MX      10 smtp11.cez.cz.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: So srp 16 19:27:59 CEST 2025
;; MSG SIZE  rcvd: 127

[xxl]

Díky. Tuhle verzi nainstalovat nemůžu.

Ale mám ověřeno, že čistá instalace Debianu Bullseye funguje, zatímco čistá instalace Bookworm a Trixie blbne. Unbound v těch Debianech je 1.13.1, 1.17.1 a 1.22.0. Chodí tedy jenom ta 1.13.1.

Ona ale chodila i ta verze 1.22. Ještě 18.7.2025 to fungovalo. A první problém jsem zaznamenal až 22.7.2025. Mezitím nevím.

Podle mě se něco změnilo na serverech ČEZu a kupodivu to rozbilo ty novější verze unboundu.

[X]

Kdyz se podivam na ty logy vidim:

validation failure cez.cz. MX IN: No DNSKEY record [all servers for this domain failed, at zone cez.cz. from 2a01:a040:2004:8100::1 upstream server timeout] for key cez.cz. while building chain of trust

Host cez.cz. not found: 2(SERVFAIL). (error)

Hadam, nejaka blokace. Taky to muze byt uplne mimo ten server.. Dokzes to overit?

[xxl]

Když se ptá unbound (nebo unbound-host), tak nepřicházejí odpovědi na tcp dotazy. Ale když se vzápětí zeptám digem přímo serveru ČEZu, tak tu odpověď dostanu. A komunikace jde také (i) po tcp. Takže v těch dotazech je prostě nějaký rozdíl, kvůli kterému ty servery neodpovídají.

[xxl]

Teď jsem v Debianu Trixie/Unstable downgradnul unbound na verzi 1.13 z Bullseye. A okamžitě to začalo fungovat.

[Xerces]

Mám sid, ale moc to nerestartuju, takže mi asi běžela starší verze unbound, kterou mám nakonfigurovanou jako rekurzivní cache. Normálně mi to www.cez.cz načetlo. Když jsem udělal restart, tak nic, vše ostatní ok. Takže té novější (1.22) verzi asi nechutná nějaké nastavení cez.cz. Ale skoro bych řekl, že by bylo lepší, kdyby se koukli na nastavení DNS na cez.cz, než zkoumat který patch to v unbound zaříznul.

[lertimir]

No tohle vypadá na chyby v DNSSEC. A starý unbound ověřování DNSSEC nedělá.

[xxl]

I ta verze 1.13 dělá ověření DNSSEC. Aspoň to tvrdí.

root@debian-bullseye:~# unbound-host -vDt mx cez.cz.
cez.cz. mail is handled by 10 smtp21.cez.cz. (secure)
cez.cz. mail is handled by 10 smtp12.cez.cz. (secure)
cez.cz. mail is handled by 10 smtp22.cez.cz. (secure)
cez.cz. mail is handled by 10 smtp11.cez.cz. (secure)
root@debian-bullseye:~# unbound-host -vDt mx nic.cz.
nic.cz. mail is handled by 10 mail.nic.cz. (secure)
nic.cz. mail is handled by 20 mx.nic.cz. (secure)

[lertimir]

SOA záznam má adresu na správce DNS tak zdokumentovat a poslat.

[xxl]

Ale nefunguje.

netmaster@cez.cz: host smtp21.cez.cz[89.111.73.164] said: 550 #5.1.0 Address
    rejected. (in reply to RCPT TO command)

[lertimir]

OK tak cez na to asi dost prdí. Tak se rozmysli co vlastně chceš. Když chceš ohnout unbound tak základní radu jsi už dostal. Odchytit tcpdumpem pro starou funkční i novou nefunkční verzi. Vyfiltrovat na DNS packety a porovnat, jak se ptá stará verze a co dostane, a jak se ptá nová a co dostane. popřípadě to postnout sem. Pokud se chceš bavit s IT čezu o DNS a proč to tak je: Na whois je nějaký kontakt s emailem. Zkus ten.

[xxl]

Ten kontakt z whois a postmastra jsem zkusil taky. Neobtěžovali se ani odpovědět. Signály o tom, že to mají nějak blbě, dostali.

[xxl]

Porovnat to, jak se ptá stará a nová verze nebo jak odpovídá dns server, to je věc pro vývojáře. Protože tam je taková spousta možností, kde se to může lišit a přesto to být správně, že jako uživatel nemám vůbec šanci přijít na to, co je blbě.

Já vidím, že jedna verze unboundu dostává od serverů ČEZu odpovědi a druhá je nedostává, protože si nějak nerozumějí. Nejspíš jedna strana nedodržuje nějaké standardy, přičemž bych se vsadil, že to je ČEZ. A dál vidím, bind a knot-resolver s tím nemají problém.

Jo a vývojáři jsem taky napsal.

[lertimir]

No pokud nejsi ochoten se podívat fakticky na to, jak se ty verze ptají, tak asi není o čem se bavit. Měl jsi to hned na první reakci. Pak má smysl řešit proč a jak to změnit.

[xxl]

No pokud nejsi ochoten se podívat fakticky na to, jak se ty verze ptají, tak asi není o čem se bavit.

Promiň, ale já se fakt nevyznám ve všem.

A jenom se zeptám, používáš unbound? A víš přesně jak má nebo může vypadat komunikace s DNS serverem? Já to nevím, ale vidím, že to nefunguje. Buď za to může unbound nebo za to může ČEZ. A to je to, co v tuto chvíli nevím.

[lertimir]

A víš přesně jak má nebo může vypadat komunikace s DNS serverem?

No vím, ale i když bych nevěděl, jsem schopen najít. Za 3 minuty dotazů do googlu jsem našel zde. Navíc dostal jsi doporučení na wireshark. Ten ti paket zanalyzuje a popíše jaký dotaz nebo odpověď, co tam přímo obě strany pošlou. Ty jen chceš, aby ti tu analýzu, co je špatně někdo udělal. Používám ho často když na siti něco nefunguje. Bez analýzy paketů to prostě nejde. když si nerozumí, někdo musí se zahloubit do dialog, A odešle, B odpoví, A zareaguje. Načíst kdo se odchylí od protokolu. Alespoň sem ty záchyty poslat at ti to někdo vysvětli.

[xxl]

OK. Jsi lepší.

Fakt se nehodlám učit RFC vztahující se ke komunikaci DNS serverů.

Já za ten problém nemůžu. Podle mě za něj může ČEZ, protože, jak už jsem psal, s verzí unboudu 1.22 to nejprve fungovalo a poté to fungovat přestalo.

[X]

Skoda,ze jsi to vzdal.

[xxl]

http://www.dnsflagday.net/2020/

https://ednscomp.isc.org/ednscomp/b47c041886

[X]

Zeptam se blbe, ale proc to cele vlastne resis? K cemu diagnostikujeme DNS nejake "cizi" soukrome firmy?

[xxl]

Protože nám pro tu cizí soukromou firmu zůstávaly viset maily na poštovním serveru a korespondenti si stěžovali, že jim to nechodí.

Také jsem následně zjistil, že se nedostanu do svého účtu na jejich webu, protože doma také resolvuji unboundem. Jsem totiž jejich zákazníkem, jako milióny dalších.

[Peter Golis]

A keď to zinvestiguješ, a vydokladuješ kde majú chybu, tak im ten výsledok ako doručíš?

Spomínal si že email nečítajú. Plánuješ im zaslať kolkovanú žiadosť?

[X]

Od oka staci:

tcpdump -i tvuj_inteface -n -p -s0 -w cez_bad.pcap port 53 

Ukladani prerusis a pustis znova pro cez_ok.pcap.

Vylezou dva soubry, ktere otevres ve Wiresharku a muzes snadno a detailne videt co se presne stalo.

Kdys sem soubory posles tak ti nekdo poradi.

[Heron]

Neprdí.

[marek]

Dobry den

https://dnsviz.net/d/cez.cz/dnssec/ hlasi tolik chyb a varovani, ze bych se na jakoukoli cache, ktera to odmitne odpovedet, nehneval:

cez.cz/AAAA has errors; select the "Denial of existence" DNSSEC option to see them.
cez.cz/CDS has errors; select the "Denial of existence" DNSSEC option to see them.
cez.cz/CNAME has errors; select the "Denial of existence" DNSSEC option to see them.
cez.cz/CDNSKEY has errors; select the "Denial of existence" DNSSEC option to see them.
2amnh.1bxz3.cez.cz/A has errors; select the "Denial of existence" DNSSEC option to see them.
Warnings (63)
RRSIG cez.cz/A alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/A alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/A alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/A alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/A alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/A alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/DNSKEY alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/DNSKEY alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/DNSKEY alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/DNSKEY alg 10, id 35439: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/DNSKEY alg 10, id 35439: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/DNSKEY alg 10, id 35439: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/DNSKEY alg 10, id 35439: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/DNSKEY alg 10, id 35439: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/DNSKEY alg 10, id 35439: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/DNSKEY alg 10, id 35439: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/DNSKEY alg 10, id 35439: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/DNSKEY alg 10, id 35439: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/DNSKEY alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/DNSKEY alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/DNSKEY alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/MX alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/MX alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/MX alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/MX alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/MX alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/NS alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/NS alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/NS alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/NS alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/NS alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/NSEC3PARAM alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/NSEC3PARAM alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/NSEC3PARAM alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/NSEC3PARAM alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/NSEC3PARAM alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/NSEC3PARAM alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/NSEC3PARAM alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/NSEC3PARAM alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/SOA alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/SOA alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/SOA alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/SOA alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/SOA alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/SOA alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/SOA alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/SOA alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/SOA alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/SOA alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/SOA alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/SOA alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/TXT alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/TXT alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/TXT alg 10, id 25490: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/TXT alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/TXT alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
RRSIG cez.cz/TXT alg 10, id 48902: DNSSEC implementers are recommended against implementing signing with DNSSEC algorithm 10 (RSASHA512). See RFC 8624, Sec. 3.1.
cez.cz/CDS has warnings; select the "Denial of existence" DNSSEC option to see them.
2amnh.1bxz3.cez.cz/A has warnings; select the "Denial of existence" DNSSEC option to see them.
cez.cz/AAAA has warnings; select the "Denial of existence" DNSSEC option to see them.
cez.cz/CNAME has warnings; select the "Denial of existence" DNSSEC option to see them.
cez.cz/DNSKEY has warnings; select the "Denial of existence" DNSSEC option to see them.
cez.cz/CDNSKEY has warnings; select the "Denial of existence" DNSSEC option to see them.

marek

[Heron]

Tohle nejsou žádné chyby ale warningy a vše se točí kolem velikosti šifrování, což ČEZ nijak ovlivnit nemůže, protože má své klíče u nadřízené organizace.

[marek]

Ano, vsechny "chyby" a warningy souvisi s algoritmem 10, nemelo by to byt smrtelne(ale velikost odpovedi, obzvlaste kdyz jsou tam zrovna dva klice, muze hrat roli).

Nemyslim, ze je pravdepodobne, ze by ksk daval do cznic nekdo jiny, nez cez.

marek

[Heron]

Melo by na stroji s Unboundem stacit vypnout tcp fastopen: sysctl -w net.ipv4.tcp_fastopen=0

[xxl]

Super!! Opravdu to funguje.

Díky.

Akorát že default hodnota je 1 a jsem si jist, že to s ní dřív chodilo. Takže to na dns serverech ČEZu museli změnit na 0.

[alkoholik]

Smutne.
RFC 9210 4.1:
TCP Fast Open (TFO) [RFC7413] allows TCP clients to shorten the handshake for subsequent connections to the same server. TFO saves one round-trip time in the connection setup. DNS servers SHOULD enable TFO when possible.

[Petr]

Měl jsem stejný problém, nakonec jsem to vyřešil přidáním volby do konfigurace unbound

edns-buffer-size: 4096