Zlobící DNS resolving

Software [CZ] SW chyby-diskuze [CZ]
1

Většinu problémů s občasným neresolvováním nějakých jmen jsem už před delší dobou vyřešil nastavením forwardingu dotazů na resolver CZ.NIC.

Dnes jsem ale narazil na něco, co neumím otrasovat, co se děje.

Nefunguje resolving doménového jména api.cxense.com (a dalších) a to nejen na připojených počítačích a mobilech, ale ani přímo na omnii:

root@rgh821:~# dig api.cxense.com

; <<>> DiG 9.18.24 <<>> api.cxense.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7567
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 15 (Blocked): (CR36)
;; QUESTION SECTION:
;api.cxense.com.                        IN      A

;; AUTHORITY SECTION:
api.cxense.com.         10800   IN      SOA     api.cxense.com. nobody.invalid. 1 3600 1200 604800 10800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Apr 19 11:42:30 CEST 2024
;; MSG SIZE  rcvd: 103

Přitom přímý dotaz na veřejný sever CZ.NIC funguje.

root@rgh821:~# dig @odvr.nic.cz api.cxense.com

; <<>> DiG 9.18.24 <<>> @odvr.nic.cz api.cxense.com
; (4 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45215
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;api.cxense.com.                        IN      A

;; ANSWER SECTION:
api.cxense.com.         54      IN      A       167.235.124.25

;; Query time: 0 msec
;; SERVER: 193.17.47.1#53(odvr.nic.cz) (UDP)
;; WHEN: Fri Apr 19 11:44:18 CEST 2024
;; MSG SIZE  rcvd: 59

Kupodivu nepomůže ani to, když v konfiguraci omnie změním forwarding na jiný server ani když zakážu forwarding úplně.

Nevím, jestli to nějak nesouvisí s tím, že při aktualizaci na TOS 7 se mi na některých omniích zrušil forwarding s chybovou hláškou:

Oznámení o chybách
==================
DNS servery vašeho poskytovatele internetu nefungují úplně dobře - pravděpodobně nepodporují DNSSEC. Bylo proto vypnuto forwardování a váš router bude nyní vyhodnocovat DNS dotazy sám.

Přitom všude byl nastavený forwarding na resolvery CZ.NIC, tak té hlášce moc nerozumím. Na té omnii, kterou teď řeším, žádná taková chyba není. Na jiných omniích s TOIS 7 resolving tohoto doménového jména funguje.

Vůbec tomu nerozumím, co se vlastně děje. Dá se to nějak poladit?

Jako kdyby byl v TOS 7 nějaký problém s resolvingem?

Edit: restart omnie nepomůže.

2

Když zapnu debug, tak v logu je jen:

Apr 19 10:31:45 rgh821 kresd[19119]: [plan  ][00000.00] plan 'api.cxense.com.' type 'A' uid [10875.00]
Apr 19 10:31:45 rgh821 kresd[19119]: [policy][10875.00]   DENY applied for api.cxense.com. A
Apr 19 10:31:45 rgh821 kresd[19119]: [resolv][10875.00]   finished in state: 4, queries: 1, mempool: 16392 B

Co to může znamenat?

Na jiné omnii je to OK:

Apr 19 10:38:49 mnichov81 kresd[4785]: [plan  ][00000.00] plan 'api.cxense.com.' type 'A' uid [06989.00]
Apr 19 10:38:49 mnichov81 kresd[4785]: [iterat][06989.00]   'api.cxense.com.' type 'A' new uid was assigned .01, parent uid .00
Apr 19 10:38:49 mnichov81 kresd[4785]: [cache ][06989.01]   => skipping exact RR: rank 030 (min. 030), new TTL -853
Apr 19 10:38:49 mnichov81 kresd[4785]: [cache ][06989.01]   => no NSEC* cached for zone: cxense.com.
Apr 19 10:38:49 mnichov81 kresd[4785]: [cache ][06989.01]   => skipping zone: cxense.com., NSEC, hash 0;new TTL -123456789, ret -2
Apr 19 10:38:49 mnichov81 kresd[4785]: [cache ][06989.01]   => skipping zone: cxense.com., NSEC, hash 0;new TTL -123456789, ret -2
Apr 19 10:38:49 mnichov81 kresd[4785]: [plan  ][06989.01]   plan '.' type 'DNSKEY' uid [06989.02]
Apr 19 10:38:49 mnichov81 kresd[4785]: [iterat][06989.02]     '.' type 'DNSKEY' new uid was assigned .03, parent uid .01
Apr 19 10:38:49 mnichov81 kresd[4785]: [cache ][06989.03]     => satisfied by exact RRset: rank 060, new TTL 69987
Apr 19 10:38:49 mnichov81 kresd[4785]: [iterat][06989.03]     <= answer received:

atd.

3

Zablokováno nějakými nakonfigurovanými policy, zřejmě.

; EDE: 15 (Blocked): (CR36)

Apr 19 10:31:45 rgh821 kresd[19119]: [policy][10875.00]   DENY applied for api.cxense.com. A
4

Tohle jméno bych tipoval na pokus o blokování reklam.

5

No to bych tipoval také, kde ale zjistím jak to přesně je? Obě Omnie jsou nakonfigurovány úplně stejně, na obou je aktivní AdBlock ve výchozím nastavení a přesto jedna to blokuje a druhá ne. To je jméno serveru, který používá třeba idnes při kliknutí na odkaz na článek.

Zajímavé je, že na té problémové omnii je soubor /etc/kresd/adb_list.overall velký 3,7 MB a obsahuje skutečně i řádky

cxense.com CNAME .
*.cxense.com CNAME .

tak tensto soubor na neproblémové omnii má pouze hlavičku a jinak je prázdný.

Když dám ale “Znovu načíst” blokované domény, tak se na té neproblémové načtou a už je také problémová. Je divné, že před tím “Znovu načíst” byl ten seznam prázdný. Nastavení Adblocku je na obou omniích stejné.

V každém případě je vidět, že AdBlock blokuje něco, co by neměl, a nejjednodušší řešení je ho vypnout.

6

No upřímně, záležitosti okolo blokování reklam neřeším a tedy skoro neznám.

A tohle je spíše o zdroji dat než o adblocku samotném (dají se volit) a o přetahované s weby které z reklamy žijí.

7

Jasně, díky za nasměrování.

8

Pokud je něco blokované AdBlock, najdeš to v logu a můžeše tO whitelistovat. Stejně si zkontroluješ, že to v blacklistu vůbec je.

image
image789×745 118 KB

9

Problém s AdBlockem jsem vyřešil tím, že jsem ho úplně vypnul.

Jenže pořád jsou adresy, které Omnia nepřeloží a je to ještě divnější, než před tím. Třeba doménové jméno www.rezervujstul.cz při zapnutém přeposílání na CZ.NIC se nepřeloží s chybou SERVFAIL:

; <<>> DiG 9.18.24 <<>> www.rezervujstul.cz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36203
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 6 (DNSSEC Bogus): (I74V)
;; QUESTION SECTION:
;www.rezervujstul.cz.           IN      A

;; Query time: 30 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu May 09 13:43:17 CEST 2024
;; MSG SIZE  rcvd: 58

Pokud ale navolím kterýkoliv jiný resolver (Google, Cloudflare, Quad9, poskytovatele připojení), tak se doménové jméno na IP adresu přeloží.

A rovněž když udělám dotaz přímo na ten server CZ.NICu, tak se přeloží také.

; <<>> DiG 9.18.24 <<>> @odvr.nic.cz www.rezervujstul.cz
; (4 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25521
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.rezervujstul.cz.           IN      A

;; ANSWER SECTION:
www.rezervujstul.cz.    3600    IN      A       185.59.210.141

;; Query time: 10 msec
;; SERVER: 193.17.47.1#53(odvr.nic.cz) (UDP)
;; WHEN: Thu May 09 13:44:40 CEST 2024
;; MSG SIZE  rcvd: 64

Čím to může být?

Teď to vyřeším tak, že změním přeposílání z CZ.NIC na Google, ale je mi divné, že resolver a Omnia spolu nějak nespolupracují, i když jsou oboje od CZ.NIC.

10

Chyby se dějí. Podařilo se mi to zreprodukovat, zkoumám co se tam děje.

Forwardování z Turrisu na Google nedoporučuji – to je příklad nevýhody, kdy nekontrolujeme ten server a oni nejsou motivováni opravovat chyby důležité pro nás (spousty jmen jsou tím rozbité, myslím): https://issuetracker.google.com/issues/299255571

1 Like
11

Děkujeme. Otevřel jsem issue u nás: downgrades due to NSEC3 limits interact badly with wildcards (and validating the resolver answer) (#910) · Issues · Knot projects / Knot Resolver · GitLab

Problém se projevuje na serverové straně, takže – jak jste zjistil – se mu vyhnete, pokud se vyhnete forwardování (s validací) na Knot Resolver (tady konkrétně cz.nic ODVR).

12

Děkuji, jaké je tedy doporučené nastavení? Přeposílání úplně vypnout? Je fakt, že za uplynulé roky s Omnií jsem to nastavení několikrát měnil, vždy, když se některé jména nechtěla přeložit, jednou nefungoval dobře Google, podruhé Cloudflare… skončil jsem u CZ.NICu, ale i tam je teď problém. DNS servery podkytovatele jsou řekl bych obecně dost rizikové, takže asi to nechat řešit přímo Omnii, že?

13

Vypnutí přeposílání je nejpřirozenější mód, obecně nejméně náchylný na problémy – alespoň pokud třeba ISP nemá tendenci do toho nešifrovaného provozu zasahovat, apod.