Hello,
finally, the upcoming release is available for testing. All details about what has changed are on our blog:
Please report any bugs to our bug tracker and leave any other feedback right here.
Upgrade from 202 to 203 aarch64.
Everything works fine: VPN (openvpn, wireguard), DNS Firewall, Wlan, etc.
After upgrade memory consumption decrease from 43% to 10%
This is what we wanted to see! Knot Resolver will be much more memory-efficient than Unbound was with the DNS Firewall.
That depends. This was a tracker bug so that we can collect ideas.
If you are certain that you found a bug with it, I would suggest to open a new one. If you have questions about how to use that feature, you should open a thread on this forum potentially.
I installed CU203, too, in my testing VirtualBox.
No problems. Unbound config was transfered to knot without errors, as far as I can see.
Memory consumption decreased tremendous. Even with big RPZs enabled.
Good work! Congrats to the authors of this change.
No troubles here either, running net2net OpenVPN, DNS Forwarding, DNS Firewall and IPS in a virtual machine (QEMU). Memory consumption went down from around 40% to 10%.
No problems here so far. Libvirtd guests run smoothly after upgrade. Nice job again, gentlemen! 
No problem loading and system performance did improve. But it reset all my firewall settings to default. That was a first for me.
I donāt normally have safe search enabled.
I enabled the two checkboxes as you showed and pressed the Save button. I was also using TLS for the DNS Queries.
This was on a Core-Update 203 Development Build: master/e9a5fbb3 system.
I was able to access the three search engine links you mentioned.
I was then able to carry out a search with all three of the search engines.
This was with a Firefox browser.
When I used that url it showed a table with three options, with the middle one selected.
Hello
Iām still getting the Spice connection error in VMM, even after updating from spice-0.15.0-7 to spice-0.16.0-8.
See my post below.
Paul
Were all your Unbound config migrated? I have no Unbound config defined via the WebUI, all are defined via /etc/unbound/local.d, including my rpz.conf. None of them got migrated. Is that expected behavior that only those DBL selected in the WebUI gets migrated?
Hello, thank you for this wonderful distribution. I took an iso backup of my Sophos XG-210 running core 202 (RED, GREEN and BLUE) and used it to install onto a VM (RED and GREEN only, DHCP server off). I then followed the guide here, changed the repo to Testing and upgraded to 203. Everything went well but Knot Resolver wouldnāt start.
Hereāre the relevant log entries after changing the worker to 1 to reduce the noise:
Jun 18 04:38:17 gatekeeper supervisord: spawned: 'kresd0' with pid 10056
Jun 18 04:38:17 gatekeeper supervisord: captured stdio output from kresd0[10056] (stderr): [system] config 'kresd0.conf' (workdir '/run/knot-resolver'): No such file or directory
Jun 18 04:38:17 gatekeeper supervisord: exited: kresd0 (exit status 1; not expected)
Jun 18 04:38:18 gatekeeper database: has been updated recently
Jun 18 04:38:19 gatekeeper supervisord: spawned: 'kresd0' with pid 10064
Jun 18 04:38:19 gatekeeper supervisord: spawned: 'manager' with pid 10065
Jun 18 04:38:19 gatekeeper supervisord: captured stdio output from kresd0[10064] (stderr): [system] config 'kresd0.conf' (workdir '/run/knot-resolver'): No such file or directory
Jun 18 04:38:19 gatekeeper supervisord: exited: kresd0 (exit status 1; not expected)
Jun 18 04:38:20 gatekeeper knot_resolver.manager.server: Loading configuration from '/etc/knot-resolver/config.yaml' file.
Jun 18 04:38:20 gatekeeper knot_resolver.manager.logger: Changing logging level to 'INFO'
Jun 18 04:38:20 gatekeeper knot_resolver.controller: Starting service manager auto-selection...
Jun 18 04:38:20 gatekeeper knot_resolver.controller: Available subprocess controllers are ('supervisord',)
Jun 18 04:38:20 gatekeeper knot_resolver.controller: Selected controller 'supervisord'
Jun 18 04:38:20 gatekeeper knot_resolver.controller.supervi: Supervisord is already running, we will just update its config...
Jun 18 04:38:20 gatekeeper supervisord: spawned: 'policy-loader' with pid 10067
Jun 18 04:38:20 gatekeeper supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
Jun 18 04:38:20 gatekeeper kresd[10067]: [cache ] Cache top initialized using existing data (AVX2).
Jun 18 04:38:20 gatekeeper supervisord: exited: policy-loader (exit status 0; expected)
Jun 18 04:38:21 gatekeeper supervisord: spawned: 'kresd1' with pid 10068
Jun 18 04:38:21 gatekeeper kresd[10068]: [system] path = /run/knot-resolver/control/1
Jun 18 04:38:21 gatekeeper kresd[10068]: [cache ] Cache top initialized using existing data (AVX2).
Jun 18 04:38:21 gatekeeper kresd[10068]: [defer ] Initializing defer...
Jun 18 04:38:21 gatekeeper kresd[10068]: [defer ] Defer initialized (AVX2).
Jun 18 04:38:21 gatekeeper kresd[10068]: [defer ] Defer configuration: Expected cpus/procs: 1 Max waiting requests: 64.0 MiB Request timeout: 1.0 s Idle: 1.0 ms UDP phase: 400.0 us Non-UDP phase: 400.0 us Priority levels: 25 (4 main levels, 8 sublevels) + UDP KRU capacity: 524.3 k (4.2 MiB) Decay: 0.012 % per ms (32-bit max: 524280) Half-life: 5.7 s Priority rise in: 22.7 s Counter reset in: 90.8 s Rate limits for crossing priority levels as single CPU utilization: 1 2 3 max v4/32 : 0.012 % 0.195 % 3.125 % 49.999 % v4/24 : 0.391 % 6.250 % 100.000 % 1599.976 % v4/20 : 3.125 % 50.000 % 800.000 % 12799.805 % v4/18 : 9.375 % 150.000 % 2400.000 % 38399.414 % v6/128: 0.012 % 0.195 % 3.125 % 49.999 % v6/64 : 0.024 % 0.391 % 6.250 % 99.998 % v6/56 : 0.037 % 0.586 % 9.375 % 149.998 % v6/48 : 0.049 % 0.781 % 12.500 % 199.997 % v6/32 : 0.781 % 12.500 % 200.000 % 3199.951 % Instant limits for crossing priority levels as CPU time: 1 2 3 max v4/32 : 1.0 ms 16.0 ms 256.0 ms 4.1 s v4/24 : 32.0 ms 512.0 ms 8.2 s 131.1 s v4/20 : 256.0 ms 4.1 s 65.5 s 1048.6 s v4/18 : 768.0 ms 12.3 s 196.6 s 3145.7 s v6/128: 1.0 ms 16.0 ms 256.0 ms 4.1 s v6/64 : 2.0 ms 32.0 ms 512.0 ms 8.2 s v6/56 : 3.0 ms 48.0 ms 768.0 ms 12.3 s v6/48 : 4.0 ms 64.0 ms
Jun 18 04:38:21 gatekeeper kresd[10068]: [system] error while loading config: /usr/lib/knot-resolver/config.lua:130: attempt to index local 'address' (a nil value) (workdir '/run/knot-resolver')
Jun 18 04:38:21 gatekeeper supervisord: exited: kresd1 (exit status 1; not expected)
Jun 18 04:38:21 gatekeeper knot_resolver.manager.manager: Kresd with the new config failed to start, rejecting config
Jun 18 04:38:21 gatekeeper supervisord: spawned: 'kresd0' with pid 10069
Jun 18 04:38:21 gatekeeper kresd[10069]: [system] path = /run/knot-resolver/control/0
Jun 18 04:38:22 gatekeeper kresd[10069]: [cache ] Cache top initialized using existing data (AVX2).
Jun 18 04:38:22 gatekeeper kresd[10069]: [defer ] Initializing defer...
Jun 18 04:38:22 gatekeeper kresd[10069]: [defer ] Defer initialized (AVX2).
Jun 18 04:38:22 gatekeeper kresd[10069]: [defer ] Defer configuration: Expected cpus/procs: 1 Max waiting requests: 64.0 MiB Request timeout: 1.0 s Idle: 1.0 ms UDP phase: 400.0 us Non-UDP phase: 400.0 us Priority levels: 25 (4 main levels, 8 sublevels) + UDP KRU capacity: 524.3 k (4.2 MiB) Decay: 0.012 % per ms (32-bit max: 524280) Half-life: 5.7 s Priority rise in: 22.7 s Counter reset in: 90.8 s Rate limits for crossing priority levels as single CPU utilization: 1 2 3 max v4/32 : 0.012 % 0.195 % 3.125 % 49.999 % v4/24 : 0.391 % 6.250 % 100.000 % 1599.976 % v4/20 : 3.125 % 50.000 % 800.000 % 12799.805 % v4/18 : 9.375 % 150.000 % 2400.000 % 38399.414 % v6/128: 0.012 % 0.195 % 3.125 % 49.999 % v6/64 : 0.024 % 0.391 % 6.250 % 99.998 % v6/56 : 0.037 % 0.586 % 9.375 % 149.998 % v6/48 : 0.049 % 0.781 % 12.500 % 199.997 % v6/32 : 0.781 % 12.500 % 200.000 % 3199.951 % Instant limits for crossing priority levels as CPU time: 1 2 3 max v4/32 : 1.0 ms 16.0 ms 256.0 ms 4.1 s v4/24 : 32.0 ms 512.0 ms 8.2 s 131.1 s v4/20 : 256.0 ms 4.1 s 65.5 s 1048.6 s v4/18 : 768.0 ms 12.3 s 196.6 s 3145.7 s v6/128: 1.0 ms 16.0 ms 256.0 ms 4.1 s v6/64 : 2.0 ms 32.0 ms 512.0 ms 8.2 s v6/56 : 3.0 ms 48.0 ms 768.0 ms 12.3 s v6/48 : 4.0 ms 64.0 ms
Jun 18 04:38:22 gatekeeper kresd[10069]: [system] error while loading config: /usr/lib/knot-resolver/config.lua:130: attempt to index local 'address' (a nil value) (workdir '/run/knot-resolver')
Jun 18 04:38:22 gatekeeper supervisord: exited: kresd0 (exit status 1; not expected)
Jun 18 04:38:22 gatekeeper supervisord: gave up: kresd0 entered FATAL state, too many start retries too quickly
Jun 18 04:38:22 gatekeeper knot_resolver.manager.server: Uncaught generic exception during manager inicialization... Traceback (most recent call last): File "/usr/lib/python3.10/site-packages/knot_resolver/manager/server.py", line 627, in start_server manager = await _init_manager(config_store) File "/usr/lib/python3.10/site-packages/knot_resolver/manager/server.py", line 468, in _init_manager manager = await KresManager.create(controller, config_store) File "/usr/lib/python3.10/site-packages/knot_resolver/manager/manager.py", line 95, in create await inst._async_init(subprocess_controller, config_store) # noqa: SLF001 File "/usr/lib/python3.10/site-packages/knot_resolver/manager/manager.py", line 140, in _async_init await config_store.register_on_change_callback(only_on_real_changes_update(config_nodes)(self.apply_config)) File "/usr/lib/python3.10/site-packages/knot_resolver/manager/config_store.py", line 53, in register_on_change_callback await callback(self.get(), False) File "/usr/lib/python3.10/site-packages/knot_resolver/manager/config_store.py", line 88, in new_func_update await orig_func(config, force) File "/usr/lib/python3.10/site-packages/knot_resolver/manager/manager.py", line 298, in apply_config await self._rolling_restart(config) File "/usr/lib/python3.10/site-packages/knot_resolver/manager/manager.py", line 180, in _rolling_restart await kresd.apply_new_config(new_config) File "/usr/lib/python3.10/site-packages/knot_resolver/controller/interface.py", line 153, in apply_new_config await self._restart() File "/usr/lib/python3.10/site-packages/knot_resolver/utils/compat/asyncio.py", line 24, in wrapper return await to_thread(func, *args, **kwargs) File "/usr/lib/python3.10/site-packages/knot_resolver/utils/compat/asyncio.py", line 15, in to_thread return await asyncio.to_thread(func, *args, **kwargs) File "/usr/lib/python3.10/asyncio/threads.py", line 25, in to_thread return await loop.run_in_executor(None, func_call) File "/usr/lib/python3.10/conc
Jun 18 04:38:22 gatekeeper supervisord: exited: manager (exit status 1; not expected)
After going through /usr/lib/knot-resolver/config.lua I found the issue to be caused by /var/ipfire/dhcp/settings. I didnāt create a BLUE zone in my VM but the BLUE fields are still in /var/ipfire/dhcp/settings. No doubt coming from the backup. After deleting the relevant BLUE lines from the file, Knot Resolver started working. How do I force IPFire to regenerate this file after running setup and removing or adding zones?
Good afternoon.
Since I got the 203 trial version, Iāve noticed that this page isnāt loading correctly: (https://sourceforge.net/)
Iāve also had problems accessing certain pages, for example:
Since none of them are listed in: www.ipfire.org - IPFire DBL Report A Domain
Even though theyāre not categorized, Iāve had to whitelist them in the DNS Firewall to access them.
Is anyone else experiencing this?
Thanks.
I just tried this with CU2034 Testing and all sites were accessible.
What categories in the DNS Firewall do you have enabled.
Which categories did you enable?
The blocked URLs are logged by kresd in /var/log/messages. As far as I see it is categorized as ārulesā, only.
I just tested out enabling all the DNS Firewall categories. I the cleared the browser cache and then waited for a while and then confirmed that all zone files had been downloaded.
Then I tried the 5 urlās again and all of them opened up as normal. No issues with any of them.
Maybe your problem is coming from IPS or the IP Block List or the URL Filter.
If it is being caused by the DNS Firewall then you should be able to see entries about what caused the problem in the Domain Name System System Log entry.
If there are no entries related to the domains you are trying to access then it would not be due to the DNS Firewall.
If there are then you need to show what is being logged so it can be analysed.
Hi, thanks for quickly response.
I have this:
09:19:09 supervisord: captured stdio output from kresd1[3639]: Called for archive.ubuntu.com.northsecure.es. (28)
09:19:09 supervisord: captured stdio output from kresd1[3639]: Called for archive.ubuntu.com.northsecure.es. (1)
09:19:04 supervisord: captured stdio output from kresd0[3638]: Called for 89.0.254.10.in-addr.arpa. (12)
09:18:04 supervisord: captured stdio output from kresd0[3638]: Called for 89.0.254.10.in-addr.arpa. (12)
09:18:02 supervisord: captured stdio output from kresd2[3641]: Called for archive.ubuntu.com.northsecure.es. (28)
09:18:02 supervisord: captured stdio output from kresd2[3641]: Called for archive.ubuntu.com.northsecure.es. (1)
09:18:02 supervisord: captured stdio output from kresd0[3638]: Called for archive.ubuntu.com.northsecure.es. (28)
09:18:02 supervisord: captured stdio output from kresd0[3638]: Called for archive.ubuntu.com.northsecure.es. (1)
09:18:01 supervisord: captured stdio output from kresd1[3639]: Called for archive.ubuntu.com.northsecure.es. (28)
09:18:01 supervisord: captured stdio output from kresd1[3639]: Called for archive.ubuntu.com.northsecure.es. (1)
09:17:57 supervisord: captured stdio output from kresd1[3639]: Called for archive.ubuntu.com.northsecure.es. (28)
09:17:57 supervisord: captured stdio output from kresd1[3639]: Called for archive.ubuntu.com.northsecure.es. (1)
09:17:57 supervisord: captured stdio output from kresd0[3638]:
09:17:57 supervisord: captured stdio output from kresd0[3638]: Called for archive.ubuntu.com.northsecure.es. (28)
09:17:57 supervisord: captured stdio output from kresd0[3638]: Called for archive.ubuntu.com.northsecure.es. (1)
09:17:57 supervisord: captured stdio output from kresd1[3639]: Called for archive.ubuntu.com.northsecure.es. (28)
09:17:57 supervisord: captured stdio output from kresd1[3639]: Called for archive.ubuntu.com.northsecure.es. (1)
09:17:55 supervisord: captured stdio output from kresd2[3641]: Called for archive.ubuntu.com.northsecure.es. (28)
09:17:55 supervisord: captured stdio output from kresd2[3641]: Called for archive.ubuntu.com.northsecure.es. (1)
09:17:55 supervisord: captured stdio output from kresd2[3641]: Called for archive.ubuntu.com.northsecure.es. (28)
09:17:55 supervisord: captured stdio output from kresd2[3641]: Called for archive.ubuntu.com.northsecure.es. (1)
09:17:55 supervisord: captured stdio output from kresd2[3641]: Called for archive.ubuntu.com.northsecure.es. (28)
09:17:55 supervisord: captured stdio output from kresd2[3641]: Called for archive.ubuntu.com.northsecure.es. (1)
09:17:54 supervisord: captured stdio output from kresd0[3638]: Called for archive.ubuntu.com.northsecure.es. (28)
09:17:54 supervisord: captured stdio output from kresd0[3638]: Called for archive.ubuntu.com.northsecure.es. (1)
09:17:53 supervisord: captured stdio output from kresd2[3641]: Called for archive.ubuntu.com.northsecure.es. (28)
09:17:53 supervisord: captured stdio output from kresd2[3641]: Called for archive.ubuntu.com.northsecure.es. (1)
09:17:53 supervisord: captured stdio output from kresd1[3639]: Called for archive.ubuntu.com.northsecure.es. (28)
09:17:53 supervisord: captured stdio output from kresd1[3639]: Called for archive.ubuntu.com.northsecure.es. (1)
09:23:50 supervisord: captured stdio output from kresd2[3641]: Called for deb.nodesource.com.northsecure.es. (28)
09:23:50 supervisord: captured stdio output from kresd2[3641]: Called for deb.nodesource.com.northsecure.es. (1)
09:23:46 supervisord: captured stdio output from kresd2[3641]: Called for deb.nodesource.com.northsecure.es. (28)
09:23:46 supervisord: captured stdio output from kresd2[3641]: Called for deb.nodesource.com.northsecure.es. (1)
09:23:44 supervisord: captured stdio output from kresd1[3639]: Called for deb.nodesource.com.northsecure.es. (28)
09:23:44 supervisord: captured stdio output from kresd1[3639]: Called for deb.nodesource.com.northsecure.es. (1)
09:23:42 supervisord: captured stdio output from kresd2[3641]: Called for deb.nodesource.com.northsecure.es. (28)
09:23:42 supervisord: captured stdio output from kresd2[3641]: Called for deb.nodesource.com.northsecure.es. (1)
and this categories selected:
I hope this is what you asked for. It has very bad logsā¦
Bye
Hi,
Looking at the logs, I saw the following in the file /var/log/squid/access.log:
1781844902.223 40433 10.254.0.89 TCP_TUNNEL/200 1015302 CONNECT assets.box.com:443 - HIER_DIRECT/103.116.7.13 -
1781844902.624 400 10.254.0.89 TCP_TUNNEL/200 900 CONNECT account.box.com:443 - HIER_DIRECT/74.112.186.157 -
1781844902.890 264 10.254.0.89 TCP_TUNNEL/200 900 CONNECT account.box.com:443 - HIER_DIRECT/74.112.186.157 -
1781844903.684 0 10.254.0.89 TCP_TUNNEL/503 0 CONNECT cdn01.boxcdn.net:443 - HIER_NONE/- -
1781844903.684 0 10.254.0.89 TCP_TUNNEL/503 0 CONNECT cdn01.boxcdn.net:443 - HIER_NONE/- -
I added ācdn01.boxcdn.netā to the DNS Firewall whitelist and it started working correctly.
The following appears at āhttps://www.ipfire.org/dbl/search?q=cdn01.boxcdn.netā:
In URL Filter I have the list of āIPFire DBLā and the following are marked:
If I remove the entry from the DNS Firewall whitelist and disable āADSā from the URL Filter, it still doesnāt work correctly.
I hope this helps.
P.D.: To make everything work correctly for now (except for detecting pages I canāt access), this is what I have:
What do I do to get knot resolver to work?
I upgraded to CU203 and most everything seems to work, except name resolution. If, on my computer, I set the IP address of the name server to the (green) IP address of the IPFire device, DNS queries fail: ping 8.8.8.8 succeeds, ping google.com just hangs.
If I change the IP address my computer uses for name resolution to one of my ISPās name servers, things work as expected: ping 8.8.8.8 succeeds and ping google.com succeeds.
How is the status in DNS WUI page?
Have you defined DNS servers?
If DNS is signalled as ābrokenā, try to restart from CLI.