I am not sure what script you are referring to. But if it is changing any IPFire system files it might break. If you are referring to @jon’s package, he will be able to give you an answer about this.
The IPFire DNS Firewall will give you the option to maintain a custom block/allowlist, but it won’t be able to sync them to other systems. It will only support IPFire DBL lists.
You can of course use different or additional software like Pi-Hole, but I couldn’t think of a reason why that would be necessary. The builtin option is by far the strongest.
If you referring to the RPZ scripts “unofficial”, I have not tested this.
Keep in mind there is a lot of CNAME duplications if you use both that will slow down unbound (DNS). It could even cause unbound to run out of memory and crash. Not recommended.
No, this feature does not exist with the new DNS Firewall.
It is possible to add your own custom blocklist. You just have to copy and paste the list of blocked domains into the Blocked Domains section of the DNS Firewall WUI page.
It’s really good feature overall and I can easily add custom rules.
Only complain I have is with lists or how they are maintained, not really fault of IPFire team or community. Many pages have randomly stopped working because top level domain has been added to some list. Maybe some subdomain had malware, ads or tracking etc. It could also be case where same domain is used for delivering good and bad content.
Let’s take example, editmysite.com is at currently at malware list but what I know it is part of Weebly. I don’t think every page that uses Square/Weebly service is delivering malware. I had to whitelist it so one of website I visited worked correctly, otherwise navigation menu didn’t show at all because menu script was at cdn2.editmysite . com. Website was using other cdn’s too.
Also github was added to blocklist some days ago so it feels like constant battle to maintain lists to have usable internet or take it easy and don’t even bother with DNS Firewall. [tinfoil] Maybe that is someones goal to make those lists so horrible nobody uses them at all. [/tinfoil]
A similar case was presented by me on DNS IPFire incomplete list - #5 by hjkl → a domain used by Lenovo Device Orchestration (LDO) was added in blacklist despite it is in the official Lenovo Documentation for that service (and in top Akamai and Cloudflare domain lists - because so many Lenovo Devices have that software installed).
Whitelisting that domain (or google.com, or github.com) on my side is not a good option because it generates log entries every time the Lenovo machine pool checks the Device management cloud service (or Google services, or GITHUB) - that is waste in my view. For this case the best option is to remove it from DBL, and not to manually whitelist it.
The problem stems from a URL flagged as suspicious by an unknown user, which led to the entire domain being blocked.
Can just anyone get a domain blocked?
This particular case of Google.com being blocked because a Google Share link points to a phishing site should be dealt differently - block the exact URL pointing to that phishing and leave the top domain alone in the DBL.
There are services that are abused (Amazon S3 buckets, Azure ones, etc) so unless somebody understand that by their nature these domains should not be blocked, but rather the URL, we will continue to loose trust in how DBL is managed - for crying out loud, block entire Google.com because if a shared link toward a phishing site.
Thanks for that - I stopped using DBL lists. Back to Haghezi.
Some additional feedback and observations regarding the Domain Blocklists (DBL) integration, specifically around upstream source selection, data quality at ingestion, and the current feedback loop.
1. Upstream Data Quality & Downstream Impact
While using open-licensed source lists makes distribution straightforward, pulling unvetted or stale upstream feeds directly into production RPZ lists creates significant operational challenges for administrators.
As highlighted across various community testing reports, broad wildcards or unvetted entries in upstream lists have led to severe false positives affecting essential infrastructure:
Critical Service Endpoints: Domain blocks impacting google.com, github.com, and major subdomains/IP ranges across Azure or AWS or vendor specific solutions (Lenovo Device Orchestartor).
Operational Disruption: Blocking primary development endpoints or major cloud infrastructure immediately breaks CI/CD pipelines, remote services, and core network functionality for deployed instances.
2. Historical Visibility on Source Selection (dbl@lists.ipfire.org)
Looking at the public mailing list archives (lists.ipfire.org/dbl/), a few key patterns emerge regarding how source feeds are evaluated before deployment:
Missing Pre-Launch Vetting for High-Impact Categories: There is virtually no public discussion or defined vetting criteria in the archive for two of the largest, highest-volume categories: Phishing and Advertising. Given these affect nearly 100% of network traffic, the criteria for choosing these underlying sources remain opaque.
Inclusion of Unmaintained Repositories: For example, in the SmartTV category, a GitHub repository (hkamran80/blocklists) was selected based on its open MIT license. However, a quick check shows the repository has been inactive for years, carries open unresolved issues, and lacks active upstream maintenance.
When upstream sources are chosen primarily based on license availability rather than active maintenance, the burden of filtering and list maintenance is quietly shifted downstream to end users and network administrators.
3. Improving the Feedback Loop
Currently, when a list breaks live services, users are encouraged to submit reports to clean up individual domains. From an administrative perspective, this presents two main challenges:
Symptom vs. Cause: Reporting individual broken domains fixes the symptom, but it does not address a low-quality or unmaintained upstream source.
Lack of Source Metrics: Without public tracking, user reports enter a back-end queue without visibility into source-level performance (e.g., how many false positives a specific feed generates over time, or at what error threshold an upstream list is retired).
4. Suggestions for DBL
To make the DBL feature more resilient and reduce false-positive fallout on live networks, it would be extremely valuable to consider:
Ingestion Safety Belts: Automated pre-checks that reject or flag upstream feeds if they attempt to block core infrastructure (e.g., root/major search engines, public code repositories like GitHub, or major cloud provider endpoints).
Source Health Metrics: Publicly exposing basic indicators per source feed (e.g., date of last upstream commit/release, maintainer activity status, and report volume).
Clear Retirement Criteria: Establishing predefined rules for dropping upstream sources that are abandoned or consistently yield high error rates.
Has there been any further discussion on implementing intake-level safety checks or publishing source reliability metrics for DBL feeds?
I can under stand you frustration.
DBL is a massive under taking.
Making block list is a huge undertaking.
I’m sure it will improve over time.
If you see the block lists out there
Their is a shift in the companies that where backing these list to closed source.
So IPfire starting lists of its own is the only way forward.
False positives are going to happen.
Easily fixed. report. and whitelist.
I have faith that the community can built it better.
We already saw this with location database - that initiative, at least to me, started with the right premises that whatever is public has problems and the Dev team addressed those problems with a smart approach - check the peering and based on peering clarify the location of that CIDR/ASN
After seeing that approach, I can only wonder why the DBL started with stale/!veted lists and no clear metrics how to quickly vet them.
Some sources feed show an a very high rate of Dead Domains rate: Sinking Yachts
Malware DBL category does show it as one of the sources: last update: 35 minutes ago, listed domains 43,179 with a staggering 86% Dead domains.
I could not find any public reference how that list was chosen and if a vetting mechanism was used to classify it as “good to feed” one of the DBL categories.
Is the 86% dead domain rate acceptable for DBL project? Why?
Are there any thresholds where a source list no longer feeds a category?
What are the metrics used for reviewing the sources. Or the users that drop request for block/lift block (whitelist)?
If I look in the history for big cloud domains then more questions arise:
What is that domain: " cloud.microsoftis an Internet domain owned and operated by Microsoft. This domain is specifically dedicated to Microsoft cloud products and managed to the highest standards of security. It is designed to provide a single and unified home for Microsoft 365 apps and services." (copied from What is cloud.microsoft? | Microsoft Support)
How the phishing list treated it:
History
Allowed
A block was lifted by PhishDestroy - Primary Live July 31
Allowed
A block was added by PhishDestroy - Primary Live July 29
Allowed
A block was lifted by PhishDestroy July 29
Allowed
The domain was exempted by kuni bertus July 27 • Report
I really appreciate the IPFire DBL initiative and the work that has gone into integrating it with the DNS Firewall.
Since the DBL service is still marked as Beta, I think it would be useful if the DNS Firewall could also support alternative blocklist sources, ideally with the option to combine several of them.
IPFire DBL could still be the recommended and best-integrated default, while more conservative users could rely on established, actively maintained lists until DBL has matured further.
This would also give users a practical way to compare sources, handle false positives and test IPFire DBL without making it the only available backend.
This was a reply to my post in this thread. I’ve replied here as @hjkl suggested.
@bbitsch I’ve come to this discussion late. But it seems that your reply assumes that the way to create blocklists is to aggregate multiple public blocklists then remove those with high false-positives.
This seems to put quantity before quality.
I would start the other way round: pick one or two blocklists that have a reputation for low false-positives. This will accommodate most users and, importantly, get people using the DNS Firewall.
As @hjkl has pointed out, the current method seems opaque:
Why is a blocklist that hasn’t been updated for 8 months included?
What criteria are you using to include a list at all?
How are you cleansing the aggregated lists?
What is the objective: something that works for (almost) everyone or something so strict that the defaults will break and you expect people to report them?
Some exposure (or a link) to the IPFire team’s methodology for blocklists would help.
Maintaining blocklists is a big undertaking. It’s part science and part judgement, which the IPFire may not have.
I contacted the OISD maintainer (Stephan) and he replied:
OISD reduces breakage through a combination of:
carefully selecting and combining source lists;
removing domains known to cause functional problems;
processing false-positive reports from users;
testing reported domains by temporarily allowing them and checking which functionality depends on them;
being conservative with domains that are used for both tracking and essential services.
DNS blocking also has an important limitation: an exception cannot usually be limited to one website or app. A domain is either blocked or allowed globally. Therefore, when a legitimate service depends on a tracking or advertising domain, I have to judge whether blocking it causes enough real-world breakage to justify allowing it for everyone.
The large number of OISD users effectively provides broad real-world testing. When something breaks, reports usually arrive quickly, after which I investigate and adjust the list where appropriate.
So it is not a perfect automated guarantee, but an ongoing combination of source evaluation, testing, user feedback and conservative decision-making.
Stephan is clearly doing something right after years of experience and it will take the IPFire time to gain the knowledge and experience he has. That’s another reason to go for quality over quantity and to provide the ability to add custom blocklists.
I sent report to allow group46.sites.hscoscdn40.net and it should now be allowed but if I remove my custom rule it’s still getting blocked by DBL. Should i’ve sent my report for this domain instead sites.hscoscdn40.net?
Why locally allowing group46.sites.hscoscdn40.net works but not in DBL, does Custom Allow List automatically allow top level domains too?
