The IPFire DNS Firewall configures Unbound RPZ zones with primary: primary.dbl.ipfire.org in dnsbl.conf. When Unbound cannot complete a zone transfer (AXFR) from this primary — for example because the installation is behind CG-NAT and the source IP is not authorized — Unbound returns REFUSED for all queries matching domains in those zones, instead of falling back to the locally cached zone file.
Steps to reproduce:
Run IPFire behind CG-NAT (no dedicated public IP)
Enable any DNS Firewall category (e.g. Advertising)
Query a domain that should be blocked: dig @192.168.178.1 pagead2.googlesyndication.com
Result: REFUSED instead of NXDOMAIN
Expected behavior:
Unbound should serve the locally cached zone file (/var/cache/unbound/*.zone) when AXFR from the primary fails. The zone files are downloaded and kept up to date by IPFire’s own update mechanism independently of AXFR.
Actual behavior:
AXFR from primary.dbl.ipfire.org returns only the SOA record (transfer denied). Unbound then treats the zone as non-authoritative and returns REFUSED for all matching queries. The local zone file is ignored.
Evidence:
$ dig @81.3.27.55 ads.rpz.ipfire.org AXFR | head -5
ads.rpz.ipfire.org. 60 IN SOA primary.dbl.ipfire.org. ...
# (only SOA returned = AXFR denied)
$ dig @192.168.178.1 pagead2.googlesyndication.com
;; status: REFUSED
/var/log/messages:
unbound: error: SERVFAIL <primary.dbl.ipfire.org. A IN>: misc failure
Workaround:
Comment out primary: primary.dbl.ipfire.org in /etc/unbound/dnsbl.conf — Unbound then loads only the local zone file and all zones work correctly.
Fix suggestion:
Either remove the primary: directive from dnsbl.conf entirely (zone files are already managed by IPFire’s update scripts), or add fallback-enabled: yes if supported by the Unbound version, so AXFR failure gracefully falls back to the local zone file.
let’s have a look why you cannot fetch the zone. We don’t have any restrictions on the primary server whatsoever. There are not ACLs, and there is no rate-limiting.
However, I noticed that enabling all lists in the DNS firewall significantly increased the RAM usage. On a machine with 8GB of RAM, 61% of the RAM was used.
Perhaps related, I too am getting REFUSED repsonse when attempting to fetch RPZ files.
First, I can successfully fetch the files from my operational system using commands like:
dig axfr @xfr.dbl.ipfire.org ads.rpz.ipfire.org
However, when I do the same sort of command on my test system, I get the REFUSED response. Note, my test system sits downstream from operational system on my home network. My operational system redirects traffic for port 53 to local and uses TLS/853 for DNS lookups.
[Edit] The actual response on the console looks like this:
; <<>> DiG 9.20.20 <<>> axfr @xfr.dbl.ipfire.org ads.rpz.ipfire.org
; (1 server found)
;; global options: +cmd
; Transfer failed.
I am running next/a85c4ef9 on the test system.
Here is the tcpdump output I captured while attempting to do the fetch:
[Edit2] My operational system sits downstream from an external router. So, consequently my traffic gets double NATed. The traffic at the further downstream test system is getting triple NATed
If you have a system redirecting traffic to a different server, this would explain it. The zone transfer cannot be proxied through another DNS server. You need to have direct access to the IPFire DBL service to pull the zone from.
