Unbound issue when set in resolving mode (pfSense Plus - crashing?)
-
I have a pfSense setup with following configuration related to the problem I have:
- Unbound used as DNS resolver
- pfBlockerNG installed, active and set in python mode
- Firewall rules to redirect client DNS queries to pfSense (i.e. no bypass allowed)
- pfSense connected to a modem via PPPoE (legacy driver in use)
I happily used pfSense set with internal DNS resolution as primary and back off to external DNS resolver (default setting), but since a while (I can't track down if happened across a version change or a setting change) it happens pfSense stops resolving DNS queries leading to websites being unreachable.
If I restart unbound service it starts working again for 3-4h, then it happens again.
If I set unbound in forwarding mode and pfSense general config to ignore local DNS resolution everything works fine for weeks.I inspected unbound logs but without any luck (maybe due to limited understanding) finding nothing suspicious.
pfSense is plus version, running on a VM in proxmox.
Can anyone have any hints of what is going on or can suggest further info I can provide/search to understand the issue?
-
hmm sounds familiar. can you post the Logs?
Do you use KEA for DHCP ?- General Log
- DNS-Resolver Log
- DHCP Log
can you manually restart the unbound (via webgui) or do you have to restart the system ?
-
@m80s said in Unbound issue when set in resolving mode (pfSense Plus - crashing?):
pfSense is plus version
25.07.1 ?
That means that you and me use the same binaries, our programs, libraries, kernel drivers etc are all identical.
To make live easier : let's presume your CPU, RAM etc are ok.
What's left to check ?
I see two points :
You've added a layer of abstraction for your own convenience : a VM, which is a system that is, by itself, way bigger as 'pfSense'. Bigger system = more chances something goes wrong. A solution to exclude the VM as an issue : exclude de VM.
The difference between a work DNS (unbound) and a not working DNS is most often : the settings. Not only the DNS settings, but also, for example, what interfaces are used.Btw :
@m80s said in Unbound issue when set in resolving mode (pfSense Plus - crashing?):
If I set unbound in forwarding mode
Forward : instead of sending the DNS requests to one of the official DNS Root name servers - this is called resolving, you send DNS request to another resolver.
Both modes do more or less the same : sending requests to a remote server.
I'm very sure that this works very well, as millions of copies of unbound do this a thousand time per second for many years now ^^If you want that unbound tells you more about what it is doing, you can ask it to do so.
For example :
Be ware : this new log should be a temporary settings as higher log levels produce more logs lines. For example, the query level produces log line for every incoming (from pfSense, or one of your LANs) DNS request.
@m80s said in Unbound issue when set in resolving mode (pfSense Plus - crashing?):
ignore local DNS resolution
Can't happen ^^
Resolving : Example : www.facebook.com :
First : unbound contacts one of the big 13 (the root name servers), probably the closest or fastest one, and ask it if it has an IP of the Top Level Domain server (TLD) that handles the dot com's (.com). Of course it has one nearby for you, and thousands exist.
Now it has the TLD server IP that handles the com top level domain, it will ask this server if it can give all de domain name servers IPs (at least 2) of "facebook.com". The TLD hands over the list of all these facebook domain name servers.
Now unbound picks one of the domain name servers, and asks it : what is the IP of "www.facebook.com". The answer comes back, and unbound sends this answer to the device that request "www.facebook.com".
As you can see, you can not resolve locally. A contact with at least 3 different remote servers is needed.
Also : the list with the 13 root servers is build into unbound. their IPs never change.
All other answers are cached !! So a fist resolve might take some time (many ms) but subsequent requests will be served out of the local cache right away, as long as the answer is TTL permitted. -
Hi,
thank you very much for your hints!
I switched back DNS resolver to "no forwarding mode" and using local resolution: while doing so I noticed Kea had DHCPv6 activated for local LAN which I really don't need and disabled.Not sure if it solved the issue but so far (4days) no issue: I will see how it goes.
Also I had 250Mb of cache size for DNS resolver with default setting being 4Mb: i moved it to a more reasonable 10Mb.
I will keep you updated
-
So it lasted longer without issue but out of the blue it stopped responding again.
Unluckily I couldn’t debug when happened so I don’t have further info to share.
I will try again to make it happen and see what I get from the logs
