Knot kresd cannot resolve address 'b root-servers.net'

[martinus26]

Mam doma na rpi400 pusteny Knot resolver 1.10 na Ubuntu 20.04. Po polroku bezproblemovej prevadzky sa dnes v noci nieco pokazilo

Na niektore weby sa dostanem, na niektore nie weby sa nedostanem
 Rpi400 slisi ako router/firewall a pakety na  53 a 853 presmerovavam na moj Knot resolver von cez dns over tls.

Systemctl status kresd1.service

Kód: [Vybrat]

kresd[3258]: [primin] cannot resolve address 'b.root-servers.net.', type: 1

kresd[3258]: [primin] cannot resolve address 'b.root-servers.net.', type: 28

kresd[3258]: [primin] cannot resolve address 'c.root-servers.net.', type: 28

kresd[3258]: [primin] cannot resolve address 'e.root-servers.net.', type: 1

kresd[3258]: [primin] cannot resolve address 'f.root-servers.net.', type: 1

kresd[3258]: [primin] cannot resolve address 'g.root-servers.net.', type: 1

kresd[3258]: [primin] cannot resolve address 'g.root-servers.net.', type: 28

kresd[3258]: [primin] cannot resolve address 'h.root-servers.net.', type: 1

kresd[3258]: [primin] cannot resolve address 'l.root-servers.net.', type: 28

kresd[3258]: [primin] cannot resolve address 'm.root-servers.net.', type: 28

Neviem niekto poradit ako to opravit ? Dakujem

[Reklama]

[martinus26]

este som si vsimol v szslogu dalsiu chybu

Kód: [Vybrat]

kresd[2371]: [tls_cl] failed to verify peer certificate: The certificate is NOT trusted. The name in the certificate does not match the expected.
skusal som update ca-certifikatov

apt-get update
apt-get install ca-certificates
update-ca-certificates --fresh --verbose
openssl rehash -v
reboot

ale knot stale nefunguje.

[vcunat]

Prosím, nepoužívejte takto starou verzi.  Už je řadu let nepodporovaná.  Naše balíky mají poslední verzi (teď 5.5.1) i pro stabilní distra jako Ubuntu 20.04.  https://www.knot-resolver.cz/download/

[martinus26]

System na rpi nebol 2 mesiace aktualizovany.

Ja knot resolver som predtym stahoval z stahujem z repozitaru https://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolver-latest/xUbuntu_20.04/

Najskor som skusil aktualitovat len knot-resolver a knot-resolver-release a systemctl restartol, ale nepomohlo (ani po rebooote).

Ked som potom aktualizoval cely system, tak dns zacalo fungovat.

V systeme teraz mam 2 baliky knot-resolver (5.5.1-cznic.1)  a knot-resolver-release (1.10-1)

Aky je rozdiel medzi knot-resolver a knot-resolve-release ? 

[vcunat]

Ah, pardon, tak to bylo zmatení verzí.  Zapomněl jsem na ten pomocný balík knot-resolver-release.  5.5.1 je v současnosti poslední vydaná verze.

Takže, ty [primin] řádky nejsou zajímavé samy o sobě.  V tomto případě zřejmě jen druhotným důsledkem toho, že je konfigurace nefunkční a tedy ani tyto dotazy nejde resolvnout.  Obecně tyhle řádky lidi matou, už před pár týdny jsme je z default logovací úrovně vyřadili, bude to ve všech následujících releasech: https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1310

[tls_cl] řádka vypadá na ten skutečný důvod.  Zřejmě máte TLS_FORWARD kde nakonfigurované jméno služby neodpovídá jménu certifikátu který ta služba pošle.  Tam aktualizace ca-certificates nemůže pomoct, protože nesedí jméno.  Takže... prostě nastavte správné jméno, za předpokladu že mu stále věříte, apod.

[Reklama]

[martinus26]

Zřejmě máte TLS_FORWARD kde nakonfigurované jméno služby neodpovídá jménu certifikátu který ta služba pošle.  Tam aktualizace ca-certificates nemůže pomoct, protože nesedí jméno.  Takže... prostě nastavte správné jméno, za předpokladu že mu stále věříte, apod.

Kde/ako (v ktorom konfigu) mám správne nastaviť to meno ?

Ja mám k /etc/knot-resolver/kresd.conf nasledujuce nastavenie TLS

Kód: [Vybrat]

policy.add(policy.all(policy.TLS_FORWARD({
  {'9.9.9.9', hostname='dns.quad9.net', ca_file='/etc/ssl/certs/ca-certificates.crt'},
  {'149.112.112.112', hostname='dns.quad9.net', ca_file='/etc/ssl/certs/ca-certificates.crt'},
  {'194.36.144.87', hostname='ns29.de.dns.opennic.glue', ca_file='/etc/ssl/certs/ca-certificates.crt'}
})))


Tiez som si všimol ze sa Knot obsac sam od seba restartne, , vypis z /var/log/syslog

Kód: [Vybrat]

Aug  1 09:34:37 rpi400 kresd[2312]: [tls_cl] failed to verify peer certificate: The certificate is NOT trusted. The name in the certificate does not match the expected.
Aug  1 09:37:22 rpi400 kresd[2312]: double free or corruption (!prev)
Aug  1 09:37:23 rpi400 systemd[1]: kresd@1.service: Main process exited, code=dumped, status=6/ABRT
Aug  1 09:37:23 rpi400 systemd[1]: kresd@1.service: Failed with result 'core-dump'.
Aug  1 09:37:23 rpi400 systemd[1]: kresd@1.service: Scheduled restart job, restart counter is at 2.
Aug  1 09:37:23 rpi400 systemd[1]: Stopped Knot Resolver daemon.
Aug  1 09:37:23 rpi400 systemd[1]: Starting Knot Resolver daemon...
Aug  1 09:37:23 rpi400 systemd[1]: Started Knot Resolver daemon.
Aug  1 09:38:20 rpi400 kresd[5900]: [tls_cl] failed to verify peer certificate: The certificate is NOT trusted. The name in the certificate does not match the expected.
Aug  1 09:38:44 rpi400 kresd[5900]: message repeated 3 times: [ [tls_cl] failed to verify peer certificate: The certificate is NOT trusted. The name in the certificate doe



[martinus26]

po restart kresd1.service sa prva chyba [tls_cl] objavi po 15 minutach prevadzky.

[vcunat]

No tahle řádka je špatně

{'194.36.144.87', hostname='ns29.de.dns.opennic.glue', ca_file='/etc/ssl/certs/ca-certificates.crt'}

Vybraný server posílá jiný certifikát než s tímto jménem (uvedeným jako hostname).  Mimochodem, .glue v oficiálním DNS kořenu vůbec neexistuje, takže standardní certifikační autority na to jméno ani nesmí vydat certifikát.  Samozřejmě, můžete ho mít přidaný lokálně, apod.

[vcunat]

Ty "double free" chyby nevypadají že souvisí a to je to co způsobuje restarty služby.  Nejspíše nějaká chyba v našem kódu, zatím jsme o ní z jiného zdroje neslyšeli.

Bylo by pěkné, pokud byste mohl zaslat alespoň jeden z příslušných coredumpů (na vladimir.cunat@nic.cz), možná bychom z toho odhadli kde je problém.  Například přes příkaz coredumpctl dump -o /tmp/kresd-coredump se uloží poslední coredump do vybraného souboru.  Vypsaný stack-trace by možná taky stačil, ale často tam není dost informací.

[vcunat]

Aha, tak jsem zapomněl, nejspíše šlo o chybu co už byla opravena a bude v příštím releasu: https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1314

[vcunat]

Ale stejně... po spravení té (polo-)nefunkční konfigurace nejspíše nebude na tu chybu docházet.

[martinus26]

Odstránil som {'194.36.144.87', hostname='ns29.de.dns.opennic.glue', ca_file='/etc/ssl/certs/ca-certificates.crt'}

a už 3 dni všetko funguje bez chybovych hlaseni  . ( ziadba tls_cl chyba, ziadny crash knot resolvera,m, ziadny double free)

Tak to vyzera ze to opennic ma nejaky problem s certifikatmi/nastavenim.

Ďakujem za radu.

[vcunat]

Tak to vyzera ze to opennic ma nejaky problem s certifikatmi/nastavenim.

No je to OpenNIC.  Jejich hlavní téma je propagování vlastního alternativního jmenného systému, kde v kořenu "demokraticky" přidali nějaké další položky.  Například ten .glue, vizte jejich web pro další.

Samozřejmě že standardní certifikační autority pro jejich alternativní jména certifikát nemohou vydat.  Stejně tak ta jména nemohou fungovat s oficiálním DNSSEC kořenem (tedy ten používaný defaultně v Knot Resolveru).