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

by Giles Crawford

Hi All, Just wondering how you guys are ingesting RPZ feeds into Knot Resolver. While Knot doesn't natively support zone transfers at this time, it can import the zone files, and then kick the zone if the file changes, so that's what I'm doing. I'm doing the zone transfers (10 zones from ioc2rpz) using BIND for now, and then writing the zone files to storage that Knot Resolver can read. I know that dns4eu uses Knot Resolver for their protective recursor service, so I'd be curious to know how they're doing this. Could be that they're using a custom version of Knot that's zone transfer capable. For context, I run Knot Resolver behind dnsdist, and they're complimentary, offering huge flexibility. Would be great to see rpz-passthru support in the BIND format too (forgive me if that's already possible) so that a traditional white-list-first tiered approach can be followed. (Super impressed with Knot resolver, so hats off to all at CZ). Cheers, GC

2 týdny, 6 dní

2
5
0 0

SERVFAIL with Internal Resolver

by Darren Rambaud

Hi knot-resolver-users -- I am looking to install a DNS resolver for my local network and `knot-resolver` seemed to fit the bill. Network is setup like this: VLAN 1 Gateway IP 10.0.0.5 Search Domain Name internal.example.com <http://internal.example.com/> VLAN 2 Gateway IP 10.0.1.1 Search Domain Name research.internal.example.com <http://research.example.com/> ... At the moment, `knot-resolver` deployed to a single server (10.0.1.6) with this configuration: ``` forward: - options: authoritative: true dnssec: false servers: - 10.0.0.5 subtree: - internal.example.com - options: authoritative: true dnssec: false servers: - 10.0.1.1 subtree: - research.internal.example.com logging: level: info network: listen: - freebind: false interface: - 127.0.0.1 - 10.0.1.6 kind: dns port: 53 workers: 1 ``` On another machine (10.0.0.100), public queries resolve correctly: ``` # dig @10.0.1.6 knot-resolver.cz ; <<>> DiG 9.20.17 <<>> @10.0.2.6 knot-resolver.cz ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34301 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;knot-resolver.cz. IN A ;; ANSWER SECTION: knot-resolver.cz. 1800 IN A 217.31.204.96 ;; Query time: 1281 msec ;; SERVER: 10.0.1.6#53(10.0.1.6) (UDP) ;; WHEN: Fri Jan 30 16:19:23 CST 2026 ;; MSG SIZE rcvd: 61 # nslookup knot-resolver.cz 10.0.1.6 Server: 10.0.1.6 Address: 10.0.1.6#53 Non-authoritative answer: Name: knot-resolver.cz Address: 217.31.204.96 Name: knot-resolver.cz Address: 2001:1488:800:400::2:96 ``` Queries within internal network return the correct assigned IP address however report `SERVFAIL`: ``` # nslookup m1.research.internal.example.com 10.0.2.6 Server: 10.0.1.6 Address: 10.0.1.6#53 Non-authoritative answer: Name: m1.research.internal.example.com Address: 10.0.2.6 ;; Got SERVFAIL reply from 10.0.1.6 ** server can't find m1.research.internal.example.com: SERVFAIL ``` Replacing `10.0.2.6` with `10.0.0.5` (gateway IP that normally acts as resolver) does not return `SERVFAIL`: ``` # nslookup obnoxious.research.in.rambaud.dev 10.0.0.5 Server: 10.0.0.5 Address: 10.0.0.5#53 Name: m1.research.internal.example.com Address: 10.0.2.6 ``` Is the SERVFAIL something I should worry about here? Or is there a misconfiguration on my end with `knot-resolver`? Darren

2 týdny, 6 dní

3
2
0 0

Knot Resolver 6.2.0

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.2.0 has been released! Improvements: - DNS-over-QUIC (DoQ) is available for serving (beta, !1747) Bugfixes: - fix UDP answers without sendmmsg, e.g. on non-Linux (!1795) - fix /logging/groups in python 3.8 (!1799) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.2.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.2.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.2.0.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.2.0/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

3 týdny

1
0
0 0

Re: is there a way to force DNS64 synthesis for specific domains that have native AAAA records?

by Vladimír Čunát

On 12/01/2026 00.11, * wrote: > However, I cannot use it in my production environment as this returns > NODATA globally (all views) for security.ubuntu.com. > I have several views not using dns64 for which the AAAA record should > be the existing original answer. While on Lua level it's not ergonomic, tags are supported in these APIs, so you can do a tiny change, e.g.: lua: policy-script: | assert(C.kr_rule_local_data_ins( kres.rrset(kres.str2dname('security.ubuntu.com.'), kres.type.AAAA, nil, C.KR_RULE_TTL_DEFAULT), nil, policy.get_tagset({'myTag'}), C.KR_RULE_OPTS_DEFAULT ) == 0) and then you just need to add myTag to the views where you want to apply this rule (in YAML). You can read more about tags and views in the docs, around page https://www.knot-resolver.cz/documentation/latest/config-policy-new.html

1 měsíc, 1 týden

3
2
0 0

Knot Resolver 6.0.16

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.0.16 (early-access) has been released! Improvements: - reduce validation strictness for domain names (#934, !1727) - manager: force a configuration reload via management HTTP API 'api/reload/force' (#939, !1748) - kresctl: reload: added '--force' flag - /fallback: add this feature/module (!1733) - systemd: do not force-fail knot-resolver.service on OOM (!1724) In basically all cases the OOM killer will kill a kresd process and supervisord will just restart it, and everything will keep working. Bugfixes: - /options/query-case-randomization: respect this even on TCP issues (!1732) - prometheus metrics: make the latency histogram cumulative (!1731, GH#117) - fix file permission checks when running as root (!1741) - /network/address-renumbering: fix conversion to Lua configuration (!1739) - manager: avoid uncommon bugs when starting/quitting policy-loader (!1742) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.16/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.16.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.16.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.0.16/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 měsíc, 2 týdny

3
4
0 0

Knot Resolver 6.0.17

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.0.17 (early-access) has been released! Improvements: - kresctl migrate: new command for migrating the configuration to a newer version (!1672) - manager: basic support for non-Linux systems (macOS, FreeBSD) (!1758) - cache: collect garbage based on usage statistics (!1726) This results in using the cache space better, and in practice it reduces latency especially in case of answers that are *not* fully cached. Incompatible changes: See upgrading guide for incompatible configuration changes: https://www.knot-resolver.cz/documentation/v6.0.17/upgrading.html - Removed options from declarative configuration model (YAML). (!1672, !1754) These are mostly experimental and debugging/testing options that are not useful for general users (remain in Lua): - /dnssec/refresh-time - /dnssec/hold-down-time - /dnssec/time-skew-detection - /dnssec/keep-removed - /local-data/root-fallback-addresses* - /logging/debugging - /max-workers - /network/tls/auto-discovery - /webmgmt - Renamed/moved options in the declarative configuration model (YAML). (!1672) - /cache/garbage-collector -> /cache/garbage-collector/enable - /cache/prefetch/prediction -> /cache/prefetch/prediction/enable - /defer/enabled -> /defer/enable - /dns64: true|false -> /dns64/enable: true|false - /dns64/rev-ttl -> /dns64/reverse-ttl - /dnssec: true|false -> /dnssec/enable: true|false - /dnssec/trust-anchor-sentinel -> /dnssec/sentinel - /dnssec/trust-anchor-signal-query -> /dnssec/signal-query - /logging/dnstap -> /logging/dnstap/enable - /logging/dnssec-bogus -> /dnssec/log-bogus - /monitoring/enabled -> /monitoring/metrics - /monitoring/graphite -> /monitoring/graphite/enable - /network/proxy_protocol -> /network/proxy_protocol/enable - /network/tls/files-watchdog -> /network/tls/watchdog - /rate-limiting -> /rate-limiting/enable - Changed default values in declarative configuration model (YAML). (!1672) - /logging/dnstap/log-queries: true -> false - /logging/dnstap/log-responses: true -> false - /logging/dnstap/log-tcp-rtt: true -> false Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.17/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.17.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.17.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.0.17/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 měsíc, 2 týdny

5
8
0 0

Knot Resolver 6.1.0 (stable)

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.1.0, the first officially stable version 6, has been released! As of this release, version 6 is preferred over version 5. Improvements: - logging: improved logging groups (!1768) - support libdnssec merged into libknot, as planned for knot >= 3.6 (!1769) - support cmocka 2.0.0 (!1772) - avoid AD=1 in reply if ANSWER+AUTHORITY are empty (#914, !1780) - defer: enabled by default in declarative configuration (!1785) - /defer/enable: false -> true - datamodel: lua: added Lua scripts for policy-loader (!1771) Bugfixes: - reload did not apply changes to /fallback (!1763) - fix config.cache.clear test on apple silicon (!1766) - cache: fix wrong TTL in some cases, typically 32768 (!1774) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.1.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.1.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.1.0.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.1.0/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 měsíc, 2 týdny

1
0
0 0

kresd 5.7.6, secondary NS-es may not be tried if single auth NS fails

by Paweł Małachowski

There is a domain delegated to 4 NS-es. If I block network connectivity with auth NS 1, kresd sometimes returns and caches SERVFAIL without trying secondary NS-es 2-4. Impact: single faulty auth NS affects multi-NS domain resolvability. How to reproduce: knot-resolver 5.7.6-cznic.1~bookworm amd64 -- Network interface configuration net.listen('127.0.0.1', 53, { kind = 'dns' }) net.listen('::1', 53, { kind = 'dns', freebind = true }) net.listen('127.0.0.1', 8452, { kind = 'webmgmt' }) modules = { 'hints > iterate', -- Allow loading /etc/hosts or custom root hints 'stats', -- Track internal statistics 'http', 'cache', } cache.size = 100 * MB let's use domain: trafficmanager.net name server tm1.dns-tm.com. trafficmanager.net name server tm1.edgedns-tm.info. trafficmanager.net name server tm2.dns-tm.com. trafficmanager.net name server tm2.edgedns-tm.info. Intentionally block communication with tm2.dns-tm.com (tm2.dns-tm.com has address 150.171.16.240): # ip route add blackhole 150.171.16.240 or table inet filter { chain input { type filter hook input priority filter; } chain forward { type filter hook forward priority filter; } chain output { type filter hook output priority filter; ip daddr 150.171.16.240 drop } } Flush kresd cache: # echo 'cache.clear()' | socat - UNIX-CONNECT:/run/knot-resolver/control/1 Query admin.exchange.microsoft.com. Repeat cache.flush and query few times if needed). If kresd tries faulty NS as first, it returns and caches SERVFAIL. All following queries will also return SERVFAIL. Please note, when this happens, other auth NS-es (tm1.dns-tm.com., tm1.edgedns-tm.info., tm2.edgedns-tm.info.) are reachable but not tried. # while sleep 1; do host admin.exchange.microsoft.com 127.0.0.1 | grep admin; done Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) [...] admin.exchange.microsoft.com is an alias for admin.exchange.trafficmanager.net. admin.exchange.trafficmanager.net is an alias for eacafdprod-fzakegfrabbub0ab.z01.azurefd.net. admin.exchange.microsoft.com is an alias for admin.exchange.trafficmanager.net. admin.exchange.trafficmanager.net is an alias for eacafdprod-fzakegfrabbub0ab.z01.azurefd.net. admin.exchange.microsoft.com is an alias for admin.exchange.trafficmanager.net. admin.exchange.trafficmanager.net is an alias for eacafdprod-fzakegfrabbub0ab.z01.azurefd.net. admin.exchange.microsoft.com is an alias for admin.exchange.trafficmanager.net. [...] Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) ^C # curl http://localhost:8452/trace/admin.exchange.trafficmanager.net [iterat][66079.00] 'admin.exchange.trafficmanager.net.' type 'A' new uid was assigned .01, parent uid .00 [cache ][66079.01] => no NSEC* cached for zone: trafficmanager.net. [cache ][66079.01] => skipping zone: trafficmanager.net., NSEC, hash 0;new TTL -123456789, ret -2 [cache ][66079.01] => skipping zone: trafficmanager.net., NSEC, hash 0;new TTL -123456789, ret -2 [zoncut][66079.01] found cut: trafficmanager.net. (rank 010 return codes: DS 1, DNSKEY 1) [resolv][66079.01] => NS is provably without DS, going insecure [select][66079.01] => id: '03790' choosing from addresses: 2 v4 + 0 v6; names to resolve: 2 v4 + 4 v6; force_resolve: 0; NO6: IPv6 is KO [select][66079.01] => id: '03790' choosing: 'tm2.dns-tm.com.'@'150.171.16.240#00053' with timeout 400 ms zone cut: 'trafficmanager.net.' [resolv][66079.01] => id: '03790' querying: 'tm2.dns-tm.com.'@'150.171.16.240#00053' zone cut: 'trafficmanager.net.' qname: 'exchange.trafficmanager.net.' qtype: 'NS' proto: 'udp' [resolv][66079.00] request failed, answering with empty SERVFAIL [resolv][66079.01] finished in state: 8, queries: 0, mempool: 81952 B /PM

1 měsíc, 2 týdny

2
2
0 0

Introduction and questions about RPZ support

by Francis Turner

HI there, I work for ThreatSTOP, a company that distributes DNS policies using RPZ to our customers. One prospective customer uses knot-resolver and so they have asked us to look at what we can support with respect to importing our data into knot-resolver. I have read the documentation and I have done some testing with 5.7.2 that is the version in Ubuntu 24.04 I have also read some of the documentation for version 6.x I have a few questions The first is fairly basic. What is the status of 6.x? >From what I can see it seems to be undergoing development and not to be considered as stable. Is this correct? And therefore we should not recommend it to our users? Assuming that is the case, it's unfortunate because RPZ support seems to be considerably better in 6.x. however I'm still a bit confused as to the RPZ support and would appreciate being pointed to a spec. The 6.x documentation was not clear to me Also I have questions about policy limitations, which I don't see in the documentation for 5.x How large can an RPZ be? How many policies can you have? For example I'd like an ALLOW, a DENY and perhaps one to three A record rewrite policies. The total across all RPZs would be in the 500k-1M records. Also assuming it is supported, what are the performance impacts of large (say 500k+) RPZ policies? I intend to test some of this, but if there are known limits that can be shown that will help both the testing and the recommendations to our customers Finally is there a place to publicize a script that does a zone transfer of a policy from an external server (e.g. ours) and outputs 3 or 4 zones in the right format for knot-resolver to import? Regards Francis Francis Turner Threat STOP Global SE JP Cell: +81-8080404701 | US Cell: +1-760-402-7676 Office: +1-760-542-1550 | Line: francisturner francis(a)threatstop.com<mailto:francis@threatstop.com> | www.threatstop.com<http://www.threatstop.com/> Weaponize Your Threat Intelligence "If You Don't Build It, They Definitely Will Not Come" - P. Vixie

1 měsíc, 2 týdny

2
8
0 0

Re: Knot Resolver 6.0.17

by Leo Vandewoestijne

Hi, Between countless parcel notifications in my inbox, I suddenly found this message... ...just moments after I posted my modification (which is entirely focussed on setup.py): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292197 I'm now merging that with what's suggested here. So it's getting further than before, but is not yet completing successfully. Leo. On Fri, 02 Jan 2026, Michael Grimm wrote: > Vladim??r ??un??t via knot-resolver-users <knot-resolver-users(a)lists.nic.cz> wrote: > > On 31/12/2025 13.37, Michael Grimm via knot-resolver-users wrote: > > >> FYI: This is FreeBSD and kresctl tool isn't available here. > > > OK, that's a complication. In 6.0.17 we added FreeBSD support to code added in 6.x, and now we're in contact with the maintainer of the [port], but the last version I saw didn't seem to package all parts needed for YAML (e.g. executables called knot-resolver and kresctl). > > In March 2024 I tried to create a FreeBSD port for knot-resolver-6.0.8. I got it compiled after applying the following changes (see tar file attached). I do remember that I could use kresctl in a poudriere testport jail, only, but I can't reproduce that as of today, sorry. > > (This is intended as a FYI, just in case it helps.) > > 1) files/patch-meson_options.txt > > This adds a manager section to meson_options.txt. > With that I could tell meson to use '-Dmanager=enabled' within the port's Makefile > > This section is missing in 6.0.17 as well. If added meson log file tells me that a manager is enabled. > > I do not have the knowledge if that is necessary at all, though > > > 2) files/patch-controller_supervisord_plugin_notifymodule.c > > This patch addresses: > > #) include sys/ucred.h > #) use LOCAL_PEERCRED instead of SO_PASSCRED > #) use 'struct xucred' instead of 'struct ucred' > #) use SCM_CREDS instead of SCM_CREDENTIALS > #) use cred.cr_pid instead of cred.pid as returned value > > Again, I do not have the knowledge if that is of relevance at all. > > > I applied both patches to Leo's port and modified the Makefile accordingly (see tar), and it compiles successfully; but is still lacking kresctl and knot-resolver. > > > I hope that this might be of interest for you. > > Regards, > Michael >

1 měsíc, 2 týdny

2
1
0 0

Re: Knot Resolver 6.0.17

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

1 měsíc, 2 týdny

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

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, 1 týden

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, 1 týden

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

4 měsíce, 2 týdny

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

4 měsíce, 3 týdny

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ů, 1 týden

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ů, 1 týden

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ů

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

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

1
0
0 0

[PATCH 0/1] Fix crash in knot-resolver6 v6.0.13 when local-data enabled

by Brad Cowie

knot-resolver6 v6.0.13 introduces a bug that causes an invalid policy-loader.conf to be generated when the following local-data options are enabled: * addresses * addresses-files * rules/subtree The log message from the crash: kresd[223706]: [system] error while loading config: policy-loader.conf:65: wrong number of arguments for function call (workdir '/run/knot-resolver') The attached patch fixes this crash: Brad Cowie (1): datamodel/templates: fix kr_rule_local_* macros .../templates/macros/local_data_macros.lua.j2 | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) -- 2.43.0

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

2
2
0 0

Knot Resolver 6.0.13

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.0.13 (early-access) has been released! Security: - DoS: fix more rare crashes with `requirement` failing (#930, !1696) [system] requirement "session2_is_empty(s)" failed in session2_transport_event (and others not observed in practice) Bugfixes: - fix `dnssec: false` (!1687) - fix undefined disable_defer (!1685) - daemon: fix a memory leak present since v6.0.9 (#927) - fix logging `[prefil] empty zone file` (!1688) Improvements: - C++ compatibility of lib/ headers (!1689) - /local-data/rpz/*/log: add option to log RPZ matches (!1694) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.13/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.13.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.13.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.0.13/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

9 měsíců

2
1
0 0

error with root.keys permissions

by Mike Wright

Hi, I'm receiving this error: ERROR: write access needed to keyfile dir '/etc/knot-resolver/root.keys' Current permissions are 775 knot-resolver:knot-resolver. I've also tried 0:0. Contents of the dir are same owner 664. Suggestions? Thanks, Mike Wright

10 měsíců

2
1
0 0

Kresd installation

by Ulrich Wisser

Hi, on a fresh debian system I followed this installation guide https://www.knot-resolver.cz/documentation/stable/quickstart-install.html The package installed successfully, but after that things get a bit more difficult The installed gpg key is expired > /etc/apt/trusted.gpg.d/cznic-obs.gpg > ------------------------------------ > pub rsa2048 2018-02-15 [SC] [verfallen: 2024-08-15] > 4573 7F9C 8BC3 F3ED 2791 8182 7406 2DB3 6A1F 4009 > uid [ verfallen ] home:CZ-NIC OBS Project > <home:CZ-NIC@build.opensuse.org> > > "verfallen" means expired. Sorry that system speaks german (german hoster). Makes it kind of hard to install kresd. :-) And while we are at it, why are there no kresd packages for the raspberry pi? Please!!! Kind regards /Ulrich

10 měsíců

2
3
0 0

Knot Resolver 6.0.12

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.0.12 (early-access) has been released! Security: - DoS: fix rare crashes with either of the lines below (!1682) [system] requirement "h && h->end > h->begin" failed in queue_pop_impl [system] requirement "val == task" failed in session2_tasklist_del Bugfixes: - daemon: fix DoH with multiple "parallel" queries in one connection (#931, !1677) - /management/unix-socket: revert to absolute path (#926, !1664) - fix `tags` when used in /local-data/rules/*/records (!1670) - stats: request latency was very incorrect in some cases (!1676) Improvements: - /local-data/rpz/*/watchdog: new configuration to enable watchdog for RPZ files (!1665) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.12/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.12.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.12.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.0.12/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

10 měsíců

1
0
0 0

Knot Resolver 5.7.5

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.7.5 (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 unconfirmed crashes with the line below (!1683) [system] requirement "h && h->end > h->begin" failed in queue_pop_impl Improvements: - tests: disable problematic config.http test (#925, !1678) - validator: accept a confusing NODATA proof with insecure delegation (!1678) Bugfixes: - daemon/http: DoH stream got stuck after returning an error code (!1652) - stats: request latency was very incorrect in some cases (!1678) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.5/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.5.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.5.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v5.7.5/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

10 měsíců

1
0
0 0

Re: Weird memleak since v6.0.9

by Vladimír Čunát

I'm afraid that DoH in 6.0.x is in much worse trouble than just memleaks; see: https://gitlab.nic.cz/knot/knot-resolver/-/issues/931

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

1
0
0 0

Is it possible to forward to authoritative servers?

by Stephane Bortzmeyer

I'm trying to set up a resolver with the addition of an invented TLD (this is an experiment, no need to explain to me that it may be a bad idea). I have authoritative name servers for the dummy TLD, which is signed with DNSSEC and I want DNSSEC validation. The documentation says that policy.FORWARD requires to forward to a resolver :-( policy.STUB disables validation so it is a no-no. If I configure with policy.add + policy.FORWARD, and trust_anchors.add for the key of the dummy TLD, it works for the TLD apex, for subdomains of the TLD which are NOT signed but for signed subdomains of the TLD, I get SERVFAIL + "EDE: 12 (NSEC Missing): (AHXI)". Querying directly the authoritative name servers with the DO bit, I get all the RRSIG and NSEC I need. But apparently, Knot cannot get them. Knot-resolver 5.7.4

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

2
2
0 0

Re: Weird memleak since v6.0.9

by Vladimír Čunát

On 02/04/2025 23.19, oui.mages_0w(a)icloud.com wrote: > So knot-resolver 6.0.8 with libknot15 seems to also trigger the memory > leak I was experiencing with knot-resolver 6.0.9+ by the unidentified > traffic pattern (or whatever is causing this). Thanks, this is very interesting. I confirm that (for our Ubuntu 24.04 packages), libknot15 (i.e. knot 3.4) is used exactly since 6.0.9, so the timing checks out, too. That's just a matter of binary builds. Even the latest versions can still be built with libknot14 (3.3.x) Have you looked into which libdnssec and libzscanner you have there? The thing is that these two didn't change soname between knot 3.3 and 3.4, so here I see larger risks than with libknot itself.

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

3
3
0 0

Knot-resolver stats module per process

by Marcel Adamski

Hello, In short, we do use stats module with http module exposing webmgmt every time SYSTEMD process knot is started (we do have 30 on one machine). Unfortunately each of webmgmt shows the same stats in /stats or /metrics endpoint (prometheus) Checking metrics with socat, going into each process and running stats.list() shows correctly stats per process. Is there any way to have automatically exported per knot process statistics? Regards, _ *Marcel Adamski*DevOps Engineer *M: *+48 882 115 524 *Redge *Technologies Ostrobramska 86 | 04-163 Warsaw *T: *+48 22 255 11 00 | *F: *+48 22 255 15 50 *www.redge.com* <https://redge.com/> [image: RedgeTechnologies] *Redge Technologies Sp. z o.o.* *VAT No:* PL1132687365 | *REGON:* 141103558 | *KRS: *0000287417 District Court for the Capital City of Warsaw, XIV Commercial Division of National Court Register | Share capital: 501 650 PLN We use personal data in accordance with our privacy policy <https://redge.com/privacy-policy/>

11 měsíců

2
1
0 0

Kresd - Multiple instances.

by Łukasz Trąbiński

Hello We are using knot-resolver 5.7.4 with multiple independent instances - 32. We also use tmpfs. We starts processes by systemd. the problem we encountered is that when systemd starts 32 processes, they get a timeout and are restarted by systemd. As a result, we have problems starting all processes. The problem does not occur when we do not use tmpfs. How to solve this problem? We shoud add to systemd something like this? ExecStartPre=/bin/sleep $(( RANDOM % 5 )) [Service] StartLimitBurst=5 StartLimitIntervalSec=10 Or we should something to kresd configuration?

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

1
0
0 0

root trust anchors

by Mike Wright

Hi, I've found this warning in my journal: ... kresd[1071788]: [taupd ] you need to update package with trust anchors in "/usr/share/dns/root.key" before it breaks I don't know how to do that. I think my system is current but just ran: apt update; apt list --upgradable and it shows nothing regarding knot. Thanks for any pointers, Mike Wright

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

3
3
0 0

Knot Resolver 6.0.10

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.0.10 (early-access) has been released! Improvements: - avoid multiple log lines when IPv6 isn't available (!1633) - manager: fix startup on Linux without libsystemd (!1608) - auto-reload TLS certificate files (!1626) - Can be configured using the /network/tls/files-watchdog option. (!1645) - reload TLS certificate files even if the configuration has not changed (!1644) - kresctl: bash command-line TAB completion (!1622) - add request prioritization (defer) to mitigate DoS attacks (!1641) - views: allow overriding price-factor (!1646) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.10/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.10.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.10.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.0.10/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

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

4
6
0 0

Knot Resolver 6.0.11

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.0.11 (early-access) has been released! Bugfixes: - manager: avoid an uncommon startup race in policy-loader (!1653) [WARN] exited: policy-loader (exit status 0; not expected) - manager: fix processes watchdog errors during shutdown (!1651) - /cache/prefill/*/ca_file: fix setting this attribute (!1655) Improvements: - manager: allow multiple instances with different rundirs (!1656) - tests: disable problematic config.http test (#925, !1662) - /management/unix-socket: allow path relative to rundir (!1657) - validator: accept a confusing NODATA proof with insecure delegation (!1659) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.11/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.11.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.11.tar.xz.asc <https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.11.tar.xz.asc> Documentation: https://www.knot-resolver.cz/documentation/v6.0.11/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

12 měsíců

1
0
0 0

different forwarder and no cache for specific host

by Mathieu Roy

Hello, On my local network, I have a computer fixed IP that I would like to use a specific TLS FORWARD. Generic TLS_FORWARD is simply configured as such. policy.add(policy.all(policy.TLS_FORWARD({ {'9.9.9.9', hostname='dns9.quad9.net'}, {'1.1.1.1', hostname='cloudflare-dns.com'}, {'1.0.0.1', hostname='cloudflare-dns.com'}, }))) I tried to embed a specific different TLS_FORWARD with a view:addr('10.10.10.10', ... ) but I cannot manage to restrict this TLS_FORWARD and to avoid it poisoning the cache. Is there somewhere an example of such setup, with ACL ending up on two different TLS_FORWARD and one with no cache ? Regards, -- Mathieu Roy

1 rok

2
1
0 0

Knot Resolver 6.0.9

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.0.9 (early-access) has been released! Improvements: - rate-limiting: add these options, mechanism, docs (!1624) - manager: secret for TLS session resumption via ticket (RFC5077) (!1567) The manager creates and sets the secret for all running 'kresd' workers. The secret is created automatically if the user does not configure their own secret in the configuration. This means that the workers will be able to resume each other's TLS sessions, regardless of whether the user has configured it to do so. - answer NOTIMPL for meta-types and non-IN RR classes (!1589) - views: improve interaction with old-style policies (!1576) - stats: add stale answer counter 'answer.stale' (!1591) - extended_errors: answer with EDE in more cases (!1585, !1588, !1590, !1592) - local-data: make DNAMEs work, i.e. generate CNAMEs (!1609) - daemon: use connected UDP sockets by default (#326, !1618) - docker: multiplatform builds (#922, !1623) - docker: shared VOLUMEs are prepared for configuration and cache (!1625, !1627) Configuration path was changed to standard '/etc/knot-resolver/config.yaml'. Bugfixes: - daemon/proxyv2: fix informing the engine about TCP/TLS from the actual client (!1578) - forward: fix wrong pin-sha256 length; also log pins on mismatch (!1601, #813) Incompatible changes: - -f/--forks is removed (#631, !1602) - gnutls < 3.4 support is dropped, released over 9 years ago (!1601) - libuv < 1.27 support is dropped, released over 5 years ago (!1618) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.9/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.9.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.9.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.0.9/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 rok, 3 měsíce

1
0
0 0

Forward DNS Query Based on Specific Answer (Matching IP Address)

by ealireza＠gmail.com

Issue Summary: I need to forward DNS queries to a secondary DNS server if a specific value (IP address) is returned in the DNS response. Specifically, if the answer contains 192.168.1.1, I want the request to be forwarded to 10.10.10.1 for re-resolution. Expected Behavior: A user queries for a domain (e.g., dig alibaba.com). If the result contains the IP address 192.168.1.1, the query should be automatically forwarded to another DNS server (e.g., 10.10.10.1) for further resolution. Current Attempt: lua policy.add(policy.all(function (state, req) log("info Policy function triggered") -- Get the DNS answer section local answer = req:answer() if answer then for _, record in ipairs(answer) do -- Check if the response is an A record and contains the IP 192.168.1.1 if record.stype == kres.type.A and tostring(record.rdata) == '192.168.1.1' then log("info IP is 192.168.1.1, forwarding to 10.10.10.1") -- Forward the query to the specified DNS server return policy.FORWARD({'10.10.10.1'}) end end else log("info No answer found") end return kres.DONE end), true) Issue: The function triggers correctly, but the query is not being forwarded to the specified DNS server when the condition (record.rdata == '192.168.1.1') is met. Steps to Reproduce: Add the above Lua code to the Knot Resolver configuration. Query for a domain (dig alibaba.com). If the result contains the IP 192.168.1.1, the query should be forwarded, but it does not. Environment: Knot Resolver Version: [Include version] Operating System: [Your OS] Configuration: [Any relevant additional configuration] Desired Solution: I would like the query to forward correctly to 10.10.10.1 whenever the answer contains 192.168.1.1. Any guidance on why the forward might not be triggered or if additional configurations are needed would be appreciated.

1 rok, 5 měsíců

2
1
0 0

DNS rebinding protection - issue with apple.com

by Aleš Rygl

Hello, we are observing that Knot-resolver is refusing certain queries because of enabled DNS rebinding protection to subdomains beneath apple.com. IMHO there is no reason for that - they are not pointing to a private addres range. For instance: Unbound: dig init.ess.apple.com @127.0.0.1 -p 53 ; <<>> DiG 9.18.24-1-Debian <<>> init.ess.apple.com @127.0.0.1 -p 53 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38044 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;init.ess.apple.com. IN A ;; ANSWER SECTION: init.ess.apple.com. 81 IN CNAME init-cdn-lb.ess-apple.com.akadns.net. init-cdn-lb.ess-apple.com.akadns.net. 27 IN CNAME init.ess.g.aaplimg.com. init.ess.g.aaplimg.com. 12 IN A 17.253.73.204 init.ess.g.aaplimg.com. 12 IN A 17.253.73.205 init.ess.g.aaplimg.com. 12 IN A 17.253.73.203 init.ess.g.aaplimg.com. 12 IN A 17.253.73.201 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Wed Sep 18 10:42:46 CEST 2024 ;; MSG SIZE rcvd: 194 Knot-resolver 5.7.4-cznic.1 freshly re-installed: dig init.ess.apple.com @127.0.0.1 -p 2053 ; <<>> DiG 9.18.24-1-Debian <<>> init.ess.apple.com @127.0.0.1 -p 2053 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17074 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; EDE: 18 (Prohibited): (EIM4) ;; QUESTION SECTION: ;init.ess.apple.com. IN A ;; ADDITIONAL SECTION: explanation.invalid. 10800 IN TXT "blocked by DNS rebinding protection" ;; Query time: 8 msec ;; SERVER: 127.0.0.1#2053(127.0.0.1) (UDP) ;; WHEN: Wed Sep 18 10:45:40 CEST 2024 ;; MSG SIZE rcvd: 124 I have also tried to remove the cache under /var/cache/knot-resolver but without any effect. There are more domain names with this beavior: query.ess.apple.com comm-cohort.ess.apple.com kt-prod.ess.apple.com Thanks. Ales Rygl

1 rok, 5 měsíců

3
4
0 0

non-persistent cache during system reboot although stored on persistent storage, why?

by Michael Grimm

Hi, I am running knot-resolver-5.7.4 in a FreeBSD service jail (14.1-STABLE). Note: Because I am still pretty new to using knot resolver, I may miss something important besides [1]. MWN> sum /usr/home/jails/test/var/run/kresd/data.mdb 268 10240 /usr/home/jails/test/var/run/kresd/data.mdb MWN> ./_STATS [2] cache('['count_entries']'): 4953 cache('['usage_percent']'): 16.953125 ### stopping jail simulates shutdown server [3]: MWN> service jail stop test Stopping jails: test. MWN> sum /usr/home/jails/test/var/run/kresd/data.mdb 268 10240 /usr/home/jails/test/var/run/kresd/data.mdb ### Thus, data.mdb is preserved after shutdown! ### starting jail simulates booting server: MWN> service jail start test Starting jails: test. MWN> sum /usr/home/jails/test/var/run/kresd/data.mdb 15059 10240 /usr/home/jails/test/var/run/kresd/data.mdb MWN> ./_STATS cache('['count_entries']'): 87 cache('['usage_percent']'): 0.15625 1) After having stopped that jail, data.mdb is still available and hasn't been modified as shown by checksum. 2) After start of the jail including start of kresd data.mdb has been modified (checksum). 3) cache.stats() shows significantly lower numbers. Questions: #) become cache.stats() reset after a reboot? #) what am I missing? Thanks in advance and regards, Michael [1] https://knot-resolver.readthedocs.io/en/stable/daemon-bindings-cache.html#p… [2] _STATS (based on https://knot-resolver.readthedocs.io/en/stable/daemon-bindings-cache.html#c…) echo -n "cache('['count_entries']'): " ; echo "cache.stats()" | nc -NU /var/run/kresd/control/kresd.sock | grep count_entries echo -n "cache('['usage_percent']'): " ; echo "cache.stats()" | nc -NU /var/run/kresd/control/kresd.sock | grep usage_percent [3] a real server reboot shows the same issue with the cache

1 rok, 6 měsíců

2
4
0 0

Moving Knot Resolver release files

by Oto Šťáva

Dear Knot Resolver users, due to an internal infrastructure change, released sources for Knot Resolver have been moved from <https://secure.nic.cz/files/knot-resolver/> to <https://knot-resolver.nic.cz/release/>. Apart from this movement, the rest of the directory structure remains unchanged. Proper redirects (HTTP 301 Moved Permanently) have been put in place to make this change as painless and transparent as possible. These redirects can be expected to stay in place for the foreseeable future. Still, we do recommend to change any of your direct links from the secure.nic.cz server to knot-resolver.nic.cz, to avoid the extra indirection step and/or unforeseen issues in the future. Should any of you run into any issues or have any questions about this change, please do let us know, we will be happy to help you out. Best regards -- Oto Šťáva | Knot Resolver team lead | CZ.NIC z.s.p.o. PGP: 6DC2 B0CB 5935 EA7A 3961 4AA7 32B2 2D20 C9B4 E680

1 rok, 6 měsíců

1
0
0 0

Expired key in upstream repositories

by Vladimír Čunát

Hello. In case you're using our upstream repositories for Debian or Ubuntu, as suggested on https://www.knot-resolver.cz/download/ you'll be running into their signing key expiring since today. As we didn't update it in time, you'll have to update it manually by re-running: wgethttps://secure.nic.cz/files/knot-resolver/knot-resolver-release.deb dpkg -i knot-resolver-release.deb Ticket: https://gitlab.nic.cz/knot/knot-resolver/-/issues/747 We also forgot to add Ubuntu 22.04, so that is fixed now, too. --Vladimir

1 rok, 6 měsíců

2
2
0 0

CNAME resolution across internal STUB zones

by Paul Furtado

Hello, I am attempting to migrate some internal bind servers to knot+knot-resolver. We have knot acting as the authoritative server for internal views of our public zones and we're attempting to use Knot Resolver to forward to Knot to provide recursive resolution on the internal network. In this configuration, when Knot is resolving a CNAME record from an internal stub zone, it doesn't chase the target of the CNAME for the client. To demonstrate, here are two example zones served by knot: # zone1.com test-a 30 IN A 192.168.1.1 # zone2.com test-cname 30 CNAME test-a.zone1.com. With these configured as stubs in Knot Resolver, if you query test-cname.zone2.com, knot resolver won't chase it across zones to get the A record value like it would for non-stub zones. Both Bind9 and Unbound chase this as expected. Is there any way to configure Knot Resolver to do the same? Thanks! - Paul

1 rok, 6 měsíců

2
2
0 0

Knot Resolver 5.7.4 and 6.0.8 (security release)

by Oto Šťáva

Dear Knot Resolver users, Knot Resolver versions 5.7.4 (stable) and 6.0.8 (early-access) have been released! Both releases include important security fixes, an update is strongly advised! Version 6.0.8 additionally brings some improvements, like faster policy reloads using a new policy-loader process, respecting system-wide crypto policies, JSON metrics, separate IPv6 and IPv4 metrics, and more. --- Knot Resolver 5.7.4: Security: - reduce buffering of transmitted data, especially TCP-based in userspace Also expose some of the new tweaks in lua: (require 'ffi').C.the_worker.engine.net.tcp.user_timeout = 1000 (require 'ffi').C.the_worker.engine.net.listen_{tcp,udp}_buflens.{snd,rcv} Improvements: - add the fresh DNSSEC root key "KSK-2024" already, Key ID 38696 (!1556) Incompatible changes: - libknot 3.0.x support is dropped (!1558) Upstream last maintained 3.0.x in spring 2022. Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.4/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.4.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.4.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v5.7.4/ --- Knot Resolver 6.0.8: Security: - reduce buffering of transmitted data, especially TCP-based in userspace Also expose some of the new tweaks in lua: (require 'ffi').C.the_worker.engine.net.tcp.user_timeout = 1000 (require 'ffi').C.the_worker.engine.net.listen_{tcp,udp}_buflens.{snd,rcv} Packaging: - all packages: - remove unused dependency on `libedit` (!1553) - deb packages: - packages ``knot-resolver-core`` and ``knot-resolver-manager`` have been merged into a single ``knot-resolver6`` package. Suffix packages ``knot-resolver-*`` have been renamed to ``knot-resolver6-*``. This change _should_ be transparent, but please do let us know if you encounter any issues while updating. (!1549) - package ``python3-prometheus-client`` is now only an optional dependency - rpm packages: - packages ``knot-resolver-core`` and ``knot-resolver-manager`` have been merged into a single ``knot-resolver`` package. This change _should_ be transparent, but please do let us know if you encounter any issues while updating. (!1549) - bugfix: do not overwrite config.yaml (!1525) - package ``python3-prometheus_client`` is now only an optional dependency - arch package: - fix after they renamed a dependency (!1536) Improvements: - TLS (DoT, DoH): respect crypto policy overrides in OS (!1526) - manager: export metrics to JSON via management HTTP API (!1527) * JSON is the new default metrics output format * the ``prometheus-client`` Python package is now an optional dependency, required only for Prometheus export to work - cache: prefetching records * predict module: prefetching expiring records moved to prefetch module * prefetch module: new module to prefetch expiring records - stats: add separate metrics for IPv6 and IPv4 (!1545) - add the fresh DNSSEC root key "KSK-2024" already, Key ID 38696 (!1556) - manager: policy-loader: new component for separate loading of policy rules (!1540) The ``policy-loader`` ensures that configured policies are loaded into the rules database where they are made available to all running kresd workers. This loading is no longer done by all kresd workers as it was before, so this should significantly improve the resolver's startup/reload time when loading large sets of policy rules, e.g. large RPZs. Incompatible changes: - cache: the ``cache.prediction`` configuration property has been reorganized into ``cache.prefetch.expiring`` and ``cache.prefetch.prediction``, changing the default behaviour as well. See the `relevant documentation section <https://www.knot-resolver.cz/documentation/v6.0.8/config-cache-predict.html>`_ for more. - libknot <=3.2.x support is dropped (!1565) Bugfixes: - arch package: fix after they renamed a dependency (!1536) - fix startup with `dnssec: false` (!1548) - rpm packages: do not overwrite config.yaml (!1525) - fix NSEC3 records missing in answer for positive wildcard expansion with the NSEC3 having over-limit iteration count (#910, !1550) - views: fix a bug in subnet matching (!1562) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.8/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.8.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.8.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.0.8/ -- Oto Šťáva | Knot Resolver team lead | CZ.NIC z.s.p.o. PGP: 6DC2 B0CB 5935 EA7A 3961 4AA7 32B2 2D20 C9B4 E680

1 rok, 7 měsíců

3
2
0 0

Re: KNOT sharing cache or not for different instances (nat64 vs no nat64)

by Vladimír Čunát

On 31/05/2024 19.00, oui.mages_0w(a)icloud.com wrote: > we have different TLS domains/certificates for dns64 and non dns64 Oh, OK. Such a thing hasn't occurred to us, so it's not possible. In that case I expect you'll need to stay on 5.x for now, with separate processes for dns64 and non-dns64 (but they can share the cache). Overall I don't think the current code can support multiple certificates.

1 rok, 8 měsíců

2
3
0 0

Re: KNOT sharing cache or not for different instances (nat64 vs no nat64)

by Vladimír Čunát

On 31/05/2024 13.04, oui.mages_0w(a)icloud.com wrote: > Unless the policy module allows to filter by listened IP, I will still > need to use split instances: we don’t select on the server side which > client is to use dns64 or not, but as an ISP, we leave the choice to > the clients to decide which dns resolver they want to use (one of ours > with or without dns64, or a third party). That is possible, but with 5.x I probably wouldn't recommend it, as it's been left out of documentation (by mistake) and overall I don't have much trust in that part of 5.x policies. But after you migrate to >= 6.x, I would recommend just having a single shared configuration. And in views you can select dst-subnet paired with dns64 options. Such deployments were taken into account when designing 6.x views. https://www.knot-resolver.cz/documentation/latest/config-views.html#config-… In 6.x it would probably also be harder for you to run multiple configurations at once on a single machine, so that's another reason to unify this when you migrate. --Vladimir

1 rok, 8 měsíců

1
0
0 0

KNOT resolver and NS serverers with CNAME

by Vladimír Čunát

On 14/05/2024 08.10, Josef Karliak via knot-dns-users wrote: > > ISC bind is strict about CNAME of NS server: > > skipping nameserver 'aa.bb.cz' *because it is a CNAME*, while > resolving '9.4/4.3.2.1.in-addr.arpa/PTR'. > > How about Knot resolver ? > Hello. I believe there is neither effort to disallow them nor to make them work. Off the top of my head I'm not sure how it will be in practice; you could just try. Either way, please don't use them. (I replied to the correct mailing-list.) --Vladimir

1 rok, 8 měsíců

3
3
0 0

Knot Resolver 5.7.3

by Oto Šťáva

Dear Knot Resolver users, Knot Resolver version 5.7.3 (stable) has been released! This maintenance update brings a minor improvement to stats and a bugfix to missing NSEC3 records. An early-access version 6.0.8 including these changes and more will come at a later date - a few more things need to be finalized there before release. Improvements: - stats: add separate metrics for IPv6 and IPv4 (!1544) Bugfixes: - fix NSEC3 records missing in answer for positive wildcard expansion with the NSEC3 having over-limit iteration count (#910, !1550) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.3/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.3.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.3.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v5.7.3/ -- Oto Šťáva | Knot Resolver team lead | CZ.NIC z.s.p.o. PGP: 6DC2 B0CB 5935 EA7A 3961 4AA7 32B2 2D20 C9B4 E680

1 rok, 9 měsíců

1
0
0 0

Re: [knot-dns-users] Re: KNOT resolver and NS serverers with CNAME

by Vladimír Čunát

On 17/05/2024 22.43, Peter Thomassen wrote: > I think the question is whether Knot Resolver follows the letter of > the RFC, like BIND, or whether it is less strict. I'm not aware of RFCs saying that resolvers should fail in such situations. My understanding is more like it's allowed not to work. Anyway, it would be better to continue this thread on knot-resolver-users(a)lists.nic.cz (I already have posted there about this a couple days ago.) --Vladimir

1 rok, 9 měsíců

1
0
0 0

Get readable text properties in request/response Lua functions

by boris.kotyrev＠gmail.com

Trying to make Policy Based Routing routing. Looking for HOWTO/snippents of two API features : 1) Tracking Cache TTL for some records and ability to make requests against cache. 2) Printing some text properties in request/response (kres) functions - like domain name, is cached (yes/no), TTL, etc. As I understood docs regarding Lua/C bindings is not finished yes. But I'm not a experienced developer so reading .c files is not an option for me ;-)

1 rok, 10 měsíců

2
1
0 0

Kresd crashes on raspberry pi

by Ulrich Wisser

Hi, for some time now I have a problem running kresd on my raspberry pi. I am running pihole and use kresd as resolver behind pihole. Everything works fine until some day where kresd "decides" to crash. It is always the same error message (please see below). I then have to manually stop the garbage collector, remove all cache files and restart kresd (which automatically starts the garbage collector). My pi is pxe boot and the root partition is on an nfs mounted volume. The volume has several terra byte of space left. After a restart it will run flawless for tow or three weeks just to crash with the same error again. Any idea how this happens? /Ulrich root@pi-hole1:~# systemctl status kresd ● kresd.service - Knot Resolver daemon Loaded: loaded (/lib/systemd/system/kresd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2024-04-05 02:31:47 CEST; 6h ago Docs: man:kresd.systemd(7) man:kresd(8) Process: 5106 ExecStart=/usr/sbin/kresd -c /usr/lib/arm-linux-gnueabihf/knot-resolver/distro-preconfig.lua -c /etc/knot-resolver/kresd.conf -n (code=exited, status=1/FAILURE) Process: 5110 ExecStopPost=/usr/bin/env rm -f /run/knot-resolver/control/ (code=exited, status=1/FAILURE) Main PID: 5106 (code=exited, status=1/FAILURE) CPU: 648ms Apr 05 02:31:45 pi-hole1 kresd[5106]: [C]: at 0x0001b2d8 Apr 05 02:31:45 pi-hole1 kresd[5106]: [C]: in function 'pcall' Apr 05 02:31:45 pi-hole1 kresd[5106]: ...b/arm-linux-gnueabihf/knot-resolver/distro-preconfig.lua:9: in main chunk Apr 05 02:31:45 pi-hole1 kresd[5106]: ERROR: net.listen() failed to bind Apr 05 02:31:46 pi-hole1 kresd[5106]: [system] error while loading config: /usr/lib/arm-linux-gnueabihf/knot-resolver/sandbox.lua:402: 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') Apr 05 02:31:47 pi-hole1 systemd[1]: kresd.service: Main process exited, code=exited, status=1/FAILURE Apr 05 02:31:47 pi-hole1 env[5110]: rm: cannot remove '/run/knot-resolver/control/': Is a directory Apr 05 02:31:47 pi-hole1 systemd[1]: kresd.service: Control process exited, code=exited, status=1/FAILURE Apr 05 02:31:47 pi-hole1 systemd[1]: kresd.service: Failed with result 'exit-code'. Apr 05 02:31:47 pi-hole1 systemd[1]: Failed to start Knot Resolver daemon. root@pi-hole1:~# ps aux Op | grep kres knot-re+ 569 0.1 0.1 114480 4140 ? Ss Apr02 5:15 /usr/sbin/kres-cache-gc -c /var/cache/knot-resolver -d 1000 root 23835 0.0 0.0 10292 504 pts/0 S+ 09:00 0:00 grep kres root@pi-hole1:~# systemctl status | grep kres │ └─23861 grep kres ├─system-kresd.slice │ └─kres-cache-gc.service │ └─569 /usr/sbin/kres-cache-gc -c /var/cache/knot-resolver -d 1000 root@pi-hole1:~# systemctl stop kres-cache-gc

1 rok, 10 měsíců

2
2
0 0

Knot Resolver 5.7.2 and 6.0.7

by Oto Šťáva

Dear Knot Resolver users, Knot Resolver versions 5.7.2 (stable) and 6.0.7 (early-access) have been released! Both fix running on 32-bit systems with 64-bit time; 6.0.7 additionally brings fixes to RPZ, cache clearing via kresctl, and more. --- Knot Resolver 5.7.2: Bugfixes: - fix on 32-bit systems with 64-bit time_t (!1510) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.2/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.2.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.2.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/artifacts/1056229/index.html --- Knot Resolver 6.0.7: Improvements: - manager: clear the cache via management HTTP API (#876, !1491) - manager: added support for Python 3.12 and removed for 3.7 (!1502) - manager: use build-time install prefix to execute `kresd` instead of PATH (!1511) - docs: documentation is now separated into user and developer parts (!1514) - daemon: ignore UDP requests from ports < 1024 (!1507) - manager: increase startup timeout for processes (!1518, !1520) - local-data: increase default DB size to 2G on 64-bit platforms (!1518) Bugfixes: - fix listening by interface name containing dashes (#900, !1500) - fix kresctl http request timeout (!1505) - fix RPZ if it contains apex NS record (!1516) - fix RPZ if SOA is repated, as usual in AXFR output (!1521) - avoid RPZ overriding the root SOA (!1521) - fix on 32-bit systems with 64-bit time_t (!1510) - fix paths to knot-dns libs if exec_prefix != prefix (!1503) - manager: add missing early check that neither a custom port nor TLS is set for authoritative server forwarding (#902, !1505) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.7/NEWS Documentation: https://www.knot-resolver.cz/documentation/artifacts/1056245/index.html -- Oto Šťáva | Knot Resolver team leader | CZ.NIC z.s.p.o. PGP: 6DC2 B0CB 5935 EA7A 3961 4AA7 32B2 2D20 C9B4 E680

1 rok, 11 měsíců

1
0
0 0

Newbie questions regarding knot-resolver

by Michael Grimm

Hi, I am in the process to migrate from unbound to knot-resolver. This is on FreeBSD 14-STABLE, knot-resolver 5.7.1, and on a very small instance serving a handful users, around 100 mails a day and such. The resolver is up and running, but I still have some questions left I cannot answer myself after reading the documentation et al. 1) I managed to run 'kres-cache-gc -c /var/run/kresd' but I am unsure whether I do need the garbage collector at all? I read that after filling up of '/var/run/kresd/data.mdb' that file would become reset to 0 bytes, correct? FYI: After 3 days '/var/run/kresd/data.mdb' uses less than 1 MB currently. 2) Does knot-resolver automatically update 'root.hints' and 'root.keys', or do I have to install a script in crontab doing the updates instead? FYI: I didn't unload the modules 'ta_signal_query' and 'ta_sentinel‘ 3) I am still struggeling to understand, how to get access to the statistics produced by the module 'stats'? FYI: If I do try to use knotc (I know, it's experimental), I'll get: |dns> kresc /var/run/kresd/control/17158 |Warning! kresc is highly experimental, use at own risk. |Please tell authors what features you expect from client utility. | FYI: There is no 'kresd>' prompt … I tried to modify that socket's privileges but to no avail. 4) If that socket is the way to get hold on all statistics information, how can one name that socket file? Currently, it is just the PID of kresd. Thanks in advance and regards, Michael

1 rok, 11 měsíců

3
7
0 0

DNS Shotgun v20240219

by Oto Šťáva

Dear Knot Resolver users, DNS Shotgun v20240219, our high-performance realistic benchmarking tool for DNS resolvers, has been released. This new release, amongst a variety of other improvements, brings support for testing DNS-over-QUIC. Incompatible changes: - CMake is now being used to build dnssim instead of Autotools - GnuTLS 3.7.5+ is now required Improvements: - pcap/extract-clients: always reset UDP port numbers to 53 (!56) - pcap/extract-clients: ability to write to stdout (!62) - pcap/filter-dnsq: skip 'special' queries for *.dotnxdomain.net (!58) - pcap/split-clients: new tool to split larger PCAPs into smaller ones (!61) - pcap/merge-chunks: allow disabling randomization (!67) - tools/plot-latency: ability to diversify lines with linestyles (!69) - tools/plot-response-rate: estimate worst-case drop caused by discarded packets (!74) - tools/plot-packet-rate: handle incomplete last sampling period (!71) - tools/plot-response-rate: ability to ignore RCODEs with small response rate (!73) - pcap/filter-dnsq: ability to log malformed queries (!72) - pcap/generate-const-qps: new tool to generate constant QPS (!33) - tools: allow customizing plot charts with `SHOTGUN_MPLSTYLES` (!65) - replay: `--preload` argument, mainly for dnssim debugging with sanitizers (!76) - tools/plot-latency: use fractional values for humans in charts (!78) - pcap/extract-clients: warn if some input packets were skipped (!80) - dnssim: replace Autotools with CMake (!77, !86) - configs: DoH configs with exclusively GET/POST methods (!82) - tools/plot-response-rate: avoid division by zero (!89) - tools/plot-latency: denser labels to improve logarithmic scale readability (!90) - pcap/extract-clients: allow query rewriting - anonymization (!91) - Support for DNS-over-QUIC (!75) Bugfixes: - tools/plot-response-rate: avoid white lines on white background (!55) - tools/plot-client-distribution: properly handle file limit (!59) - pcap: proper PCAP write error handling (!60) - tools/plot-connections: set axis limits properly (!66) - tools/plot-packet-rate: trim chart whitespace (!79) - replay: do not exit silently when dnssim returns non-zero (!87) Full changelog: https://gitlab.nic.cz/knot/shotgun/-/releases/v20240219 Sources: https://gitlab.nic.cz/knot/shotgun/-/archive/v20240219/shotgun-v20240219.ta… Documentation: https://dns-shotgun.readthedocs.io/en/v20240219/ Oto Šťáva Knot Resolver CZ.NIC z.s.p.o.

2 roky

1
0
0 0

Why are some names not cached?

by Ondřej Caletka

Hello, I am trying to figure out why some domain names are not resolving on my instance of Knot resolver over DoH with some clients. I was able to reproduce this issue with [doh](https://github.com/curl/doh) client built on libcurl. The problem never manifests with kdig (neither with DoH, nor DoT nor Do53). During this, I noticed something strange. For domain name github.com (which sometimes returns no A record), I always receive an answer with TTL set to 60. It seems like this name does not get cached at all. See the test output below. Interestingly, if I delete cache files and restart the resolver, the TTL starts decreasing as expected. Is this a sign that something was wrong with the cache before? Or is this some sort of cache optimization for low TTL records? Here is the test output: $ for i in `seq 1 5`; do ./doh github.com https://nscache.mtg.ripe.net/dns-query ; echo "----"; kdig +https +noadflag +nocookie +noall +answer github.com A @nscache.mtg.ripe.net ; echo "===="; sleep 1; done [github.com] TTL: 60 seconds AAAA: 0064:ff9b:0000:0000:0000:0000:8c52:7903 ---- github.com. 60 IN A 140.82.121.3 ==== [github.com] TTL: 60 seconds A: 140.82.121.3 AAAA: 0064:ff9b:0000:0000:0000:0000:8c52:7904 ---- github.com. 60 IN A 140.82.121.4 ==== [github.com] TTL: 60 seconds A: 140.82.121.4 AAAA: 0064:ff9b:0000:0000:0000:0000:8c52:7904 ---- github.com. 60 IN A 140.82.121.4 ==== [github.com] TTL: 60 seconds A: 140.82.121.4 AAAA: 0064:ff9b:0000:0000:0000:0000:8c52:7903 ---- github.com. 60 IN A 140.82.121.4 ==== [github.com] TTL: 60 seconds A: 140.82.121.3 AAAA: 0064:ff9b:0000:0000:0000:0000:8c52:7904 ---- github.com. 60 IN A 140.82.121.3 ==== -- Best regards, Ondřej Caletka

2 roky

2
1
0 0

LIGA CHAMPIONS

by sachgame570＠gmail.com

Komentator -Liga Champions✔️✔️ Owen Hargreaves mengatakan bahwa “semua orang akan terpukul” oleh penampilan buruk Bayern Munich baru-baru ini, kali ini setelah kalah dari Lazio di leg pertama babak 16 besar Liga Champions. Situs web: https://svipbola.com/liga/liga-champions Pertandingan Liga Champions“Mereka perlu menemukan cara untuk mempercepat permainan dan menjadi sedikit lebih cepat. Mereka melewati fase ini di bawah asuhan Pep dan memainkan sepakbola terindah. Hari ini mereka bahkan tidak memainkan sepakbola indah.” Jadwal Liga Champions - dengan meningkatnya perhatian media terhadap manajer dan pemain, mantan gelandang Manchester United dan pemenang Liga Champions Hargreaves tidak berharap tim tamu mendapat ulasan positif atas penampilan seperti itu. Liga Champions 2023⭐“Ketika Anda bermain untuk tim papan atas, saya tahu orang-orang tidak ingin mendengarnya, namun ketika Anda bermain seperti itu, Anda akan dikritik. Saya pikir akan ada banyak rasa frustrasi di dalam dan di sekitar Bayern saat ini.” Address: Jl Gondosuli 8 Yk Jawa Tengah Indonesia #Liga Champions #pertandingan liga champions #jadwal liga champions #klasemen liga champions #liga champions uefa #liga champions 2023 #hasil liga champions #liga champions 2022

2 roky

1
0
0 0

Unable to install kdig utility in Linux fedora 8.8

by Ramakrishnudu MANGALA

Hi Team, I am trying to install kdig utility in Linux fedora 8.8 but not successful. I took the reference from https://www.knot-resolver.cz/download/ Tried below: # yum install -y epel-release Oracle Linux 8 BaseOS Latest (x86_64) 4.7 kB/s | 3.6 kB 00:00 Oracle Linux 8 Application Stream (x86_64) 9.8 kB/s | 3.9 kB 00:00 Oracle Linux 8 CodeReady Builder (x86_64) - Unsupported 3.7 kB/s | 3.3 kB 00:00 ITE 20 kB/s | 1.4 kB 00:00 Package oracle-epel-release-el8-1.0-5.el8.x86_64 is already installed. Dependencies resolved. Nothing to do. Complete! # yum install -y knot-resolver Oracle Linux 8 BaseOS Latest (x86_64) 1.1 kB/s | 3.6 kB 00:03 Oracle Linux 8 Application Stream (x86_64) 10 kB/s | 3.9 kB 00:00 Oracle Linux 8 CodeReady Builder (x86_64) - Unsupported 8.3 kB/s | 3.3 kB 00:00 ITE 22 kB/s | 1.4 kB 00:00 No match for argument: knot-resolver Error: Unable to find a match: knot-resolver # dnf install -y knot-resolver Oracle Linux 8 BaseOS Latest (x86_64) 2.4 kB/s | 3.6 kB 00:01 Oracle Linux 8 BaseOS Latest (x86_64) 15 MB/s | 62 MB 00:04 Oracle Linux 8 Application Stream (x86_64) 10 kB/s | 3.9 kB 00:00 Oracle Linux 8 Application Stream (x86_64) 11 MB/s | 48 MB 00:04 Oracle Linux 8 CodeReady Builder (x86_64) - Unsupported 2.2 kB/s | 3.3 kB 00:01 Oracle Linux 8 CodeReady Builder (x86_64) - Unsupported 4.5 MB/s | 8.6 MB 00:01 ITE 1.1 kB/s | 1.4 kB 00:01 No match for argument: knot-resolver Error: Unable to find a match: knot-resolver But none of the above is successful. Could you help me with kdig utility installation on Fedora 8.8? Regards, Rama.

2 roky

2
1
0 0

Knot Resolver 5.7.1 and 6.0.6

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver versions 5.7.1 (stable) and 6.0.6 (early-access) have been released! These releases include important security fixes, an update is strongly advised! Security: - CVE-2023-50868: NSEC3 closest encloser proof can exhaust CPU * validator: lower the NSEC3 iteration limit (150 -> 50) * validator: similarly also limit excessive NSEC3 salt length * cache: limit the amount of work on SHA1 in NSEC3 aggressive cache * validator: limit the amount of work on SHA1 in NSEC3 proofs * validator: refuse to validate answers with more than 8 NSEC3 records - CVE-2023-50387 "KeyTrap": DNSSEC verification complexity could be exploited to exhaust CPU resources and stall DNS resolvers. Solution boils down mainly to limiting crypto-validations per packet. We would like to thank Elias Heftrig, Haya Schulmann, Niklas Vogel and Michael Waidner from the German National Research Center for Applied Cybersecurity ATHENE for bringing this vulnerability to our attention. Improvements: - update addresses of B.root-servers.net (!1478) Bugfixes: - fix potential SERVFAIL deadlocks if net.ipv6 = false (#880) The update affects how some cached records are being treated, which may trip up some sanity checking mechanisms in Knot Resolver if you have advanced debugging options enabled (disabled by default), "debugging.assertion_abort" for version 5 (Lua) and "logging/debugging/assertation-abort" for version 6 (YAML). In case you encounter any issues, please try clearing the cache first. Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.7.1/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

2 roky

1
0
0 0

Lost e-mails to the mailing list + upcoming security release today

by Oto Šťáva

Dear Knot Resolver users, last week a long-lasting bug in our mailing system has been discovered, which, over the past two years, blocked quite a few e-mails from being delivered to the list <knot-resolver-users(a)lists.nic.cz> and a few others (namely the <knot-dns-users(a)lists.nic.cz>, whose subscriber Juha Suhonen initially brought our attention to the issue - a thank you to Juha is in order!). This week the issue has been resolved and the blocked e-mails came through. Some of these were our own, namely the Knot Resolver 5.5.0 release announcement, which is obviously outdated, as the current stable version is Knot Resolver 5.7.0. We apologize for any confusion this situation may have caused. Some others are still awaiting additional approval, so after we manually identify, which are still relevant, and which are spam, they will also come through during the following weeks. Furthermore, later today we are planning to release new versions of the stable Knot Resolver 5 and the early-access Knot Resolver 6. These important updates will mitigate a few newfound DoS issues, the details of which will soon be revealed globally. We are fully aware that this unfortunate timing may cause further confusion, so we opted to inform you, the subscribers, beforehand, that this next release e-mail is indeed relevant. We once again apologize for the confusion. Best regards Oto Šťáva Knot Resolver team CZ.NIC z.s.p.o.

2 roky

1
0
0 0

[SOLVED] Re: [knot-dns-users] Re: kresd not starting with lua error

by Mike Wright

On 2/12/24 01:34, Vladimír Čunát wrote: > On 28/01/2024 02.52, Mike Wright wrote: >> [system] error while loading config: >> ...b/x86_64-linux-gnu/knot-resolver/kres_modules/policy.lua:378: bad >> argument #1 to 'create' (table expected, got nil) (workdir >> '/var/lib/knot-resolver') > > You don't define the `internalDomain` variable. That's correct in lua > and evaluates as nil. > > (and as I already posted, please use the correct mailing-list next time) OK, figured out my mistake. internalDomains MUST APPEAR BEFORE any reference to it. Thanks for your time, Mike Wright

2 roky

1
0
0 0

Introducing Knot Resolver 6.x

by Aleš Mrázek

Dear Knot Resolver users, we would like to introduce you to Knot Resolver 6.x! This future version of the resolver is now in the testing phase. An article was published on our blog as part of this introduction. EN: https://en.blog.nic.cz/2023/12/15/knot-resolver-6-x-news CZ: https://blog.nic.cz/2023/12/15/novinky-v-knot-resolver-6-x We will be happy if you try the new version and give us any feedback. -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

2 roky, 2 měsíce

1
0
0 0

Knot Resolver error

by martin.skalicky＠outlook.cz

Hi! I'm pretty new to Knot Resolver, previously i used Bind9 but wanted to try something else. However, i can't really figure out one problem, error: [system] error while loading config: /usr/lib/knot-resolver/kres_modules/policy.lua:43: bad argument #1 to 'kr_straddr_split' (cannot convert 'table' to 'const char *') (workdir '/var/lib/knot-resolver') I don't absolutely know, what am I doing wrong. Can you help me, please? Also, possible communication in Czech if better for someone? Here is my kresd.conf (my actual domains are replaced by domain1.tld, domain2.tld respectively): -- SPDX-License-Identifier: CC0-1.0 -- vim:syntax=lua:set ts=4 sw=4: -- Refer to manual: https://knot-resolver.readthedocs.org/en/stable/ -- Network interface configuration net.listen('127.0.0.1', 53, { kind = 'dns' }) net.listen('127.0.0.1', 853, { kind = 'tls' }) net.listen('::1', 53, { kind = 'dns', freebind = true }) net.listen('::1', 853, { kind = 'tls', freebind = true }) -- Load useful modules modules = { 'hints > iterate', -- Allow loading /etc/hosts or custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- Cache size cache.size = 100 * MB -- DNS Rebinding Configuration policy.add(policy.todnames({'domain2.tld', 'domain1.tld'}), policy.PASS) policy.add(policy.todnames({'domain2.tld', 'domain1.tld'}), policy.FORWARD({{'192.168.0.126'}}))

2 roky, 2 měsíce

3
3
0 0

Problems with DNSSEC .CZ

by Martin Doubrava

Hi colleagues, we are using knot-resolver as anycast resolvers for our region wide network. Everything works fine, but from saturday we are experiencing problems with zone .cz on one of our resolvers: lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [plan ][00000.00] plan 'www.seznam.cz.' type 'AAAA' uid [20220.00] lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [iterat][20220.00] 'www.seznam.cz.' type 'AAAA' new uid was assigned .01, parent uid .00 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => skipping exact RR: rank 060 (min. 030), new TTL -16225 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => trying zone: seznam.cz., NSEC3, hash db928b48 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 depth 1: hash 0sil3tll31qpi1iq50o2h3kjrmon169q lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 encloser error for www.seznam.cz.: range search found stale or insecure entry lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 depth 0: hash lg5rgspgqdoqqjko0u7fkpkakk8hgc1s lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 encloser error for seznam.cz.: range search found stale or insecure entry lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => trying zone: seznam.cz., NSEC3, hash f8ba757c lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 depth 1: hash s92e2vuk6k14pvqp4ubga1im9kpgff8a lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 encloser error for www.seznam.cz.: range search found stale or insecure entry lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 depth 0: hash 07u4nbhjigung96jklsqvtf6crqjojp8 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 encloser error for seznam.cz.: range search found stale or insecure entry lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [zoncut][20220.01] found cut: cz. (rank 002 return codes: DS 0, DNSKEY -116) lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [plan ][20220.01] plan 'cz.' type 'DNSKEY' uid [20220.02] lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [iterat][20220.02] 'cz.' type 'DNSKEY' new uid was assigned .03, parent uid .01 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.03] => skipping exact RR: rank 060 (min. 030), new TTL -14979 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.03] => trying zone: cz., NSEC3, hash 20b5ab23 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.03] => NSEC3 depth 0: hash gurgi3ems8m3ts3pvppubu3hhqkivt3l lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.03] => NSEC3 encloser error for cz.: range search found stale or insecure entry lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.03] => skipping zone: cz., NSEC, hash 0;new TTL -123456789, ret -2 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [select][20220.03] => id: '03706' choosing from addresses: 0 v4 + 0 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is OK lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [select][20220.03] => id: '03706' no suitable transport, zone cut: 'cz.' lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [iterat][20220.03] 'cz.' type 'DNSKEY' new uid was assigned .04, parent uid .01 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [select][20220.04] => id: '28359' choosing from addresses: 0 v4 + 0 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is OK lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [select][20220.04] => id: '28359' no suitable transport, zone cut: 'cz.' lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [resolv][20220.04] AD: request NOT classified as SECURE lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [resolv][20220.01] finished in state: 8, queries: 1, mempool: 16400 B Version of knot-resolver: 5.7.0-cznic.1 When i turn off DNSSEC with trust_anchors.remove('.') and then turn it on everything works, but only for day or so. Other machines are working seamlessly. What we are doing here wrong? Thank you! -- Best regards Bc. Martin Doubrava CEO _______________________________ DOUBRAVA.NET s.r.o. Náklo 178, 783 32 Náklo Mobil: +420 771 280 361 Technická podpora: +420 776 778 173 Office: +420 588 884 000 E-mail: martin(a)doubrava.net WWW: http://www.doubrava.net Najdete nás i na facebooku: http://www.facebook.com/doubravanet

2 roky, 2 měsíce

2
3
0 0

Accessing DoH headers in Lua

by Blažej Krajňák

Hi there, please, can anyone move me forward? I want to implement new stats counter for DoH requests with “Chrome” in "user-agent" header. I don’t know how to iterate “query.request.qsource.headers”. I have tried: function count_chrome_doh() return function (state, query) if query.request.qsource.flags.http then for k, v in ipairs(query.request.qsource.headers) do if v.name == 'user-agent' and v.value == 'Chrome' then if stats.get('request.agent.chrome') then stats['request.agent.chrome'] = stats.get('request.agent.chrome') + 1 else stats['request.agent.chrome'] = 1 end return nil end end end return nil end end policy.add(count_chrome_doh()) but it falls with error "'struct 322' has no '__ipairs’ metamethod” Thanks! Blažej

2 roky, 5 měsíců

2
3
0 0

Best way to implement kresd to filter by listening interface

by oui.mages_0w＠icloud.com

Hello, What would be the best way to implement the following with kresd? The device used has a 2 core cpu. It has 3 (listening) ip addresses, for example: 10.2.3.4, 2001:0DB8:123::1 and 2001:0DB8:123::64 I want to have kresd to listen to: – 10.2.3.4 and 2001:0DB8:123::1 and do a dns resolution using UDP (53), TLS and HTTPS (the question is not about these settings). – 2001:0DB8:123::64 and use the same settings as above, but adding the dns64 module and resolution (only for requests made to 2001:0DB8:123::64). Having 2 cores, I have 2 identical instances; should I differentiate them and have one for dns64 and one without? or could I have 2 identical instances with a shared configuration file allowing to use dns64 or not depending on the listening ip? Or 4 instances (2 identical for dns64, 2 identical without, to have a spare of each config)? The options with view: are good to filter or do actions depending on the source ip, the queried domain or even the resolved ip (destination), but nothing about the ip used to reach the resolver (the listening address). Thank you.

2 roky, 5 měsíců

1
0
0 0

Accessing DoH headers in Lua

by Blažej Krajňák

Hi there, please, can anyone move me forward? I want to implement new stats counter for DoH requests with “Chrome” in "user-agent" header. I don’t know how to iterate “query.request.qsource.headers”. I have tried: function count_chrome_doh() return function (state, query) if query.request.qsource.flags.http then for k, v in ipairs(query.request.qsource.headers) do if v.name == 'user-agent' and v.value == 'Chrome' then if stats.get('request.agent.chrome') then stats['request.agent.chrome'] = stats.get('request.agent.chrome') + 1 else stats['request.agent.chrome'] = 1 end return nil end end end return nil end end policy.add(count_chrome_doh()) but it falls with error "'struct 322' has no '__ipairs’ metamethod” Thanks! Blažej

2 roky, 5 měsíců

1
0
0 0

Knot Resolver 5.7.0

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.7.0 has been released! Security - avoid excessive TCP reconnections in a few more cases Like before, the remote server had to behave nonsensically in order to inflict this upon itself, but it might be abusable for DoS. We thank Ivan Jedek from OryxLabs for reporting this. Improvements - forwarding mode: tweak dealing with failures from forwarders, in particular prefer sending CD=0 upstream (!1392) Bugfixes - fix unusual timestamp format in debug dumps of records (!1386) - adjust linker options; it should help less common platforms (!1384) - hints module: fix names inside home.arpa. (!1406) - EDNS padding (RFC 8467) compatibility with knot-dns 3.3 libs (!1422) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.7.0/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

2 roky, 6 měsíců

1
0
0 0

PID file path

by snowmailer＠gmail.com

Is there any way to write PID file to /var/run or so with knot-resolver? I can't find any info in documentation about it.

2 roky, 7 měsíců

2
1
0 0

Knot Resolver - redirect wildcard domain

by Milan Jeskynka Kazatel

Hello, could you please help me with knot resolver configuration in the case when I need to redirect each variation for the domain to some address. e.g. www.example.com, m.example.com, domain.example.com ... like wildcard record *.example.com 10.0.0.50 In my configuration is it handeled by file with static records -- load static records hints.add_hosts('/etc/knot-resolver/static_records.txt') which contains address to be redirected and the domain. 10.0.0.50 1xbet.com 10.0.0.50 thelotter.com 10.0.0.50 webmoneycasino.com 10.0.0.50 betworld.com 10.0.0.50 bosscasino.eu 10.0.0.50 sportingbull.com But I´m not able to handle the correct syntax for a wildcard domain redirection. Best regards, -- Smil Milan Jeskyňka Kazatel

2 roky, 7 měsíců

3
7
0 0

Setting up to use the OpenNIC root zone

by Ed V.

Hoping someone can help... Built Knot Resolver v5.6.0 from source. It works and resolves correctly for "regular" TLDs. However, I would like to point it to OpenNIC for resolution /forwarding so that I can resolve the expanded /alternative TLDs. Default configuration with: policy.add(policy.all( policy.FORWARD( {'2001:19f0:b001:379:5400:3ff:fe68:1cc6', '138.197.140.189', '2600:3c04::f03c:93ff:febd:be27', '45.61.49.203'}))) and it fails to find "grep.geek" using the standard root zone /hints: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22871 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;grep.geek. IN A ;; AUTHORITY SECTION: . 86077 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2023050902 1800 900 604800 86400 So I checked the Documentation site and found "hints.root" which theoretically will override any other root hints. Using the OpenNIC root zone file (downloads as "db.root") I set: hints.root ({ ['ns13.opennic.glue.'] = { '2a01:4f8:192:43a5::2', '144.76.103.143' } }) in kresd.conf. Still no joy - "grep.geek" is NXDOMAIN from a.root-servers.net again. Any thoughts? Things I might have missed along the way?

2 roky, 9 měsíců

3
5
0 0

DoH connection closed after 10 seconds

by Blažej Krajňák

Hello, it's me again :) I just want to make sure if behaviour of Knot Resolver is correct. I implemented DDR mechanism to discover DoH / DoT DNS servers. My Macbook with Ventura successfully discovered DoH server and started to use it. But: Knot Resolver sends 10 seconds after establishing FIN,ACK packet and connection is correctly closed. From this moment, Macbook starts to use DNS over UDP again and will retry DoH connection after 10-30s later. Then it uses DoH server again for 10 seconds .... Is this behaviour correct? Should Macbook sends some keepalive messages to prevent connection closing? Or should Macbook reopen DoH connection more quickly? Thanks, Blažej

2 roky, 12 měsíců

2
3
0 0

Policy based on destination IP

by Blažej Krajňák

Hello, is there any correct way how to do query policy based on destination IP (IP which processed the query)? Like view:addr but on the dst address. I found that function view.addr(_, subnet, rules, dst) contains DST parameter but I'm not sure how to use it. I also found function view.rule_dst(action, subnet) but still get errors: error: /usr/lib/knot-resolver/kres_modules/view.lua:103: attempt to index local 'req' (a number value) Thanks Blažej

3 roky

2
3
0 0

Implementing DDR SVCB record

by Blažej Krajňák

Hi there, I'm trying to implement SVCB record "_dns.resolver.arpa" for DDR mechanism for our AS50242 recursive resolvers. When I look on Cloudflare or Google implementation, they answer with "ADDITIONAL SECTION" also. kdig _dns.resolver.arpa @8.8.8.8 type64 ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 61402 ;; Flags: qr aa rd ra; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 4 ;; QUESTION SECTION: ;; _dns.resolver.arpa. IN SVCB ;; ANSWER SECTION: _dns.resolver.arpa. 86400 IN SVCB 1 dns.google. alpn=dot _dns.resolver.arpa. 86400 IN SVCB 2 dns.google. alpn=h2,h3 key7="/dns-query{?dns}" ;; ADDITIONAL SECTION: dns.google. 86400 IN A 8.8.8.8 dns.google. 86400 IN A 8.8.4.4 dns.google. 86400 IN AAAA 2001:4860:4860::8888 dns.google. 86400 IN AAAA 2001:4860:4860::8844 In Knot Resolver documentation is an example how to answer for SVCB request but without addition section. policy.add( policy.domains( policy.ANSWER( { [kres.type.SVCB] = { rdata=kres.parse_rdata({ 'SVCB 1 resolver.example. alpn=dot ipv4hint=192.0.2.1 ipv6hint=2001:db8::1', 'SVCB 2 resolver.example. mandatory=key65380 alpn=h2 key65380=/dns-query{?dns}', }), ttl=5 } } ), { todname('_testing.domain') })) Can anyone help me, how to add additional section to answer? Do we need to use policy.custom_action(state, request)? Thanks! Blažej

3 roky

3
5
0 0

Knot Resolver 5.6.0

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.6.0 has been released! Security - avoid excessive TCP reconnections in some cases (!1380) For example, a DNS server that just closes connections without answer could cause lots of work for the resolver (and itself, too). The number of connections could be up to around 100 per client's query. We thank Xiang Li from NISL Lab, Tsinghua University, and Xuesong Bai and Qifan Zhang from DSP Lab, UCI. Improvements - daemon: feed server selection with more kinds of bad-answer events (!1380) - cache.max_ttl(): lower the default from six days to one day and apply both limits to the first uncached answer already (!1323 #127) - depend on jemalloc, preferably, to improve memory usage (!1353) - no longer accept DNS messages with trailing data (!1365) - policy.STUB: avoid applying aggressive DNSSEC denial proofs (!1364) - policy.STUB: avoid copying +dnssec flag from client to upstream (!1364) Bugfixes - policy.DEBUG_IF: don't print client's packet unconditionally (!1366) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.6.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.6.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.6.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.6.0/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

3 roky

1
0
0 0

Knot Resolver 5.5.3

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.5.3 has been released! Security - fix CPU-expensive DoS by malicious domains - CVE-2022-40188 Improvements - fix config_tests on macOS (both HW variants) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.5.3/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.3.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.3.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.5.3/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

3 roky, 5 měsíců

1
0
0 0

Resolving problem connectivity.samsung.com.cn even on dual-stack

by Blažej Krajňák

Hello everyone, at AS50242 we experience problem with resolving connectivity.samsung.com.cn We run two servers, each with 4 instances. Both servers have working dual-stack (v4/v6). knot-dnsutils/unknown,now 3.1.1-cznic.1 amd64 [installed] knot-resolver-module-http/unknown,now 5.5.0-cznic.1 all [installed,automatic] knot-resolver-release/unknown,now 1.9-1 all [installed] knot-resolver/unknown,now 5.5.0-cznic.1 amd64 [installed] Dnsviz shows problem reaching few IPv6 servers of .cn TLD via UDP. I can not understand, why both of our servers response with SERVFAIL. Any ideas how to troubleshoot more? Thank you, Blažej

3 roky, 5 měsíců

3
7
0 0

not resolving CNAME

by Mike Wright

Hello, I am a user, not a developer, of knot-resolver, on ubuntu groovy. When I look up something that has a CNAME and ask for an A record I get a SERVFAIL. If I ask for the CNAME I get the correct answer but then I have to do another search for the A record for that. #------------- # using knot-resolver kdig @127.0.53.1 www.cdc.gov. ;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 44868 #------------- # using google dns kdig 8.8.8.8 www.cdc.gov. www.cdc.gov. 126 IN CNAME www.akam.cdc.gov. www.akam.cdc.gov. 20 IN A 104.100.61.241 #------------- My guess is I don't have a complete configuration. Here's my very simple knot-resolver.conf #------------ -- SPDX-License-Identifier: CC0-1.0 -- Network interface configuration net.listen('127.0.53.1') -- Load useful modules modules = { 'hints > iterate', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- Cache size cache.size = 100 * MB -- -- MY STUFF -- internalDomains = policy.todnames({ 'main', '0.1.10.in-addr.arpa', '1.10.in-addr.arpa', '10.in-addr.arpa' }) policy.add(policy.suffix(policy.FLAGS({'NO_CACHE'}), internalDomains)) policy.add(policy.suffix(policy.STUB({'127.53.0.1'}), internalDomains)) #------------- How do I fix this? Thank you, Mike Wright

3 roky, 5 měsíců

2
2
0 0

When knot delete old ksk key ?

by support＠profiwh.eu

Hello, I have problem with ksk rotation keys. I've rotated shared KEY, submit by hand and rotate the key. I did setting of delete-delay, but after reaching time nothing happends. keymgr profivh.cz list 4a32ef440c27342c1aca748e0ff3236c41c9dff0 ksk=yes zsk=no tag=11739 algorithm=13 size=256 public-only=no pre-active=0 publish=1660242640 ready=1660246540 active=1660587842 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 55c0eb5bbc46ffc5b0355311384e32957f369bf3 ksk=no zsk=yes tag=51831 algorithm=13 size=256 public-only=no pre-active=0 publish=1659353890 ready=0 active=1659357790 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 a85ffe2752572a3e057c1dca6f1173e2d4f4a6b7 ksk=yes zsk=no tag=14655 algorithm=13 size=256 public-only=no pre-active=0 publish=1641666021 ready=1641666021 active=1655760727 retire-active=1660587842 retire=0 post-active=0 revoke=0 remove=1660587842 but time is over and knot didnt remove the key, list at current time : date +%s 1660838273 with policy setting : policy: - id: "signing_policy_prod" manual: "off" single-type-signing: "off" algorithm: "ecdsap256sha256" ksk-size: "256" zsk-size: "256" ksk-shared: "on" dnskey-ttl: "7200" ksk-lifetime: "0" zsk-lifetime: "2592000" delete-delay: "86400" propagation-delay: "14400" rrsig-lifetime: "1209600" rrsig-refresh: "604800" rrsig-pre-refresh: "3600" nsec3: "on" cds-cdnskey-publish: "none" with template : - id: "signed-zones" storage: "/var/lib/knot/szones" file: "%s" notify: [ "XXX.XXX.cz", "XXX.XXX.cz" ] acl: [ "sec1-transfer", "sec2-transfer" ] zonefile-sync: "0" zonefile-load: "whole" journal-content: "changes" dnssec-signing: "on" dnssec-policy: "signing_policy_prod" serial-policy: "unixtime" it is any normal behavior or is something wrong ? knotc (Knot DNS), version 3.1.9 Thanks for help.

3 roky, 6 měsíců

2
2
0 0

Knot Resolver 5.5.1

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.5.1 has been released! Improvements - daemon/tls: disable TLS resumption via tickets for TLS <= 1.2 (#742, !1295) - daemon/http: DoH now responds with proper HTTP codes (#728, !1279) - renumber module: allow rewriting subnet to a single IP (!1302) - renumber module: allow arbitrary netmask (!1306) - nameserver selection algorithm: improve IPv6 avoidance if broken (!1298) Bugfixes - modules/dns64: fix incorrect packet writes for cached packets (#727, !1275) - xdp: make it work also with libknot 3.1 (#735, !1276) - prefill module: fix lockup when starting multiple idle instances (!1285) - validator: fix some failing negative NSEC proofs (!1294, #738, #443) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.5.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.5.1/ Donation: https://donations.nic.cz/en/donate/?project=knot-resolver -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

3 roky, 6 měsíců

1
1
0 0

new user - issues with one domain

by Jürgen Echter

Hi, i installed knot-resolver on my mail server and i see a issue with a specific domain, dovecot.org. Everything is working as expected but this single domain doesn't always resolve. After some time postfix cannot check the domain where mails coming from and doesn't accept them. If i do dig dovecot.org, i get this (SERVFAIL): dig dovecot.org ; <<>> DiG 9.11.26-RedHat-9.11.26-6.el8 <<>> dovecot.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27594 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;dovecot.org. IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fr Apr 29 08:34:55 CEST 2022 ;; MSG SIZE rcvd: 40 it starts working again if do dig +cd, like this: dig +cd dovecot.org ; <<>> DiG 9.11.26-RedHat-9.11.26-6.el8 <<>> +cd dovecot.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56130 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;dovecot.org. IN A ;; ANSWER SECTION: dovecot.org. 300 IN A 94.237.12.234 ;; Query time: 245 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fr Apr 29 08:34:59 CEST 2022 ;; MSG SIZE rcvd: 56 i didn't have this kind of issue using unbound before i switched, so i think here would be the right place to ask. i'm using the knot-resolver 5.5.0 package from epel on rockylinux 8.5 and my kresd config is very simple: net.listen('127.0.0.1', 53, { kind = 'dns' }) net.listen('127.0.0.1', 853, { kind = 'tls' }) --net.listen('127.0.0.1', 443, { kind = 'doh2' }) net.listen('::1', 53, { kind = 'dns', freebind = true }) net.listen('::1', 853, { kind = 'tls', freebind = true }) --net.listen('::1', 443, { kind = 'doh2' }) -- Load useful modules modules = { 'hints > iterate', -- Allow loading /etc/hosts or custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- Cache size cache.size = 100 * MB -- use /etc/hosts entries -- hints.add_hosts() net.ipv6 = false Anything i can do to track this down? Thanks in advance for your help. Juergen

3 roky, 9 měsíců

2
3
0 0

kresd segfault

by Aleš Rygl

Hello, I have noticed kresd segfault: [Sun May 15 14:22:47 2022] kresd[1791403]: segfault at 407ce590 ip 00000000407ce590 sp 00007ffc2d192668 error 15 There were also about 1300 lines from the same PID with a message like this: May 15 14:23:45 xxxx kresd[1791403]: [primin] triggered priming query, next in 0 seconds Maybe it is related to the crash maybe not. OS: Debian Linux 11.3 kernel 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) Knot-Resolver: 5.5.0-cznic.1 With regards Ales

3 roky, 9 měsíců

2
1
0 0

100....Error Messages new user

by Günther J. Niederwimmer

Hello List, why i got hundreds of these error messages see below, How can I best determine whether and how knot-resolver is working correctly May 9 13:37:28 bbs kresd[2102]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2102]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2107]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2107]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2107]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2101]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2100]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Broken pipe) May 9 13:37:37 bbs kresd[2101]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2100]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2100]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2101]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2102]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2102]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2102]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Broken pipe) May 9 13:37:38 bbs kresd[2107]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2107]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2107]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) Thanks for the Help, -- mit freundlichen Grüßen / best Regards, Günther J. Niederwimmer

3 roky, 9 měsíců

2
1
0 0

100....Error Messages new user

by Günther J. Niederwimmer

Hello List why i got hundreds of these error messages see below, How can I best determine whether and how knot-resolver is working correctly May 9 13:37:28 bbs kresd[2102]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2102]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2107]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2107]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2107]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2101]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2100]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Broken pipe) May 9 13:37:37 bbs kresd[2101]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2100]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2100]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2101]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2102]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2102]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2102]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Broken pipe) May 9 13:37:38 bbs kresd[2107]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2107]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2107]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) Thanks for the Help, -- mit freundlichen Grüßen / best Regards, Günther J. Niederwimmer

3 roky, 9 měsíců

1
0
0 0

Rebinding protection - how to suppress additional section

by Aleš Rygl

Hello, We are using Knot-Resolver 5.5.0 with rebinding protection: modules.load('rebinding < iterate') We have some complains about an invalid domain name being returned in the additional section of the response to the blocked request: ;; ADDITIONAL SECTION: explanation.invalid. 10800 IN TXT "blocked by DNS rebinding protection" It looks like some windows domain controllers running DNS clients do not like it and log an error: The DNS server encountered an invalid domain name in a packet from <Knot-Resolver IP> The packet will be rejected. The event data contains the DNS packet. Is there a way how to suppress this? Or even better response with SERVFAIL? Thanks Ales Rygl

3 roky, 10 měsíců

2
1
0 0

Preload module with mutliple instances of kresd

by Aleš Rygl

Hello, I'd would like to ask for help with preload module. The issue is that when running multiple instatnces of kresd under systemd usualy just one of them is able to start correctly. The other hangs and fails to start. The config is just copy/paste from the documentation: modules.load('prefill') prefill.config({ ['.'] = { url = 'https://www.internic.net/domain/root.zone', interval = 86400, -- seconds } }) Starting instances in a sequence does not help, the 2nd one hangs - and only if the 1st one is killed/stopped the 2nd one goes on and processes the root zone. Did I miss something in the documentation? With regards Ales Rygl

3 roky, 10 měsíců

2
2
0 0

Google Chrome not working with Knot Resolver via DoH

by Blažej Krajňák

Hello, at AS50242 we run two recursive resolvers for our ISP customers. Both resolvers are listening for doh2 with ECDSA SSL certs from Letsencrypt. ns1r.levonet.sk ns2r.levonet.sk kdig +https is working correctly, however I'm unable to use these DoH resolvers with Google Chrome (99.0.4844.74) browser on MacOS (12.2.1). In settings I entered "https://ns2r.levonet.sk" as custom DoH resolver and I got error: Please verify that this is a valid provider or try again. I have enabled Knot debugging for doh and tls and log is flooded with messages about "incomplete, refusing". Does anybody have an idea what's wrong? Has Chrome some specific requirements for DoH servers? Thanks Blažej Mar 15 19:47:44 ns2r kresd[1317767]: [doh ] [0x215d1e0] h2 session created for 2a02:6ca3:800:0:60c4:dcd1:0000:0000#57880 Mar 15 19:47:44 ns2r kresd[1317767]: [tls ] TLS handshake with 2a02:6ca3:800:0:60c4:dcd1:0000:0000#57880 has completed Mar 15 19:47:44 ns2r kresd[1317775]: [doh ] [0x168d620] h2 session created for 2a02:6ca3:800:0:60c4:dcd1:0000:0000#57881 Mar 15 19:47:44 ns2r kresd[1317775]: [tls ] TLS handshake with 2a02:6ca3:800:0:60c4:dcd1:0000:0000#57881 has completed Mar 15 19:47:45 ns2r kresd[1317771]: [doh ] [0x1016940] h2 session created for 2a02:6ca3:800:0:60c4:dcd1:0000:0000#57882 Mar 15 19:47:45 ns2r kresd[1317771]: [tls ] TLS handshake with 2a02:6ca3:800:0:60c4:dcd1:0000:0000#57882 has completed Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (begin_headers_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (begin_headers_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:46 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 23 incomplete, refusing (begin_headers_callback)

3 roky, 11 měsíců

3
3
0 0

Survey on DNS resolver operations and DNSSEC

by Moritz Müller

Hi everyone, The DNS Security Extensions (DNSSEC) add integrity and authenticity to the Domain Name System (DNS). Now, more than 17 years after their standardization, we would like to hear from DNS recursive resolver operators about their experience with DNSSEC. For this reason, we have set up a short survey. It’s directed mainly towards organisations that run a recursive resolver. Filling out the survey should take roughly 5 to 10 minutes. https://forms.gle/FxTD9FofaogdvLqcA (link directs to Google Forms) This survey is carried out by SIDN Labs (https://sidnlabs.nl) and by the Swedish Internet Foundation (https://internetstiftelsen.se/en/). You can contact us via email: moritz.muller(a)sidn.nl Please excuse us, if you have received this email via different mailing lists. — Moritz Müller Research Engineer at SIDN Labs

3 roky, 11 měsíců

1
0
0 0

Knot Resolver 5.5.0

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.5.0 has been released! Improvements - extended_errors: module for extended DNS error support, RFC8914 (!1234) - policy: log policy actions; useful for RPZ debugging (!1239) - policy: new action policy.IPTRACE for logging request origin (!1239) - prefill module: prepare for ZONEMD, improve performance (!1225) - validator: conditionally ignore SHA1 DS, as SHOULD by RFC4509 (!1251) - lib/resolve: use EDNS padding for outgoing TLS queries (!1254) - support for PROXYv2 protocol (!1238) - lib/resolve, policy: new NO_ANSWER flag for not responding to clients (!1257) Incompatible changes - libknot >= 3.0.2 is required Bugfixes - doh2: fix CORS by adding `access-control-allow-origin: *` (!1246) - net: fix listen by interface - add interface suffix to link-local IPv6 (!1253) - daemon/tls: fix resumption for outgoing TLS (e.g. TLS_FORWARD) (!1261) - nameserver selection: fix interaction of timeouts with reboots (#722, !1269) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.5.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.5.0/ Donation: https://donations.nic.cz/en/donate/?project=knot-resolver -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

3 roky, 11 měsíců

1
0
0 0

Knot Resolver 5.5.0.

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.5.0 has been released! Improvements - extended_errors: module for extended DNS error support, RFC8914 (!1234) - policy: log policy actions; useful for RPZ debugging (!1239) - policy: new action policy.IPTRACE for logging request origin (!1239) - prefill module: prepare for ZONEMD, improve performance (!1225) - validator: conditionally ignore SHA1 DS, as SHOULD by RFC4509 (!1251) - lib/resolve: use EDNS padding for outgoing TLS queries (!1254) - support for PROXYv2 protocol (!1238) - lib/resolve, policy: new NO_ANSWER flag for not responding to clients (!1257) Incompatible changes - libknot >= 3.0.2 is required Bugfixes - doh2: fix CORS by adding `access-control-allow-origin: *` (!1246) - net: fix listen by interface - add interface suffix to link-local IPv6 (!1253) - daemon/tls: fix resumption for outgoing TLS (e.g. TLS_FORWARD) (!1261) - nameserver selection: fix interaction of timeouts with reboots (#722, !1269) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.5.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.5.0/ Donation: https://donations.nic.cz/en/donate/?project=knot-resolver -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

3 roky, 11 měsíců

1
0
0 0

Knot Resolver 5.5.0

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.5.0 has been released! Improvements - extended_errors: module for extended DNS error support, RFC8914 (!1234) - policy: log policy actions; useful for RPZ debugging (!1239) - policy: new action policy.IPTRACE for logging request origin (!1239) - prefill module: prepare for ZONEMD, improve performance (!1225) - validator: conditionally ignore SHA1 DS, as SHOULD by RFC4509 (!1251) - lib/resolve: use EDNS padding for outgoing TLS queries (!1254) - support for PROXYv2 protocol (!1238) - lib/resolve, policy: new NO_ANSWER flag for not responding to clients (!1257) Incompatible changes - libknot >= 3.0.2 is required Bugfixes - doh2: fix CORS by adding `access-control-allow-origin: *` (!1246) - net: fix listen by interface - add interface suffix to link-local IPv6 (!1253) - daemon/tls: fix resumption for outgoing TLS (e.g. TLS_FORWARD) (!1261) - nameserver selection: fix interaction of timeouts with reboots (#722, !1269) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.5.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.5.0/ Donation: https://donations.nic.cz/en/donate/?project=knot-resolver -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

3 roky, 11 měsíců

1
0
0 0

Knot Resolver 5.5.0

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.5.0 has been released! Improvements - extended_errors: module for extended DNS error support, RFC8914 (!1234) - policy: log policy actions; useful for RPZ debugging (!1239) - policy: new action policy.IPTRACE for logging request origin (!1239) - prefill module: prepare for ZONEMD, improve performance (!1225) - validator: conditionally ignore SHA1 DS, as SHOULD by RFC4509 (!1251) - lib/resolve: use EDNS padding for outgoing TLS queries (!1254) - support for PROXYv2 protocol (!1238) - lib/resolve, policy: new NO_ANSWER flag for not responding to clients (!1257) Incompatible changes - libknot >= 3.0.2 is required Bugfixes - doh2: fix CORS by adding `access-control-allow-origin: *` (!1246) - net: fix listen by interface - add interface suffix to link-local IPv6 (!1253) - daemon/tls: fix resumption for outgoing TLS (e.g. TLS_FORWARD) (!1261) - nameserver selection: fix interaction of timeouts with reboots (#722, !1269) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.5.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.5.0/ Donation: https://donations.nic.cz/en/donate/?project=knot-resolver -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

3 roky, 11 měsíců

1
0
0 0

Crashless crash

by Łukasz Jarosz

Hello, I recently deployed knot-resolver as main resolver for my network with following config: -- modules modules = { 'policy', 'view', 'workarounds < iterate', 'stats', -- required by predict module 'predict', 'http', } -- network net.ipv6 = false net.listen('0.0.0.0', 53, { kind = 'dns' }) net.listen('0.0.0.0', 8453, { kind = 'webmgmt' }) -- permissions user('knot-resolver','knot-resolver') -- cache, stats, performance optimizations cache.open(950*MB, 'lmdb:///cache/knot-resolver') cache.min_ttl(600) predict.config({ window = 5, period = 1*(60/5) }) -- limit access with ACLs view:addr('127.0.0.0/8', policy.all(policy.PASS)) view:addr('172.16.0.0/12', policy.all(policy.PASS)) view:addr('10.0.0.0/8', policy.all(policy.PASS)) view:addr('redacted', policy.all(policy.PASS)) view:addr('redacted', policy.all(policy.PASS)) view:addr('redacted', policy.all(policy.PASS)) view:addr('0.0.0.0/0', policy.all(policy.DROP)) -- query resolving policies policy.add(policy.rpz(policy.ANSWER, '/run/knot-resolver/custom.rpz', true)) policy.add(policy.all(policy.FORWARD({ "9.9.9.9", "8.8.8.8", }))) Process is started inside docker container with properly attached tmpfs at /cache mountpoint. Setup is monitored through prometheus and I received notification around 21:55 that exporter is down. To be exact context deadline exceeded (scrape_interval: 15s). I grabbed control socket and dumped following stats: > worker.stats() { ['concurrent'] = 1, ['csw'] = 31436648, ['dropped'] = 16081, ['err_http'] = 0, ['err_tcp'] = 0, ['err_tls'] = 0, ['err_udp'] = 0, ['ipv4'] = 9950850, ['ipv6'] = 0, ['pagefaults'] = 1, ['queries'] = 30978879, ['rss'] = 166846464, ['swaps'] = 0, ['systime'] = 2681.109337, ['tcp'] = 232596, ['timeout'] = 139212, ['tls'] = 0, ['udp'] = 9718254, ['usertime'] = 6298.521581, } > cache.stats() { ['clear'] = 1, ['close'] = 1, ['commit'] = 23279836, ['count'] = 20349, ['count_entries'] = 340222, ['match'] = 0, ['match_miss'] = 0, ['open'] = 2, ['read'] = 144512076, ['read_leq'] = 10170653, ['read_leq_miss'] = 4988410, ['read_miss'] = 25166216, ['remove'] = 0, ['remove_miss'] = 0, ['usage_percent'] = 11.396792763158, ['write'] = 25742556, } When I opened web interface I noticed steady decline in requests. [image: image.png] I think this means that clients mostly moved to secondary DNS resolver. Also when reviewing gathered data in grafana dashboard I noticed that slow (250ms+) queries are prevalent from the fast queries. [image: image.png] Any advice what happened here? Best regards, Łukasz Jarosz

3 roky, 11 měsíců

1
0
0 0

Removing a temporary negative trust anchor

by Matthew Richardson

Running 5.4.4, adding an NTA seems very straightforward:- >> trust_anchors.set_insecure( {"fj"} ) > >> trust_anchors.summary() >'fj. is negative trust anchor >. 172800 DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ; Valid: ; KeyTag:20326 >' What is the precise incantation to remove it when it is no longer required? The following do not work:- >> trust_anchors.remove('fj') >false >> trust_anchors.remove('fj.') >false >> trust_anchors.remove( {"fj"} ) >false Any help would be appreciated. Also, does Knot Resolver allow an automatic timeout when setting NTAs as Bind does? --- Best wishes, Matthew

3 roky, 11 měsíců

2
2
0 0

Unicode issue

by Łukasz Jarosz

Hello, I am trying to import custom generated RPZ list into kresd, but daemon fails with following error "[policy] RPZ: invalid domain name character". I am using UTF-8 as encoding for file. Any pointers how to convince kres to ingest these domain names would be greatly appreciated. Best regards, Łukasz Jarosz

3 roky, 11 měsíců

2
2
0 0

Knot Resolver dropping requests

by Aleš Rygl

Hello, I'd like to kindly ask for help with following issue. I am considering to deploy knot-resolver to the DNS solution where it should coexist with other DNS daemons namely Unbound. I am running dnsdist <https://dnsdist.org/> in front of the pool of resolvers where I have just added also the latest release (5.5.4) of knot-resolver. It receives a portion of requests at the rate about 500qps. There are 6 kresd processes on a VM running with cache in tmpfs. Cache size is 2GB (8GB mounted to tmpfs). Resolver is running Debian Bullseye. The solution is serving real customers - the traffic is not artificial. The configuration enables some modules: modules = { 'hints > iterate', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records 'bogus_log', -- DNSSEC validation failure logging 'nsid', 'prefill', 'rebinding < iterate' } cache.size = cache.fssize() - 6*GB modules = { predict = { window = 15, -- 15 minutes sampling window period = 6*(60/15) -- track last 6 hours } } policy.add( policy.rpz(policy.DENY, '/var/cache/unbound/db.rpz.xxx.cz', true) ) And the Carbon protocol reporting is enabled with the sample rate of 5s. The performance in terms of response time is equal or even better when comparing with Unbound. I am measuring the performance of the dnsdist's backend servers (daemons) - the latency, dropped requests and the requests rate using Carbon protocol with sample rate of 5s. The backend servers kresd included are receiving requests from just several clients at the moment (source IPs of the balancers). What is wrong here is some kind of repeated packet drops reported for kresd instance by dnsdist. It appears in about 15 min. interval. When it occurs the drop rate increases from about 0.5 req/s (standard behavior) to 5-10 req/s which causes a positive feedback and increased packet rate. There are such peaks every 15 min. When I restart the kresd instances drops go away and everything is stellar for couple of hours. I have no explanation for that. It is apparently not related to the requests - I have tried to simulate this by replaying the traffic captured when the problem occurs several times without success. kresd can even process 20k qps on this instance with no increase of drop rate from the balancer's point of view. But after a while... The fact that restarting kresd helps immediately shows that there might be something wrong inside. I have tried to increase the number of kresd processes, cache size and disabling the cache persistence. Nothing helps here. I am pretty sure there are no network issues on the VM or surrounding network. I can provide some graphical representations of this behavior of it is needed or a packet capture of the real traffic. Many thanks With best regards Ales Rygl

3 roky, 12 měsíců

2
2
0 0

How to post DNSTAP data to rsyslog

by Martin Zingor

Hello, I'd like to post DNSTAP data to remote syslog. In kresd.conf I have: ... dnstap.config({ socket_path = "/tmp/dnstap.sock", }) ... I try run socat to create and listen on socket but no data I see. What is wrong? Thank you. MZ

4 roky

1
0
0 0

Knot Resolver 5.4.4

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.4.4 has been released! Bugfixes -------- - fix bad zone cut update in certain cases (e.g. AWS; !1237) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.4.4/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.4.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.4.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.4.4/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

4 roky, 1 měsíc

1
0
0 0

Knot Resolver 5.4.3

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.4.3 has been released! Improvements ------------ - lua: add kres.parse_rdata() to parse RDATA from string to wire format (!1233) - lua: add policy.domains() for exact domain name matching (!1228) Bugfixes -------- - policy.rpz: fix origin detection in files without $ORIGIN (!1215) - lua: log() works again; broken in 5.4.2 (!1223) - policy: correctly include EDNS0 previously omitted by some actions (!1230) - edns_keepalive: module is now properly loaded (!1229, thanks Josh Soref!) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.4.3/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.3.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.3.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.4.3/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

4 roky, 2 měsíce

1
0
0 0

Knot resolver in front of systemd-resolved stub resolver, more issues

by Sergio Callegari

Hi, I am writing looking for some help with a setup where the local lan has a machine with knot resolver and some of the hosts that are connected to the LAN are ubuntu machines that by default use systemd-resolved as a local caching stub resolver. For some reasons this combination appears troublesome and I am trying to undestand all the reasons why. One issue has already been identified as a systemd-resolved, in the ubuntu focal version getting confused by a (correct) answer from kresd (discussion on https://gitlab.nic.cz/knot/knot-resolver/-/issues/686#note_234431). Now, I find another issue in that I do not appear successful in making systemd-resolved talk to kresd over tls. This would be important because most of the ubuntu focal hosts are setup with systemd-resolved using opportunistic tls. If systemd-thinks that there is a problem with contacting the current DNS server via tls then it switches to the fallback server and kresd ends up not being used at all. If I use `resolvectl` to set the DNS of an ubuntu host to point to the machine with kresd and I activate DNSoverTLS, then I get: resolvectl query lwn.net lwn.net: resolve call failed: All attempts to contact name servers or networks failed Similarly, if I user resolvectl to set to use opportunistic DNSoverTLS, things seem to work, but I see on the journal some messages about Using degraded feature set UDP for DNS server Thus, I'd be glad to get some pointer at how to check that DNS over TLS works correctly with kresd and how to verify why systemd-resolved fails. Thanks! Sergio

4 roky, 2 měsíce

2
1
0 0

Knot resolver in front of systemd-resolved stub resolver, more issues

by Sergio Callegari

Hi, I am writing looking for some help with a setup where the local lan has a machine with knot resolver and some of the hosts that are connected to the LAN are ubuntu machines that by default use systemd-resolved as a local caching stub resolver. For some reasons this combination appears troublesome and I am trying to undestand all the reasons why. One issue has already been identified as a systemd-resolved, in the ubuntu focal version getting confused by a (correct) answer from kresd (discussion on https://gitlab.nic.cz/knot/knot-resolver/-/issues/686#note_234431). Now, I find another issue in that I do not appear successful in making systemd-resolved talk to kresd over tls. This would be important because some of the ubuntu focal hosts are setup with systemd-resolved using tls. If I use `resolvectl` to set the DNS of an ubuntu host to point to the machine with kresd and I activate DNSoverTLS, then I get: resolvectl query lwn.net lwn.net: resolve call failed: All attempts to contact name servers or networks failed Similarly, if I user resolvectl to set to use opportunistic DNSoverTLS, things seem to work, but I see on the journal some messages about Using degraded feature set UDP for DNS server Thus, I'd be glad to get some pointer at how to check that DNS over TLS works correctly with kresd and how to verify why systemd-resolved fails. Thanks! Sergio

4 roky, 2 měsíce

1
0
0 0

CNAME resolving knot-resolver vs bind

by tomas tomas

Hello, I have a problem with knot-resolver and resolving CNAME on my domain, but request to bind-resolver is ok. Some configuration parameter (such as --trust_anchors.set_insecure,remove) doesn't solve my problem. Could you help me please? Commands (data is anonymized) : [ ~]$ nslookup elearning.mycompany.sk 192.168.1.53 # kresd -failed Server: 192.168.1.53 Address: 192.168.1.53#53 Non-authoritative answer: elearning.mycompany.sk canonical name = elearning.netcompany.sk. [ ~]$ nslookup elearning.mycompany.sk 192.168.1.33 # bind -ok Server: 192.168.1.33 Address: 192.168.1.33#53 Non-authoritative answer: elearning.mycompany.sk canonical name = elearning.netcompany.sk. Name: elearning.netcompany.sk. Address: 53.53.53.153 [~]$ nslookup elearning.netcompany.sk. 192.168.1.53 # kresd -ok Server: 192.168.1.53 Address: 192.168.1.53#53 Non-authoritative answer: Name: elearning.netcompany.sk Address: 53.53.53.153 Here is trace command from kresd: [ ~]$ curl -s --noproxy "*" http://127.0.0.1:8453/trace/elearning.mycompany.sk [iterat][205086.00] 'elearning.mycompany.sk.' type 'A' new uid was assigned .01, parent uid .00 [cache ][205086.01] => satisfied by exact packet: rank 021, new TTL 7110 [iterat][205086.01] <= answer received: ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 31993 ;; Flags: qr aa rd QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: Unused ;; QUESTION SECTION elearning.mycompany.sk. A ;; ANSWER SECTION elearning.mycompany.sk. 7110 CNAME elearning.netcompany.sk. ;; ADDITIONAL SECTION [resolv][205086.01] AD: request NOT classified as SECURE [resolv][205086.01] finished in state: 4, queries: 1, mempool: 131152 B ;; selected from ANSWER sections: ; ranked rrset to_wire true, rank 021 (omit auth), cached false, qry_uid 1, revalidations 0 elearning.mycompany.sk. 7110 CNAME elearning.netcompany.sk. curl -s --noproxy "*" http://127.0.0.1:8453/trace/elearning.netcompany.sk. [iterat][65580.00] 'elearning.netcompany.sk.' type 'A' new uid was assigned .01, parent uid .00 [cache ][65580.01] => satisfied by exact RRset: rank 030, new TTL 1187 [iterat][65580.01] <= answer received: ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 21817 ;; Flags: qr aa QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0 ;; QUESTION SECTION elearning.netcompany.sk. A ;; ANSWER SECTION elearning.netcompany.sk. 1187 A 53.53.53.153 elearning.netcompany.sk. 1187 RRSIG A 7 3 1800 .... [iterat][65580.01] <= rcode: NOERROR [resolv][65580.01] AD: request NOT classified as SECURE [resolv][65580.01] finished in state: 4, queries: 1, mempool: 147552 B ;; selected from ANSWER sections: ; ranked rrset to_wire true, rank 030 (insecure auth), cached false, qry_uid 1, revalidations 0 elearning.netcompany.sk. 1187 A 53.53.53.153 ; ranked rrset to_wire true, rank 030 (insecure auth), cached false, qry_uid 1, revalidations 0 elearning.netcompany.sk. 1187 RRSIG A 7 3 1800 ..... [ ~]$ journalctl -u kresd@1 kresd[18169]: [iterat][34703.00] 'elearning.mycompany.sk.' type 'A' new uid was assigned .01, parent uid .00 kresd[18169]: [cache ][34703.01] => satisfied by exact packet: rank 021, new TTL 6811 kresd[18169]: [resolv][34703.01] AD: request NOT classified as SECURE kresd[18169]: [resolv][34703.01] finished in state: 4, queries: 1, mempool: 65600 B kresd[18169]: [plan ][00000.00] plan 'elearning.netcompany.sk.' type 'AAAA' uid [17932.00] kresd[18169]: [iterat][17932.00] 'elearning.netcompany.sk.' type 'AAAA' new uid was assigned .01, parent uid .00 kresd[18169]: [cache ][17932.01] => satisfied by exact packet: rank 020, new TTL 1411 kresd[18169]: [iterat][17932.01] <= rcode: NOERROR kresd[18169]: [resolv][17932.01] AD: request NOT classified as SECURE My kresd.conf: log_level('warning') net.listen('192.168.1.53', 53, { kind = 'dns', freebind = true }) net.listen('192.168.1.53', 853, { kind = 'tls', freebind = true }) net.listen('127.0.0.1', 8453, { kind = 'webmgmt' }) user('knot-resolver','knot-resolver') modules = { 'hints > iterate', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records 'policy', 'view', -- view:addr(..) 'prefill', -- Cache prefilling 'http' } internalDomains = policy.todnames({'mycompany.sk'}) externalIP = policy.todnames({'53.53.53.in-addr.arpa.'}) policy.add(policy.suffix(policy.STUB({'192.168.1.3','192.168.1.4'}), internalDomains)) policy.add(policy.suffix(policy.STUB({'192.168.1.3','192.168.1.4'}), externalIP)) view:addr('192.168.0.0/16', policy.all(policy.PASS)) view:addr('172.16.0.0/12', policy.all(policy.PASS)) view:addr('10.0.0.0/8', policy.all(policy.PASS)) view:addr('0.0.0.0/0', policy.all(policy.DROP)) --trust_anchors.set_insecure({ 'mycompany.sk.', 'netcompany.sk.' }) --trust_anchors.remove('.') cache.size = cache.fssize() - 10*MB thanks Tomas

4 roky, 3 měsíce

2
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

knot-resolver-users