It is possible, but I monitor with tail -n100 -f /var/log/messages | grep --color -e rpz -e unbound and I do not see those dhcp messages.
FYI - I went through all of my logs (one year) and I can find the dhcp[3876]: Cannot find Unbound... error.
The first error is dhcp[3876]: Unbound has died.
And that happened after unbound had restarted. Still lookingā¦
unbound-dhcp-leases-bridge checks every 30 seconds for the pid of unbound.
This generates the messages
Oct 30 16:11:04 BitschCop dhcp[3240]: Checking if Unbound is still alive...
Oct 30 16:11:04 BitschCop dhcp[3240]: Unbound is alive
If the pid doesnāt exist Cannot find Unbound... is logged.
1 Like
It looks like unbound has trouble restarting and that caused the Unbound has died and Cannot find Unboundā¦ errors.
NOTE: On Oct 1, my production IPFire box was still using CU 188. On Oct 19 I updated to CU 189.
here is my message log. It looks like Unbound took a four minute nap. See the lines with the <<<<<<<<< on the right.
What Core Update were you using when you saw the DHCP / Unbound error?
I use CU189.
I remember a long reboot time after updating from CU188 and rebooting. But even a power cut and a second reboot with fsck showed any problems.
@roberto , can you find the messages in the log when unbound was killed?
I have 189 core update. Tomorrow I will search more better in Log messeges.
Thanks.
1 Like
1 Like
Thx @roberto , looking into your logs I can find some out of memory ( oom ) errors when the RPZ WUI calls unbound-checkconf. What is your memory size?
hi
This is the problem that I had seen with the black lists too much url not useful for everyone so occupation of memory for nothing no easy to manage
ty
1 Like
I have some more rpz lists activated. Disabling them all does really change the memory consumption.
The memory diagram shows percentage only, but oom is triggered by absolute values. My RAM size is 2GB.
EDIT: A test ( unbound with RPZ stuff <ā> without RPZ ) gives a difference of 300MB of free memory. Size of all .rpz files is 14MB.
1 Like
This is not good. Let me do some checking.
With Without RPZ, was the RPZ add-on uninstalled? Or was it disabled (using the checkboxes)?
This is what I currently see on my system with RPZ running:
APU4D4 with 4 GB RAM
Removed image since it is included in EDIT3 below
EDIT: I disabled all of the RPZ checkboxes and clicked Apply at 9:53 AM
Removed image since it is included in EDIT3 below
EDIT2: I uninstalled the RPZ add-on:
Removed image since it is included in EDIT3 below
EDIT3: I rebooted to IPFire device:
So I agree with Bernhard that this may be related to the Out of Memory (OOM) error.
How much RAM do you have? What type of device is IPFire running on?
1 Like
rpz.tr.zip (753 Bytes)
Uploading Turkish translation
EDIT I didnāt realizxe Jon updated to v14, my language file is still from v12
Let me know if the changes for v14 are to remove a double quote
line 16` ārpz exitcode 105ā
2 Likes
Hi guys!!!.
My machine profile is: www.ipfire.org - Profile f583b15e74e20477b02c13b05d961386153d2c35
1 Like
Thank you! That helps!
So based on 2 GB of RAM, I am guessing the RPZ lists are too big for the amount of RAM available.
The four RPZ lists picked add about > 700 MBytes to RAM. And it looks like the biggest file is ThreatintelligenceFeeds.rpz.
The ThreatintelligenceFeeds.rpz file 38,565,428 bytes in size and 1,352,947 lines.
Being over 500,000 lines long, this file alone will slow DNS. See Note 1 @ https://www.ipfire.org/docs/addons/rpz/rpzconsole#notes
I recommend to find a smaller TIF file that meets your needs.
Iāll add a note to the RPZ wiki to avoid this RPZ list since it is too large in size.
4 Likes
After deleting the entries from the Custom blocklist,
then clicking Save, then Aply
entries in the /etc/unbound/zonefiles/block.rpz file are not deleted.
2 Likes
Probably it is this case described in the documentation
RPZ zone (rpz.nlnetlabs.nl):
$ORIGIN rpz.nlnetlabs.nl.
drop.example.com.rpz.nlnetlabs.nl. CNAME rpz-drop.
32.34.216.184.93.rpz-ip.rpz.nlnetlabs.nl. A 192.0.2.1
however, this is irrelevant because IPFire is supposed to block connections to malicious domains.
Going back to the rpz file from cert.pl
- the contents of the file are in accordance with accepted standards and documentation
- it comes from a trusted source and, in addition, the list is also used by private DNS providers - quad9, dns0.eu and nextdns.io.
- the settings in the .rpz.conf files override those in the .rpz files
rpz-action-override: nxdomain. - rpz in IPFire is in the testing phase
Take a look please at the IPFire script taking the contents of the .rpz file (/etc/unbound/zonefiles/) with the list of
It is likely that the script has a problem interpreting the characters in the line $ORIGIN
[root@ipfireupgr189t zonefiles]# unbound-checkconf
[1730666692] unbound-checkconf[29135:0] error: rpz: name of record (test-rpz.hole.cert.pl.hole.cert.pl.) to insert into RPZ is not a subdomain of the configured name of the RPZ zone (certpl.rpz.)
[1730666692] unbound-checkconf[29135:0] error: /etc/unbound/zonefiles/certpl.rpz:13 cannot insert RR of type CNAME
[1730666692] unbound-checkconf[29135:0] error: error parsing zonefile /etc/unbound/zonefiles/certpl.rpz for certpl.rpz.
[1730666692] unbound-checkconf[29135:0] fatal error: Could not setup authority zones
result after commenting out the line $ORIGIN
unbound-checkconf
unbound-checkconf: no errors in /etc/unbound/unbound.conf
Best regards.
@iptom,
All of these are Unbound related RPZ errors and not RPZ add-on errors due to the RPZ list pointing to CNAME hole.cert.pl..
So I need to set this aside and I donāt have a good direction to point you. Maybe the unbound mailing list group? Or an RPZ expert? I know this is an excuse. I am really guessing here.
1 Like
@jon
Can you answer my question:
Which script(s) (in IPFire) takes data from .rpz files located in /etc/unbound/zonefiles/ folder ?
Regards