- knot-resolver-users - lists.nic.cz

knot-resolver 4.2.2 - náhle přestane vracet odpovědi (status: SERVFAIL)

by Zdenek Janis

Dobrý den, dnes po mnoha dnech (měsíců) bezproblémového provozu knot-resolveru 4.2.2 najednou přestal vracet odpovědi na dotazy. Využívá jej několik tisíc klientů, tak nebyl moc čas na experimerny a reboot celého stroje pomohl... Ale jen asi na 15min. Pak opět přestal vracet záznamy, jako by je neměl. Opět reboot a to vydrželo fungovat asi 1.5h a opt přestal komunikovat. To už začalo být vážné, takže jsme spoustu DNS dotazů na routrech přesměrovali na 8.8.8.8. Mezi tím opět restart a nyní to již téměř 2h funguje bez problémů. Vím, že nyní již existuje knot-resolver verze 5.0.1, ale zajímá mě, zda uvedený problém je známy, jen jsem se sním do dnes nesetkal a v další verzi opraven, nebo se jedná o neevidovanou anomálii. V logách jsem totiž našel jen toto: Apr 27 18:17:56 knot-resolver systemd[1]: kresd(a)4.service: Watchdog timeout (limit 10s)! Apr 27 18:17:56 knot-resolver systemd[1]: kresd(a)4.service: Killing process 382 (kresd) with signal SIGABRT. Apr 27 18:17:56 knot-resolver systemd[1]: kresd(a)4.service: Main process exited, code=killed, status=6/ABRT Apr 27 18:17:56 knot-resolver systemd[1]: kresd(a)4.service: Failed with result 'watchdog'. Apr 27 18:17:56 knot-resolver systemd[1]: kresd(a)4.service: Service RestartSec=100ms expired, scheduling restart. Apr 27 18:17:56 knot-resolver systemd[1]: kresd(a)4.service: Scheduled restart job, restart counter is at 1. Předpokládám, že tato nemilá reakce knot-resolveru byla způsobena nějakým "spatným" dotazem, ať náhodným nebo záměrným. Nyní jsme opět zrušili přesměrovaní na 8.8.8.8 a téměř okamžitě přestal odpovídat: dig @192.168.100.100 -t AAAA www.seZNAm.cz ; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @192.168.100.100 -t AAAA www.seZNAm.cz ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64547 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.seZNAm.cz. IN AAAA ;; Query time: 0 msec ;; SERVER: 192.168.100.100#53(192.168.100.100) ;; WHEN: Po dub 27 22:32:04 CEST 2020 ;; MSG SIZE rcvd: 42 Děkuji za pomoc Zdeněk Janiš

4 roky, 11 měsíců

3
4
0 0

upstream package repositories - signing key update

by Tomas Krizek

Hi, the package signing key for our upstream repositories has expired and Debian and Ubuntu users with existing installation need to manually update the knot-resolver-release package to fix the issue: wget https://secure.nic.cz/files/knot-resolver/knot-resolver-release.deb dpkg -i knot-resolver-release.deb apt update Otherwise, apt update will report following errors and no new updates will be installed. W: GPG error: http://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolver-lates… InRelease: The following signatures were invalid: EXPKEYSIG 74062DB36A1F4009 home:CZ-NIC OBS Project <home:CZ-NIC@build.opensuse.org> E: The repository 'http://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolver-lates… InRelease' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. I apologize for the inconvenience. -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

4 roky, 11 měsíců

1
0
0 0

Maintain Fedora 29 Repo for a few more months?

by Richard Graham

Hello, Would it be possible to maintain the Fedora 29 knot-resolver repo for a few more months? It recently dropped off the mirrors and it's unclear if some F29 machines will be updated for a few more months. Thanks! R

4 roky, 11 měsíců

2
1
0 0

Knot Resolver 5.0.1

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.0.1 has been released! Bugfixes -------- - systemd: use correct cache location for garbage collector (#543) Improvements ------------ - cache: add cache.fssize() lua function to configure entire free disk space on dedicated cache partition (#524, !932) Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v5.0.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.0.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.0.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.0.1/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

5 let, 1 měsíc

1
0
0 0

Knot Resolver 5.0.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.0.0 has been released! This version has a few backward incompatible changes. Most notably, the network interface configuration has been moved back to the configuration file and configuration via systemd sockets is no longer supported. Unfortunately, this change requires a manual modification of your configuration file if you've previously configured your network interfaces via systemd sockets. Please follow the instructions printed out during package upgrade and check out our upgrading guide: https://knot-resolver.readthedocs.io/en/stable/upgrading.html We apologize for the inconvenience. Incompatible changes -------------------- - see upgrading guide: https://knot-resolver.readthedocs.io/en/stable/upgrading.html - systemd sockets are no longer supported (#485) - net.listen() throws an error if it fails to bind; use freebind option if needed - control socket location has changed (!922) - -f/--forks is deprecated (#529, !919) Improvements ------------ - logging: control-socket commands don't log unless --verbose (#528) - use SO_REUSEPORT_LB if available (FreeBSD 12.0+) - lua: remove dependency on lua-socket and lua-sec, used lua-http and cqueues (#512, #521, !894) - lua: remove dependency on lua-filesystem (#520, !912) - net.listen(): allow binding to non-local address with freebind option (!898) - cache: pre-allocate the file to avoid SIGBUS later (not macOS; !917, #525) - lua: be stricter around nonsense returned from modules (!901) - user documentation was reorganized and extended (!900, !867) - multiple config files can be used with --config/-c option (!909) - lua: stop trying to tweak lua's GC (!201) - systemd: add SYSTEMD_INSTANCE env variable to identify different instances (!906) Bugfixes -------- - correctly use EDNS(0) padding in failed answers (!921) - policy and daf modules: fix postrules and reroute rules (!901) - renumber module: don't accidentally zero-out request's .state (!901) Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v5.0.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.0.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.0.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.0.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

5 let, 2 měsíce

2
1
0 0

Re: [knot-resolver-users] knot-resolver-users Digest, Vol 93, Issue 1

by Milan Jeskynka Kazatel

Hello Petr, many thanks for your hint regarding modules.unload('bogus_log') I´m still facing the service kresd@1 crashes without any obvious reasons. Today I did a second try to upgrade to Knot Resover to version 4.2.2 and the upgrade seems to be ok, service can start without any difficulties. It runs as expected more than 3,5 hour, but unfortunately, it starts to write in the log the same messages as was reported in my previous post and the service get restart by itself. Every restarts couse a new sevice PID in /var/cache/ knot-resolver/tty, the old one was not correctly finished and the whole operating system goes to a visible slowdown. I don´t know how to do an exact sevice crashdump file, but I can provide any log messages if needed. I unload the bogus_log. The service runs now just a while. My usual dns queries throughput is around 700qps and I have only one PID in /var/cache/knot-resolver/tty as usual. Regards, -- Smil Milan Jeskyňka Kazatel ---------- Původní e-mail ---------- Od: knot-resolver-users-request(a)lists.nic.cz Komu: knot-resolver-users(a)lists.nic.cz Datum: 25. 10. 2019 11:53:00 Předmět: knot-resolver-users Digest, Vol 93, Issue 1 "Send knot-resolver-users mailing list submissions to knot-resolver-users(a)lists.nic.cz To subscribe or unsubscribe via the World Wide Web, visit https://lists.nic.cz/mailman/listinfo/knot-resolver-users or, via email, send a message with subject or body 'help' to knot-resolver-users-request(a)lists.nic.cz You can reach the person managing the list at knot-resolver-users-owner(a)lists.nic.cz When replying, please edit your Subject line so it is more specific than "Re: Contents of knot-resolver-users digest..." Today's Topics: 1. Re: DNSSEC validation failure logging on Centos 7 Knot Resolver, version 4.2.0 (Milan Jeskynka Kazatel) 2. Re: DNSSEC validation failure logging on Centos 7 Knot Resolver, version 4.2.0 (Petr Špaček) 3. HTTP module after upgrade from Knot DNS Resolver, version 2.3.0 to Knot Resolver, version 4.2.0 (Milan Jeskynka Kazatel) ---------------------------------------------------------------------- Message: 1 Date: Tue, 22 Oct 2019 14:27:30 +0200 (CEST) From: "Milan Jeskynka Kazatel" <KazatelM(a)seznam.cz> To: <knot-resolver-users(a)lists.nic.cz> Subject: Re: [knot-resolver-users] DNSSEC validation failure logging on Centos 7 Knot Resolver, version 4.2.0 Message-ID: <1XT.6dmr.1vQ4HW9UcyY.1ThlMo(a)seznam.cz> Content-Type: text/plain; charset="utf-8" Hello Team, I found it, it is described in the Upgrading guide, DNSSEC validation is now turned on by default. If you need to disable it, see Trust anchors and DNSSEC (https://knot-resolver.readthedocs.io/en/stable/daemon.html#dnssec-config). *** Since version 4.0, DNSSEC validation is enabled by default. This is secure default and should not be changed unless absolutely necessary. Options in this section are intended only for expert users and normally should not be needed. If you really need to turn DNSSEC off and are okay with lowering security of your system by doing so, add the following snippet to your configuration file. -- turns off DNSSEC validation trust_anchors.remove ('.'). *** Anyway, if it is enabled by default, how to prevent the "DNSSEC validation failure" spamming in the log and increasing the I/O operation on the system? For me now is the service in the unstable condition. My kresd@1 is crashing and restarting in the row. Please, any advice? I modify the server name and the domain, but still it is a live log output. Oct 22 14:02:51 dnstestserver kresd[15877]: DNSSEC validation failure example.com DNSKEY Oct 22 14:02:58 dnstestserver kresd[15877]: DNSSEC validation failure example.com DNSKEY Oct 22 14:03:08 dnstestserver kresd[15877]: DNSSEC validation failure example.com DNSKEY Oct 22 14:03:18 dnstestserver systemd[1]: kresd(a)1.service watchdog timeout (limit 10s)! Oct 22 14:03:22 dnstestserver systemd[1]: kresd(a)1.service: main process exited, code=killed, status=6/ABRT Oct 22 14:03:22 dnstestserver systemd[1]: Unit kresd(a)1.service entered failed state. Oct 22 14:03:22 dnstestserver systemd[1]: kresd(a)1.service failed. Oct 22 14:03:22 dnstestserver systemd[1]: kresd(a)1.service holdoff time over, scheduling restart. Oct 22 14:03:22 dnstestserver systemd[1]: Cannot add dependency job for unit kresd.service, ignoring: Unit not found. Oct 22 14:03:22 dnstestserver systemd[1]: Stopped Knot Resolver daemon. Oct 22 14:03:22 dnstestserver systemd[1]: Starting Knot Resolver daemon... Oct 22 14:04:07 dnstestserver kresd[16468]: [http] created new ephemeral TLS certificate Oct 22 14:04:07 dnstestserver systemd[1]: Started Knot Resolver daemon. Oct 22 14:04:07 dnstestserver kresd[16468]: [ta_update] refreshing TA for . Oct 22 14:04:07 dnstestserver kresd[16468]: [ta_update] key: 20326 state: Valid Oct 22 14:04:07 dnstestserver kresd[16468]: [ta_update] next refresh for . in 24 hours Oct 22 14:04:09 dnstestserver kresd[16468]: DNSSEC validation failure example.com DNSKEY ... Best regards. -- Smil Milan Jeskyňka Kazatel ---------- Původní e-mail ---------- Od: Milan Jeskynka Kazatel <KazatelM(a)seznam.cz> Komu: knot-resolver-users(a)lists.nic.cz Datum: 22. 10. 2019 13:33:46 Předmět: DNSSEC validation failure logging on Centos 7 Knot Resolver, version 4.2.0 "Hello Team, I would like to know if the "DNSSEC validation failure logging" is enabled by DEFAULT in version 4.2.0. on Centos 7. I do not have any explicit call for this module - as is described in the documentation like this: modules.load('bogus_log'), nevertheless, I´m facing a huge report in the system log regarding DNSSEC validation failure somedomainname. DNSKEY In the configuration, I´m using the 'http' module and module 'stats', can it be relevant? kresd.conf -- Load Useful modules modules = { 'policy', -- Block queries to local zones/bad sites 'view', -- Handle requests by source IP 'stats', -- Track internal statistics 'hints', -- Add static records to resolver } -- load HTTP module with defaults (self-signed TLS cert) modules.load('http') http.config() How can I disable DNSSEC validation failure logging? best regards, -- Smil Milan Jeskyňka Kazatel "

5 let, 3 měsíce

3
3
0 0

Knot Resolver 4.2.2

by Milan Jeskynka Kazatel

Hello Team, I would like to ask why my new version of Knot Resolver does many records of "DNSSEC validation failure szn-broken-dnssec.cz. DNSKEY" I tried to compare results with my second resolver on Unbound 1.9.4 where I' m able to receive an answer by command #unbound-control lookup szn-broken- dnssec.cz but no answer via dig command #dig szn-broken-dnssec.cz The same result via dig is on the server with new Knot Resolver 4.2.2 As was mentioned in your documentation https://knot-resolver.readthedocs.io/ en/stable/modules.html#dnssec-validation-failure-logging (https://knot-resolver.readthedocs.io/en/stable/modules.html#dnssec-validati…) I tried the https://dnsviz.net/d/szn-broken-dnssec.cz/dnssec/ (https://dnsviz.net/d/szn-broken-dnssec.cz/dnssec/) and the result is BOGUS, then should I be worried about this message in my log? Thanks for any answer, best regards -- Smil Milan Jeskyňka Kazatel

5 let, 3 měsíce

2
1
0 0

Knot Resolver 4.3.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 4.3.0 has been released! Security - CVE-2019-19331 ------------------------- - fix speed of processing large RRsets (DoS, #518) - improve CNAME chain length accounting (DoS, !899) Bugfixes -------- - http module: use SO_REUSEPORT (!879) - systemd: kresd@.service now properly starts after network interfaces have been configured with IP addresses after reboot (!884) - sendmmsg: improve reliability (!704) - cache: fix crash on insertion via lua for NS and CNAME (!889) - rpm package: move root.keys to /var/lib/knot-resolver (#513, !888) Improvements ------------ - increase file-descriptor count limit to maximum allowed value (hard limit; !876) - watchdog module: support testing a DNS query (and switch C -> lua; !878, !881) - performance: use sendmmsg syscall towards clients by default (!877) - performance: avoid excessive getsockname() syscalls (!854) - performance: lua-related improvements (!874) - daemon now attempts to drop all capabilities (!896) - reduce CNAME chain length limit - now <= 12 (!899) Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v4.3.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-4.3.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-4.3.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v4.3.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

5 let, 3 měsíce

1
0
0 0

Configuring kresd to query multiple nameservers and return the first affirmative response?

by Bernd Wechner

I wonder if this is possible. The Knot Resolver certainly looks powerful, and I use it on my Omnia Router of course. But the documentation <https://knot-resolver.readthedocs.io/en/stable/index.html>which I have perused and read quickly, hasn't helped me understand this alas. It leaves me with a couple of interesting questions: 1. How are nameservers configured? Interestingly my running instance of kresd is on the Omnia and it receives nameservers via a dhcp request on my ISP I imagine, though I don't see them in /etc/resolv.conf 2. Is it possible configure a number of nameservers on a the basis of query them all (akin to dnsmasq's --all-servers) and return the first affirmative response? My interest is acutely related to: https://superuser.com/questions/1505755/can-one-configure-name-resolution-t… And I'd happily use kresd on my local machine(s) as well as on my LAN DNS (The Omnia) to help resolve names on my .lan while on a VPN! Regards, Bernd.

5 let, 4 měsíce

3
4
0 0

policy.DENY during a CNAME chain

by Stephane Bortzmeyer

Now that Firefox blocks 3rd-party cookies by default, many sites try to hide the fact that a cookie is 3rd-party by using CNAMEs. % kdig +short A ftn.fortuneo.fr ftn-fr.eulerian.net. ftn.eulerian.net. 109.232.194.56 I want to block all the requests to *.eulerian.net. policy.add(policy.suffix(policy.DENY, {todname('eulerian.net.')})) Does not work since, to quote the documentation "The policy module currently only looks at whole DNS requests. The rules won’t be re-applied e.g. when following CNAMEs." % kdig A ftn.eulerian.net ;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 42477 ... ftn.eulerian.net. 10800 IN SOA ftn.eulerian.net. nobody.invalid. 1 3600 1200 604800 10800 % kdig A ftn.fortuneo.fr ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 59262 ... ftn.fortuneo.fr. 600 IN CNAME ftn-fr.eulerian.net. ftn-fr.eulerian.net. 5799 IN CNAME ftn.eulerian.net. ftn.eulerian.net. 5799 IN A 109.232.194.56 This seriously limits the usefulness of policy.DENY. What are the possible solutions?

5 let, 4 měsíce

3
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

knot-resolver-users