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

by Vladimír Čunát

On 02/01/2026 16.45, Michael Grimm wrote: > 1) files/patch-meson_options.txt This patch adds the option but doesn't act on the option in any way. (i.e. it doesn't affect the result except for some lines in the log) > 2) files/patch-controller_supervisord_plugin_notifymodule.c This patch might be interesting, though we just avoided the notify module on non-Linux since 6.0.17, so it's not really needed anymore. Maybe we'd need that notify-free code-path anyway for some other BSD or macOS; I don't remember details about this. --Vladimir

2 měsíce

1
0
0 0

kresd 5.7.6 NODATA cache TTL

by pawmal-knot＠freebsd.lublin.pl

Hello, it seems vanilla kresd (5.7.6-cznic.1~bookworm), when receives NODATA response (NOERROR, all RRs: 0) from remote authoritative server, stores record in cache with TTL=32768. Where is this value coming from/how can we alter it? (Seems hardcoded, not derived from SOA expiry or TTL.) Impact: may get negative ~9h cache for domains delegated to a server randomly returning NODATA Workaround: sacrifice cache hit ratio with cache.max_ttl(low_value) Reproduction: // wait 5-30 minutes while true; do echo 'cache.clear("mr-z01.tm-azurefd.net")' | socat - UNIX-CONNECT:/run/knot-resolver/control/1 >/dev/null; sleep 1; host -vvvvt a mr-z01.tm-azurefd.net 127.0.0.1; curl -s http://localhost:8451/trace/mr-z01.tm-azurefd.net; echo DONE; done 2>&1 | tee -a issue.log Watch log: // captured with cache.min_ttl(77), irrelevant here [cache ][65604.03] => satisfied by exact CNAME: rank 030, new TTL 16 [cache ][65604.05] => satisfied by exact RRset: rank 030, new TTL 16 [cache ][65605.01] => satisfied by exact packet: rank 030, new TTL 32768 <------ auth server return NODATA response (reason unknown) [cache ][65606.01] => satisfied by exact packet: rank 030, new TTL 32768 [cache ][65607.01] => satisfied by exact RRset: rank 030, new TTL 77 [cache ][65608.01] => satisfied by exact RRset: rank 030, new TTL 77 [cache ][65609.01] => satisfied by exact CNAME: rank 030, new TTL 77 [cache ][65609.03] => satisfied by exact CNAME: rank 030, new TTL 11 [cache ][65609.05] => satisfied by exact RRset: rank 030, new TTL 11 [cache ][65610.01] => satisfied by exact CNAME: rank 030, new TTL 77 [cache ][65610.03] => satisfied by exact CNAME: rank 030, new TTL 10 [cache ][65610.05] => satisfied by exact RRset: rank 030, new TTL 10 [cache ][65611.01] => satisfied by exact CNAME: rank 030, new TTL 77 [cache ][65611.03] => satisfied by exact CNAME: rank 030, new TTL 9 [cache ][65611.05] => satisfied by exact RRset: rank 030, new TTL 9 [cache ][65612.01] => satisfied by exact packet: rank 030, new TTL 32768 [cache ][65613.01] => satisfied by exact RRset: rank 030, new TTL 77 [cache ][65614.01] => satisfied by exact RRset: rank 030, new TTL 77 // host Trying "mr-z01.tm-azurefd.net" Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62752 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;mr-z01.tm-azurefd.net. IN A Received 39 bytes from 127.0.0.1#53 in 4 ms // kresd trace [iterat][65612.00] 'mr-z01.tm-azurefd.net.' type 'A' new uid was assigned .01, parent uid .00 [cache ][65612.01] => satisfied by exact packet: rank 030, new TTL 32768 [iterat][65612.01] <= answer received: ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 43459 ;; Flags: qr aa QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: Unused ;; QUESTION SECTION mr-z01.tm-azurefd.net. A ;; ADDITIONAL SECTION [iterat][65612.01] <= rcode: NOERROR [resolv][65612.01] AD: request NOT classified as SECURE [resolv][65612.01] finished in state: 4, queries: 1, mempool: 81952 B // cache miss trace [iterat][65637.03] <= rcode: NOERROR [cache ][65637.03] => stashed tm2.dns-tm.com. A, rank 030, 20 B total, incl. 0 RRSIGs [iterat][65637.01] 'mr-z01.tm-azurefd.net.' type 'A' new uid was assigned .04, parent uid .00 [select][65637.04] => id: '43668' choosing from addresses: 1 v4 + 0 v6; names to resolve: 2 v4 + 3 v6; force_resolve: 0; NO6: IPv6 is KO [select][65637.04] => id: '43668' choosing: 'tm2.dns-tm.com.'@'150.171.16.240#00053' with timeout 22 ms zone cut: 'tm-azurefd.net.' [resolv][65637.04] => id: '43668' querying: 'tm2.dns-tm.com.'@'150.171.16.240#00053' zone cut: 'tm-azurefd.net.' qname: 'mr-z01.tm-azurefd.net.' qtype: 'A' proto: 'udp' [select][65637.04] => id: '43668' updating: 'tm2.dns-tm.com.'@'150.171.16.240#00053' zone cut: 'tm-azurefd.net.' with rtt 4 to srtt: 2 and variance: 1 [iterat][65637.04] <= answer received: ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 43668 ;; Flags: qr aa QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: Unused ;; QUESTION SECTION mr-z01.tm-azurefd.net. A ;; ADDITIONAL SECTION [iterat][65637.04] <= rcode: NOERROR [cache ][65637.04] => stashed packet: rank 030, TTL 32768, A mr-z01.tm-azurefd.net. (62 B) [resolv][65637.04] AD: request NOT classified as SECURE [resolv][65637.04] finished in state: 4, queries: 2, mempool: 81952 B ;; selected from ANSWER sections: ; ranked rrset to_wire false, rank 030 (auth insecure), cached true, qry_uid 3, revalidations 0 tm2.dns-tm.com. 300 A 150.171.16.240

2 měsíce, 2 týdny

4
9
0 0

udp/tcp transport fallback strategy

by pawmal-knot＠freebsd.lublin.pl

Hi, it seems kresd 5.7.6 falls back from UDP to TCP transport but never retries over UDP. Impact: udp/53-only services (incorrect but happens in the wild[1]) may become ~permanently (long TTL) unreachable when udp/53 is not 100% reliable. When temporal udp/53 communication error occurs, kresd will fall back to tcp/53, fail to connect, store negative information and return SERVFAIL. Since retries only consider tcp/53 transport, there is no easy way to recover for udp/53-only domains. I believe it would be nice to retry with UDP as well as TCP (other implementations do this) to handle such cases more gently. [iterat][55073123.04] <= rcode: NOERROR [valdtr][55073123.04] <= cached insecure response, going insecure [iterat][55073123.02] 'www.somefooservice.com.' type 'A' new uid was assigned .05, parent uid .00 [select][55073123.05] => id: '37763' choosing from addresses: 0 v4 + 0 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is OK [select][55073123.05] => id: '37763' no suitable transport, zone cut: 'www.somefooservice.com.' [iterat][55073123.05] 'www.somefooservice.com.' type 'A' new uid was assigned .06, parent uid .00 [select][55073123.06] => id: '27070' choosing from addresses: 0 v4 + 0 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is OK [select][55073123.06] => id: '27070' no suitable transport, zone cut: 'www.somefooservice.com.' [resolv][55073123.06] AD: request NOT classified as SECURE [resolv][55073123.06] finished in state: 8, queries: 2, mempool: 81952 B Workaround: cache.max_ttl() - haven't tried cache.clear('FQDN record affected') does NOT work cache.clear('entire TLD affected') does NOT work cache.clear('.') DOES work cache.clear() DOES work [1] It took us some time to reach major mobile device producer and convince them to expose tcp/53 ;) /PM

2 měsíce, 2 týdny

1
0
0 0

Knot-resolver 6: collecting stats about blocked domains requests

by Stephane Paillet

Hello, I'm doing tests of filtering DNS with RPZ lists. Now, I would like to collect stats and metrics about blocked requests (blocked domains, sources IP, count of blocked requests...). In journalctl I have logs like this : "[rules ] => local data applied, user: xxx.xxx.xxx.xxx, name: blocked-domain.tld." Main infos I want to collect exist. Is there a way to do this with Prometheus format metrics + Grafana ? I didn't really find anything in documentation. Thank you so much if you have a tip to help me.

4 měsíce, 3 týdny

2
2
0 0

Knot Resolver 6 - replacing part of DNS tree

by jirka＠masek.pro

Hello, I was using Knot resolver 5 with configuration where I was replacing some parts of DNS tree (https://knot-resolver.readthedocs.io/en/latest/modules-policy.html#replacin…). Since I updated to Knot Resolver 6 and rewrite configuration to YAML using forward directive (https://www.knot-resolver.cz/documentation/latest/config-forward.html#forwa…) it seems that this configuration is not working as planned. After short time Knot Resolver started responding to replaced part of tree as NXDOMAIN. Is this behavior intended, or is it some unintended bug? Configuration for v6 was: forward: # Internal Domains - subtree: - internal.corp - 10.in-addr.arpa servers: - 10.3.0.102 - 10.3.0.103 options: authoritative: false dnssec: false I've tried to find if I do have something misconfigured, but without any luck. I have only a theory - in docs, it states like this: "Forwarding configuration instructs resolver to forward cache-miss queries from clients to manually specified DNS resolvers". Can the real reason of malfunction be, that Knot resolver 6 uses information from cache BEFORE it even tries to forward the query? Since I am not sure how Knot resolver handles these rules internally, it is only theory. Is there any correct way to replicate behavior from Knot Resolver 5? My config in v5 was: internalDomains = policy.todnames({ '10.in-addr.arpa', 'mydomain.corp' }) policy.add(policy.suffix(policy.FLAGS({'NO_CACHE'}), internalDomains)) policy.add(policy.suffix(policy.STUB({ '10.3.0.102', '10.3.0.103' }), internalDomains)) Regards, Jiri Masek

5 měsíců

3
8
0 0

Problem with tmpfs ???

by Ulrich Wisser

Hi, I run my knot-resolver on a raspberry pi with pxe boot and the root file system on nfs. I realize that this is not recommended operations. Therefore I try to run my cache on an tmpfs file system. > tmpfs on /var/cache/knot-resolver type tmpfs (rw,relatime,size=102400k) But now my knot-resolver refuses to start Oct 2 20:14:39 pi-hole1 systemd[1]: Starting Knot Resolver daemon... Oct 2 20:14:40 pi-hole1 kresd[1052]: [system] error while loading config: /etc/knot-resolver/kresd.conf:69: can't open cache path '/var/cache/knot-resolver'; working directory '/var/lib/knot-resolver'; No space left on device (workdir '/var/lib/knot-resolver') Oct 2 20:14:40 pi-hole1 systemd[1]: kresd(a)1.service: Main process exited, code=exited, status=1/FAILURE Oct 2 20:14:40 pi-hole1 systemd[1]: kresd(a)1.service: Failed with result 'exit-code'. Oct 2 20:14:40 pi-hole1 systemd[1]: Failed to start Knot Resolver daemon. Besides the fact that this message makes no sense (why wouldn't the cache be opened in /var/cache when /var/lib is full?), the cache gets actually opened and a database created. The kres-cache-gc process runs without problems. The /var/lib/knot-resolver directory exists and is writeable. I have tried to put it on tmpfs too, no luck. What solved the problem was root@pi-hole1:~# umount /var/cache/knot-resolver root@pi-hole1:~# systemctl start kresd@1 But now the cache is on nfs. That seems risky. I think this is the relevant part of the configuration -- Cache size workdir = '/var/cache/knot-resolver' cache.open(100 * MB, 'lmdb:///var/cache/knot-resolver') But it comes with a distro pre-config of -- Set cache location rawset(cache, 'current_storage', 'lmdb:///var/cache/knot-resolver') Which by the way makes it very hard to change cache location. Not to mention the hard coded location in the systemd script for kres-cache-gc. What do I do wrong? /Ulrich

5 měsíců, 1 týden

2
3
0 0

Knot Resolver 6.0.15

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.0.15 (early-access) has been released! Security: - DoS: fix a rare segfault in `resolve` function (!1717) Someone controlling the DNS traffic might be able to trigger this crash intentionally and too often. - DoS: drop a wrong assertion/crash (!1718) Someone controlling the DNS traffic will most likely be able to trigger this crash intentionally and too often. Bugfixes: - manager: prometheus metrics update (!1703, #917, !1712) - added missing metrics split by IPv4 and IPv6 - typo: resolver_answer_flags_rd_total -> resolver_answer_flag_rd_total - /dnssec/trust-anchors-files: fix resolver startup (!1704) - /network/edns-buffer-size: fix swapped upstream+downstream (!1711) - cache: fix a crash in case garbage collection is too slow (!1713) [system] assertion "env->is_cache" failed in cdb_write - /cache/prefill: fix 6.0.13 regression (!1705) - datamodel: improve file permission check (#933, !1714) - NO_CACHE flag: fix and tweak its behavior (!1715) Improvements: - update/more precise default answers for special names (!1709) https://www.iana.org/assignments/special-use-domain-names https://www.iana.org/assignments/locally-served-dns-zones - kresctl: strict validation is now disabled by default (!1714) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.15/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.15.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.15.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.0.15/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

7 měsíců, 3 týdny

1
0
0 0

Knot Resolver 5.7.6

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.7.6 (stable) has been released! Please consider using our packages from https://pkg.labs.nic.cz/doc/?project=knot-resolver and https://copr.fedorainfracloud.org/coprs/g/cznic/knot-resolver5 if you're not already using them. Security: - DoS: fix a rare segfault in `resolve` function (!1720) Someone controlling the DNS traffic might be able to trigger this crash intentionally and too often. - DoS: drop a wrong assertion/crash (!1721) Someone controlling the DNS traffic will most likely be able to trigger this crash intentionally and too often. Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.6/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.6.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.6.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v5.7.6/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

7 měsíců, 3 týdny

1
0
0 0

Re: [knot-dns-users] Knot Resolver 6.X : split config.yaml in several files ?

by Vladimír Čunát

Hello. On 23/06/2025 10.18, Stéphane Paillet wrote: > I would like to know if it's possible to split the config.yaml in > several files (the main config in one file, acl and views section in > another, data-local section with rpz lists and tags to rely acl lists > to blocklists in another), and if the answer is yes, how can I do ? Currently it's not possible. You could of course use some generator that produces the config.yaml, but that's of course less ergonomic. Incidentally we have this WIP: https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1710 --Vladimir

8 měsíců, 2 týdny

1
0
0 0

Knot Resolver 6.0.14

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.0.14 (early-access) has been released! Bugfixes: - /local-data/**: fix 6.0.13 regressions (!1697, !1699) The errors read as "wrong number of arguments for function call" or "does not have field named 'log'" Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.14/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.14.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.14.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.0.14/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

9 měsíců, 1 týden

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

knot-resolver-users