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

[včera 18:51 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.

[včera 21:12 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.

[dnes 13:38 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.

[dnes 14:43 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.

[dnes 16:39 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.

[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