The cert.pl problem is the CNAME, I think.
The other RPZ files define a CNAME of ‘.’, the domain_rpz.db file defines ‘hole.cert.pl’.’
I don’t fully remember whether the document @jon and others refer to nor the unbound documentation. So I cannot say, how to interpret the cert.pl list.
The original documentation on the site is in polish only, and refers mainly to the file contents ( as far as I understand ).
1 Like
It is definitely the domains_rpz.db file.
I see the same error as you:
Oct 29 15:09:05 ipfire **unbound**: [27708: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 (domains_**rpz**.**rpz**.)
RPZ is expecting a few known/defined items after the CNAME. And hole.cert.pl. is not one of them.
My RPZ files look like this:
example.com CNAME .
# -or-
example.com CNAME rpz-passthru.
EDIT: I suggest not using this file with RPZ.
1 Like
I referred to https://hole.cert.pl/schema/certpl_lista_ostrzezen_api_v2.pdf found in
Information for administrators
If you want to integrate the Warning List into your security infrastructure please implement domain blocking in accordance with the points below:
- list of blocked domains should be updated every 5 minutes
- domains are put on the List for a period of 6 months, if an entry is no longer on the List or there is information about its deletion, the domain should no longer be blocked
- blocked domains should point to the records listed on https://hole.cert.pl/schema/hole.txt. Information about the scope and scale of individual campaigns allows us to better prioritize our tasks
- subdomains of domains present on the List should be also blocked - if
a.example.comdomain is on the List, then botha.example.comandb.a.example.comshould be blocked, but notexample.com.Full description of individual formats and correct implementation of the List can be found in the specification.
From reading thought the https://cert.pl/en/warning-list/ above, all of the items in the domains_rpz.db file point to one of three cert.pl servers.
I am guessing this is done so cert.pl can track bad websites and display a large red warning label (the hole.cert.pl landing page).
To me this is a bad thing and should not happen.
Extreme Example: You would not want your favorite bank pointing to some hackers website that looks just like your bank.
1 Like
Also this is not the mechanism we talk about here.
As I statet above, the goal of these project is to suppress name resultion for malicious sites.
I did a quick tes
I restored the /usr/sbin/rpz-config file
I entered and saved the list https://threatfox.abuse.ch/downloads/threatfox.rpz
I updated lines 103-105.
After refreshing the RPZ configuration page, the .rpz extension appeared.
3 Likes
Oops, in fact… sorry 
However, I would like to draw your attention to point 4.
It says that redirection is only a recommendation.
4 Landing page for blocked domains
When blocking domains, we recommend redirecting them with entry A in DNS to the address of our landing page, which contains information about possible reasons for blocking the website and a handful of security tips for end users.
IP addresses from which the landing page is served are available in the file:
https://hole.cert.pl/schema/hole.txtAddresses are subject to change in the future. The contents of the above file will be updated then.
The appearance of the landing page served by us can be checked at: https://hole.cert.pl/
We recommend directing users of blocked domains to the landing page. This will increase user awareness and at the same time enable CERT Polska to better estimate the scale of incidents of this type.
2.10 Description of the RPZ format
Service address: https://hole.cert.pl/domains/v2/domains_rpz.db
Usage: GET request via HTTPS to the listed address, without additional parameters.
Returned response: response code 200 OK; document with MIME type text/plain;The file returned from the service, intended for DNS servers supporting the DNS RPZ (Domain Name Service Response Policy Zones) mechanism, contains a list of all blocked domains included in the Warning List.
All domains included in the response should be blocked by the recipient. If a domain is not in the response it means that it should not be blocked. The file contains only active items, i.e. items removed from the Warning List are not included in it.
Malicious domains are directed to IP addresses of servers at the disposal of CERT Polska - NASK PIB.
After accessing the malicious domain, the user is shown a “landing page” containing information that the site poses a threat, and that the domain in question has been blocked based on the Warning List.
Translated with DeepL Translate: The world's most accurate translator (free version)
Thx for your effort of translation. But this assures jon’s assumption. The list tries to redirect to CERT Polska. This is not the behaviour we will implement.
Therefore this list isn’t suitable for the RPZ project.
I am curious, How is this implemented?
1 Like
Hey folks,
I tried the addon and it works for me with the Hagazi blocklist just fine.
But I had a question, do any of you have problems with the DNS Forward option? I installed and tested the addon beforehand and only then set up a DNS Forward.
Does anyone else have the problem, or can someone confirm that the addon works with the DNS Forward option?
I have described here how I discovered the problem, but it has nothing to do with the addon, I am currently trying an exclusion procedure.
Thank you!
I do not use DNS Forward or Squid proxy. And there are no issues I have heard of. Hopefully someone else will stop by and assist.
You may want to add some details to the other post about what you have setup in DNS Forward. Basically a screenshot of this:
that will help others to answer.
1 Like
here is the latest:
rpz-beta-0.1.14-14.ipfire on 2024-10-29
rpz-config:
- bug:
rpz-config listdisplayed URL incorrectly (thank you Bernhard)rpz.cgi:
- bug: remove extra " (a double quote) in language files (thank you Bernhard)
- feature: slightly dim “apply” button when not enabled (thank you Leo)
rpz-beta-0.1.14-14.ipfire.tar (40 KB)
2 Likes
Are there any errors in /var/log/messages, tag [unbound]?
In messages:
Oct 30 15:24:25 bs dhcp[6496]: Cannot find Unbound...
Oct 30 15:24:26 bs dhcp[6496]: Cannot find Unbound...
Oct 30 15:24:26 bs unbound: info: rpz: run "unbound-control reload"
Oct 30 15:24:26 bs unbound: error: rpz: unbound-control reload. exit.
Oct 30 15:24:27 bs dhcp[6496]: Cannot find Unbound...
Only this.
Saludos.
It is a bit scary that something broke the DNS Servers. It could be one of the RPZ lists. Disable (uncheck box on the right) all four lists and click Apply. Does DNS Server work?
The command that generated the:
RPZ Error: Error al recargar unbound-control
RPZ Error: Error reloading unbound-control
. . . error is unbound-control reload
From the console/terminal go ahead and run the command and then post the results. I normally see:
[root@ipfire ~] # unbound-control reload
ok
[root@ipfire ~] #
Also, I watch the message log with:
tail -n100 -f /var/log/messages | grep --color -e rpz -e unbound
and that will show the errors related to RPZ and unbound.
1 Like
I also think, there must be some other problem with unbound.
I added the SpamHaus list from your example. No problems.
1 Like
If you want to debug, find the beginning of the dhcp[6496]: Cannot find Unbound.. in the message log and post items near there related to DHCP, Unbound and RPZ.
If not, you may want to disable the four RPZ lists and then reboot the IPFire box.
1 Like
I fear the dhcp messages are generated by the periodic check for Unbound by the unbound-dhcp-leases-bridge.