New DNS Firewall appears not to be working

[pscar13 (Phil SCAR)]

@alexand

Generally, I’m not a fan of this setting: drop (default firewall behavior outgoing).

Default firewall behavior forward: drop - that’s fine for me.

It’s your choice.
That’s not the point of this discussion thread.
But IPFire allows for many possible configurations; there are no strict rules, only recommendations.

www.ipfire.org - Firewall configuration recommendations for IPFire users

[jon]

@rjschilt

DBL appears to be working now with several TLS Name Servers enabled / active:

Glad you got it working.

These type of messages point to something blocking the xfr.dbl.ipfire.org server:

@rjschilt

May  5 13:45:19 ipfire unbound: [3625:0] info: start of service (unbound 1.24.2).
May  5 13:45:19 ipfire unbound: [3625:0] error: SERVFAIL <xfr.dbl.ipfire.org. A IN>: exceeded the maximum number of sends
May  5 13:45:19 ipfire unbound: [3625:0] error: ads.rpz.ipfire.org.: failed lookup, cannot probe to master xfr.dbl.ipfire.org
May  5 13:45:19 ipfire unbound: [3625:0] error: piracy.rpz.ipfire.org.: failed lookup, cannot probe to master xfr.dbl.ipfire.org
May  5 13:45:19 ipfire unbound: [3625:0] error: malware.rpz.ipfire.org.: failed lookup, cannot probe to master xfr.dbl.ipfire.org

And these messages point to a misconfigured firewall rule:

So deleting the misconfigured firewall rule helped big time!

---

EDIT: What did you want the firewall rule to do?

@rjschilt

Based on what I can see in the screenshot, the rule isn’t needed.

[rjschilt (Robertus Mechanicus)]

[rjschilt (Robertus Mechanicus)]

@jon - I need this firewall rule so that outgoing traffic can reach the IPFire DBL Server at 81.3.27.55.

Interesting, I’m now seeing the following in the unbound cache - note that some of the lists I selected are not showing - meaning something still aint working properly.

[root@ipfire ~]# ls -lah /var/cache/unbound
total 232K
drwxr-xr-x 2 nobody nobody  112 May  5 16:03 .
drwxr-xr-x 8 root   root    102 Apr 21 23:13 ..
-rw-r--r-- 1 nobody nobody 179K May  5 16:03 piracy.rpz.ipfire.org.zone
-rw-r--r-- 1 nobody nobody  23K May  5 16:03 smart-tv.rpz.ipfire.org.zone
-rw-r--r-- 1 nobody nobody  26K May  5 16:03 violence.rpz.ipfire.org.zone
[root@ipfire ~]# 

[alexand (Alexander)]

I suggest temporarily changing the default firewall behavior outgoing from drop to allow.
The consequence of the default firewall behavior outgoing drop is blocking all outgoing communication from IPFire.
This requires analyzing the traffic and creating appropriate rules manually.
If there are any references to the fqdn, it’s difficult to control.
This is, of course, my opinion; you can do whatever you want.

[pscar13 (Phil SCAR)]

I use the same settings and the IPFire DNS Firewall works fine.

Core 201 Test: DNS Firewall - Adding an iptables rule for primary.dbl.ipfire.org

I’m using the old rule to force the use of IPFire’s DNS. To do this, I created a DNS service group [Capture d'écran 2026-03-13 114132] A rule to redirect DNS requests to IPFire [Capture d'écran 2026-03-13 114243] A group of allowed DNS resolver addresses [Capture d'écran 2026-03-13 114206] And a rule to allow access to these servers for DNS. [Capture d'écran 2026-03-13 114327] Finaly : I choose the DNS servers I want to activate on the dns.cgi page. [Capture d'écran 2026-03-13 11521…

There must be something else blocking it.

[rjschilt (Robertus Mechanicus)]

Thanks @pscar13 - I’m going to do what @alexand is suggesting to temporarily relax my outgoing rules - this way I’ll be able to determine if it’s my rules that are preventing DBL from working properly -or- if there’s something more sinister at play here.. When I find some time I will follow through with this and report back.

[jon]

@rjschilt

I’m going to do what @alexand is suggesting to temporarily relax my outgoing rules - this way I’ll be able to determine if it’s my rules that are preventing DBL from working properly

I would guess this ^ more than the sinister.

Keep monitoring the firewall logs @ https://ipfire.localdomain:444/cgi-bin/logs.cgi/firewalllog.dat and the cache at @ ls -lah /var/cache/unbound. As someone else mentioned, it could take a few minutes to download a new zone file into that cache folder. (I’ve never had it take an hour but it may be possible)

---

After changing a Firewall Rule and instead of waiting for the cache to load, you can do a quick ping test:

ping xfr.dbl.ipfire.org

or if you have nmap loaded as a pakfire add-on, then try:

nmap -sU -sT -p 53 xfr.dbl.ipfire.org

[pscar13 (Phil SCAR)]

If you are behind CG-NAT redirect DNS maybe the problem see

Title: DNS Firewall RPZ zones return REFUSED for all clients when AXFR from primary.dbl.ipfire.org is denied (e.g. CG-NAT) Component: DNS Firewall / Unbound Version: IPFire 2.29 Core Update 201

Summary: 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…

Try

dig @81.3.27.55 ads.rpz.ipfire.org AXFR

[rjschilt (Robertus Mechanicus)]

Thanks @pscar13 - I ran that command and the output is rather long but always ends the the following two lines:

;; communications error to 81.3.27.55#53: end of file
;; no servers could be reached
[root@ipfire ~]# 

This suggests that the issue could be because I’m sitting behind a CG-NAT -or- the firewall rules I have configured are too strict and I need to relax my outgoing rules a little - sorry, but I have not had any time to followup on either suggestion.

Implementing IPF DNS DBL is proving to be much more of an effort than what I had originally planned - mind you I’m not giving up but need to push further investigation / diagnosis down the priority list. I’ll come back to this when I have some spare time and feeling motivated enough.

[rjschilt (Robertus Mechanicus)]

Thanks @jon,

Implementing IPF DNS DBL is proving to be much more of an effort than what I had originally planned - mind you I’m not giving up but need to push further investigation / diagnosis down the priority list. I’ll come back to this when I have some spare time and feeling motivated enough.

[kazzamar (Lincoln P)]

@roberto I had the same issue I managed to get a work around which i have added to my post.

DNS Firewall: Timeout while downloading large zones

Hi Guys Upgraded to Core 201 and tried to get DNS Firewall to replace my Adguard but not having much luck. I can get the zones: Dating Smart-TV Violence Piracy To download zones files and block content but the larger zones never download the zones files into /var/cache/unbound/ I have run a few dig commands to see if I can get them to download manually but they always exit with ;; Communications error to 81.3.27.55#53: end of file ;; no servers could be reached it will get the first 3759…

Try this and let me know how many lines it downloads for you as it always only downloads 3766 lines for me does not seem to matter if i use my home network or my work network so it looks like it is a rate limit some were.
`dig @81.3.27.55 ads.rpz.ipfire.org AXFR | wc -l`

[rjschilt (Robertus Mechanicus)]

Thanks @kazzamar, I will take a closer look at your suggestions and post when i have more time.

[rjschilt (Robertus Mechanicus)]

Hi @kazzamar and @jon and @pscar13 and @alexand and @bonnietwin,

I’m having another shot at this and despite relaxing all my IPF firewall rules (meaning all outbound traffic now allowed) the /var/cache/unbound refuses to populate:

[root@ipfire ~]# ls -lah /var/cache/unbound
total 0
drwxr-xr-x 2 nobody nobody   6 May  7 19:28 .
drwxr-xr-x 8 root   root   102 Apr 21 23:13 ..
[root@ipfire ~]#

When I say I relaxed my firewall rules I mean it - all rules disabled and default firewall rules totally relaxed:

When I run the dig command you suggested I get the same count each time - I’m on a 500/50 good performing fiber connection:

[root@ipfire ~]# dig @81.3.27.55 ads.rpz.ipfire.org AXFR | wc -l
11291
[root@ipfire ~]# 

When I run the following command:

[root@ipfire ~]# dig @81.3.27.55 porn.rpz.ipfire.org AXFR

(a very log list of URL's and always finishes with the following lines)

royalasians.com.au.porn.rpz.ipfire.org.	60 IN CNAME .
*.royalasians.com.au.porn.rpz.ipfire.org. 60 IN	CNAME .
rubber.com.au.porn.rpz.ipfire.org. 60 IN CNAME	.
*.rubber.com.au.porn.rpz.ipfire.org. 60	IN CNAME .
;; communications error to 81.3.27.55#53: end of file
;; no servers could be reached

I have a single DBL list enabled for testing purposes - my machine is in the Green Zone.

Furthermore - for the sake of troubleshooting further - I have:

• Disabled IPS / Suricata totally
• Disabled all IP Address Blocklists
• Web Proxy turned off
• Restarted and rebooted IPF

… to no avail - IPF DNS Firewall refuses to work.

Note that all the IPF configuration I have done has always been via the Admin WUI panel and never command line changes under the hood.

I’ll leave my IPF in a relaxed / open state for a day or so (in case anyone reading this has any last minute suggestions) and then I’m reverting my configuration back to a strict state like it was before.

Whilst I’m happy to rebuild my IPF I’m not 100% convinced that a rebuild will fix the issue.

[pscar13 (Phil SCAR)]

Apparently, it’s the same problem @kazzamar mentioned above.

Do you know if your internet address is behind a CG-NAT?

[jon]

@rjschilt

I’ll leave my IPF in a relaxed / open state for a day or so

Please double check the Firewall Rules one more time to make sure all is disabled and Apply Changes is clicked.

---

I ask because I saw this (see quote below) and so things appeared to be “hopeful” for a few minutes on May 5 at 16:03 when three zones downloaded.

@rjschilt

Interesting, I’m now seeing the following in the unbound cache - note that some of the lists I selected are not showing - meaning something still aint working properly.

[root@ipfire ~]# ls -lah /var/cache/unbound
total 232K
drwxr-xr-x 2 nobody nobody  112 May  5 16:03 .
drwxr-xr-x 8 root   root    102 Apr 21 23:13 ..
-rw-r--r-- 1 nobody nobody 179K May  5 16:03 piracy.rpz.ipfire.org.zone
-rw-r--r-- 1 nobody nobody  23K May  5 16:03 smart-tv.rpz.ipfire.org.zone
-rw-r--r-- 1 nobody nobody  26K May  5 16:03 violence.rpz.ipfire.org.zone
[root@ipfire ~]# 

Also, is there anything in the firewall.local file?

cat /etc/sysconfig/firewall.local

firewall.local

[pscar13 (Phil SCAR)]

Based on the similar issues previously mentioned by @kazzamar and @garfield3333 above, it seems the data transfer via AXFR is being blocked by the DNS upstream of the Red interface (ISP WAN).

But I don’t know how to explain or resolve it.

Perhaps the IPFire team has more expertise on this?

[bbitsch (Bernhard Bitsch)]

The given commands do have some problems.
If I run dig @81.3.27.55 ads.rpz.ipfire.org AXFR >ads.txt I get the whole file without problems. The messages of dig inside the file show success of the operation.
The versions without file redirection show the error / less lines.

[pscar13 (Phil SCAR)]

Here is the response I get with a init test IPFire server with the RED NIC plugged behind the GREEN of my production IPFire server which has a DNS redirection (Double NAT).

[root@ipfireTest ~]# dig @81.3.27.55 ads.rpz.ipfire.org AXFR

; <<>> DiG 9.20.20 <<>> @81.3.27.55 ads.rpz.ipfire.org AXFR
; (1 server found)
;; global options: +cmd
; Transfer failed.

And the TCPDUMP trace

No.	Time	Source	Source port	Destination	Destination port	Protocol	Length	Info
52	2026-05-07 19:32:42,597086Z	192.168.20.120	39803	81.3.27.55	53	TCP	74	39803 → 53 [SYN] Seq=0 Win=42700 Len=0 MSS=1220 SACK_PERM TSval=2766016587 TSecr=0 WS=512
53	2026-05-07 19:32:42,597244Z	81.3.27.55	53	192.168.20.120	39803	TCP	74	53 → 39803 [SYN, ACK] Seq=0 Ack=1 Win=43440 Len=0 MSS=1460 SACK_PERM TSval=1253020110 TSecr=2766016587 WS=512
54	2026-05-07 19:32:42,597782Z	192.168.20.120	39803	81.3.27.55	53	TCP	66	39803 → 53 [ACK] Seq=1 Ack=1 Win=43008 Len=0 TSval=2766016588 TSecr=1253020110
55	2026-05-07 19:32:42,597782Z	192.168.20.120	39803	81.3.27.55	53	DNS	127	Standard query 0x25a9 AXFR ads.rpz.ipfire.org OPT
56	2026-05-07 19:32:42,597991Z	81.3.27.55	53	192.168.20.120	39803	TCP	66	53 → 39803 [ACK] Seq=1 Ack=62 Win=43520 Len=0 TSval=1253020111 TSecr=2766016588
57	2026-05-07 19:32:42,598326Z	81.3.27.55	53	192.168.20.120	39803	DNS	127	Standard query response 0x25a9 Refused AXFR ads.rpz.ipfire.org OPT
58	2026-05-07 19:32:42,598668Z	192.168.20.120	39803	81.3.27.55	53	TCP	66	39803 → 53 [ACK] Seq=62 Ack=62 Win=43008 Len=0 TSval=2766016589 TSecr=1253020111
59	2026-05-07 19:32:42,599244Z	192.168.20.120	39803	81.3.27.55	53	TCP	66	39803 → 53 [FIN, ACK] Seq=62 Ack=62 Win=43008 Len=0 TSval=2766016589 TSecr=1253020111
60	2026-05-07 19:32:42,599592Z	81.3.27.55	53	192.168.20.120	39803	TCP	66	53 → 39803 [FIN, ACK] Seq=62 Ack=63 Win=43520 Len=0 TSval=1253020112 TSecr=2766016589
61	2026-05-07 19:32:42,600054Z	192.168.20.120	39803	81.3.27.55	53	TCP	66	39803 → 53 [ACK] Seq=63 Ack=63 Win=43008 Len=0 TSval=2766016590 TSecr=1253020112

[bbitsch (Bernhard Bitsch)]

Seems a problem of double NAT.
But @rjschilt, @kazzamar et al. get some content.
The redirect version of the dig command line seems to get all.