local DNS resolver issues

Acclaim2480

A few weeks ago back I noticed that my pfsense FW wasn't able to retrieve update information and therefore unable to do any updates. I also had some notifications about not being able to save config backups. Both appeared to be because it was unable to resolve acb.netgate.com.

I'm using unbound to run a local resolver and I had no issues with resolving anything (including acb.netgate.com) when using it from any of the devices on my network and I didn't notice any other issues at the time.

When I tried doing local lookups on the FW, the local resolver would time out. If I set an upstream public resolver, the local resolvers obviously still time out and I get an answer from the upstream resolver but it doesn't resolve the issues.

Finally I was able to figure out that lo0 interface had both 127.0.0.1 and 10.10.10.1 configured. Removing the 10.10.10.1 entry and restarting the unbound service seems to have resolved the symptoms of the issue - the FW was able to use the local resolver to resolve acb.netgate.com and retrieve the latest version info / save config backups.

This has happened a few more times without me making any configuration changes and I can't seem to correlate it to a specific event (e.g. the FW being rebooted) so I'm at a loss for what the root cause of the issue is.

I'm running the current stable version on a netgate 6100.

25.11.1-RELEASE (amd64)
built on Mon Feb 9 18:26:00 GMT 2026
FreeBSD 16.0-CURRENT

I do use pfblockerng, and that's the only thing I know has 10.10.10.1 associated with it (the redirect/injected resolution when there's a match from any of the blocklists) and that's obviously DNS related so could be related but I'm not sure how to confirm or why it began to be an issue when it wasn't before.

I did notice today that while it does resolve, doing a dig command the FW terminal, using the local resolver, I consistently get 3 time outs first but if I use a public DNS server, it works first time

$ dig acb.netgate.com
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out

; << >> DiG 9.20.13 << >> acb.netgate.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10701
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
.......<OPT & ANSWER sections omiited for brevity>.......
;; Query time: 237 msec
;; SERVER: ::1#53(::1) (UDP)

I'm not sure if this was happening before today but it's weird to me that it's resolving via IPv6 - I'd have expected IPv4 since I don't really have IPv6 enabled on my network. That suggests the timeouts could be IPv4?

This also made me recheck some things and I noticed that I'd never removed the public DNS server I'd set the first time I was troubleshooting this. When I removed it, I started having resolution issues on local devices for anything that wasn't already in their DNS cache.

That makes me think that since I first "fixed" the symptoms, it's been the public DNS server that's been used since then, even though I have set DNS Resolution Behavior to use local DNS and ignore remote DNS servers. So probably I never really fixed anything, because prior to that I had no public server set and no internet issues on local devices.

Any help would be greatly appreciated, please ask if I didn't explain something well or left our important information, and thank you for taking the time to read this.

SteveITS

@Acclaim2480 Is DNS Resolver set to listen on/use All interfaces?

Acclaim2480

@SteveITS Prior to everything I had both "network interfaces", and "outgoing network interfaces" set to All. I do remember changing outgoing interfaces to just the WAN when I was troubleshooting and I never reverted that.

I changed it back to All, and after that I was able to remove the public DNS server entry and ~~still have internet connectivity/DNS resolutions on local devices.~~ edit: I spoke too soon. Removing the public DNS server did mess up DNS resolutions for devices on the network so I had to revert that.

Thanks - good question. (I tried to upvote your post for being helpful but I don't have enough reputation...)

Looks like DNS lookups are still going through IPv6 and that IPv4 lookups time out.

johnpoz

@Acclaim2480 so out of the box pfsense would be set to resolve.. If yours is set to forward then yes you would need some external dns setup..

So in the resolver you have forwarding unchecked or checked?

Do you show unbound listening on 127.0.0.1? You can see this with either sockstat or netstat.. You might see all 0s if you have all selected.

Are you using a vpn? I have heard many a user complain about nordvpn for example doing interception of dns - this can cause problems when you resolve.. But when forwarding pfsense wouldn't know any better and think its talking to who you are fowarding too.

If you show pfsense listening on 127.0.0.1, can you query its own name? If so this shows unbound working.. If you can not resolve some external fqdn via this same sort of query.. Then sniff on your wan when you do the query.. Do you see the query go out?

[25.11.1-RELEASE][admin@sg4860.home.arpa]/root: dig sg4860.home.arpa @127.0.0.1

; <<>> DiG 9.20.13 <<>> sg4860.home.arpa @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14229
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sg4860.home.arpa.              IN      A

;; ANSWER SECTION:
sg4860.home.arpa.       3600    IN      A       192.168.9.253

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sun Mar 29 15:17:13 CDT 2026
;; MSG SIZE  rcvd: 61

[25.11.1-RELEASE][admin@sg4860.home.arpa]/root:

Clearly in such a test use your own fqdn for pfsense.

PaddraighOS

That pattern of IPv4 timeouts to 127.0.0.1 while ::1 works is usually unbound binding to the wrong interface after pfBlockerNG modifies lo0. When pfBlockerNG adds 10.10.10.1 to the loopback it can cause unbound to drop its IPv4 bind on 127.0.0.1 if it gets restarted at the wrong moment. Worth checking: Services > DNS Resolver > Advanced Settings, look at Outgoing Network Interfaces. Also run sockstat -46 | grep unbound from the pfSense shell to confirm whether unbound is actually listening on 127.0.0.1 port 53 or just ::1. If it is only on ::1, a full unbound restart rather than a reload usually fixes it: pfSsh.php playback svc restart unbound. The 10.10.10.1 on lo0 reappearing suggests pfBlockerNG is adding it back on its own reload schedule - worth checking pfBlockerNG DNSBL settings to see if it is configured to inject a virtual IP to lo0. Should sort you out.

Gertjan

@Acclaim2480

Compare this system prompt :

with the one johnpozz showed :

or mine :

[26.03-RC][root@pfSense.bhf.tld]/root:

( note : guess what : I have pfSense 26.03 RC )

My question, and the answer to all your questions : who is your "$" ?

johnpoz

@Gertjan great question, I totally missed that.