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

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

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

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

10 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

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

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.

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

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

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

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

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

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, 1 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, 1 měsíc

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

knot-resolver-users