DNS unresponsive to clients
-
Just to be sure :
grep 'start' /var/log/resolver.log
Ho many per day ? hour ? or even minute ?
pfBlockerng and 'DHCP registration' are just two possible 'unbound re-starters'.
If 'any Interface' on pfSense, to which unbound is bound, goes down and/or up, unbound restarts also.
There are probably other reasons ... I don't know them all.Example : recently, some one noticed that unbound restarted often.
At the end we discovered that he uses a direct LAN cable from his PC to the LAN interface, and his PC went to sleep every xx minutes, thus pulling the LAN NIC down.
The solution was : add a switch.And then there is the issue that others have seen : forwarding to x.x.x.x (using IPv6 ?) makes unbound not happy - fail ....
I'm test-driving unbound right now, forwarding to 9.9.9.9 and the IPv6 equivalent, using TLS, and all goes well ....
I've been forwarding to the 1.1.1.1 family for weeks : I've nothing to declare. -
@gertjan Thank you for suggestions. You talking very good points.
There are just so many cases of Unbound restarting that it maybe difficult to point out. Like the case you mentioned about the PC is directly connected to pfsense box. This could be my case. However, I donโt see a reason why this would force Unbound restarts.I moved on and restored my original configuration. These are just few advantages I see running DNS separate from the firewall.
- No restarts (pfsense+ related)
- efficient DNS cache
- easy maintenance
- compile and install new versions on demand
I implemented my own ads/malware blocking with RPZ - I use the same DNSBL feeds that pfblockerng is using. When one any DNSBL feed gets updated Unbound does not need to be restarted. Rather you can issue command "unbound-control auth_zone_reload file".
-
@markster said in DNS unresponsive to clients:
PC is directly connected to pfsense box. This could be my case. However, I donโt see a reason why this would force Unbound restarts.
If the PC hibernates or shuts down pfSense sees this as an interface up/down event and restarts multiple services, to see the new/unsee the old interface.
I'm not saying you're having a problem, or that your solution won't work, but it's not normal for unbound to restart without a reason. If unbound was crashing it would not restart on its own.
Shell Output - unbound-control -c /var/unbound/unbound.conf status version: 1.17.1 ... uptime: 3166788 seconds
...so ~36 days which was when I made the last config change on that router.
-
@steveits said in DNS unresponsive to clients:
uptime: 3166788 seconds
nice - if I didn't always make changes to help users showing how to do something ;)
I'm only at 83 hours ;)
uptime: 299808 seconds
-
@johnpoz said in DNS unresponsive to clients:
if I didn't always make changes to help users showing how to do something ;)
Here.
Every 'dip' is a restart.
Now, I'm even forwarding to quad9.
Still waiting for it to fail. -
@gertjan I decided, as a last resort try to start from default setting. Reset the box to default and re-entered the rules. Took me a while but now all its working as designed/intended.
My Interfaces are set to include only local+localhost. Outbound is set to ALL.
Tested the configuration by rebooting netgate 5100
and also Disconnect/reconnect clients. Unbound did not restarted. -
@markster After running this config DNS started again to restart caused by dhcp renewals. I also noticed that for many cases Unbound get restarted were it does not need to be.
Cases like chaning a setting in General->DNS Resolution; or
chaning Advanced option in Unbound. These could just call unbound-control reload.Someone on this forum has mentioned that many of these issues have been fixed in OPnsense. The issue with DHCP leases restarting DNS is for me a mind twister. It does not need to happen.
Unfortunalty it looks like it is a big issue to fix, I suspect that there are just some many dependencies that no one wants to touch it. Sad.
I am in the situation that I have a NAS box and I can run Unbound in a docker. This is my "solid" solution. I wanted to test Unbound on my pfsense 5100 but I will not spend more time trying to get things working (unpredictable), in effect this should be working perfectly out of the box. After all DNS is such a important part of any network. I cannot understand why Netgate and pfsense developers does not think that way.
-
@gertjan said in DNS unresponsive to clients:
pfBlockerng and 'DHCP registration' are just two possible 'unbound re-starters'.
If 'any Interface' on pfSense, to which unbound is bound, goes down and/or up, unbound restarts also.As an aside, DNS Resolver on my system is not restarted due to pfBlockerNG.
As for an interface going down, yep - got that T-shirt. I've been minded to change the 'All' bind to just my LAN interfaces to avoid a Resolver restart when my WAN link goes down / up again.
๏ธ
-
@robbiett said in DNS unresponsive to clients:
LAN interfaces to avoid a Resolver restart when my WAN link goes
I bind my outgoing to loopback.. That never goes down ;)
And why would you have it listen on your wan? You serving up dns off your wan interface? When it talks outbound, that traffic would be natted to your public IP anyway, etc.
-
@johnpoz said in DNS unresponsive to clients:
And why would you have it listen on your wan? You serving up dns off your wan interface? When it talks outbound, that traffic would be natted to your public IP anyway, etc.
That was my thought too. As to why it included WAN - well that is the default set in pfSense.
localhost makes much more sense and what I had set on previous non-pfSense routers.
๏ธ
-
@robbiett I think they have it listen on all as default because you never know what users might setup, or add etc. so with all its a given that it will listen on all interfaces..
But you could prob have a discussion about outbound default to localhost...
-
@johnpoz Setting the actual network interfaces for my 3 LAN/VLANs didn't go so well:
๏ธ
-
@robbiett where is your local host in your listen?
Its hard to see can you not expand that box?
-
@markster https://redmine.pfsense.org/issues/5413
(Hope towards the bottom) ;) -
@johnpoz said in DNS unresponsive to clients:
@robbiett where is your local host in your listen?
Its hard to see can you not expand that box?Small walk of shame for me as I didn't know the box could be simply dragged to expand it.
[Using Safari in screenshot]
๏ธ
-
@johnpoz said in DNS unresponsive to clients:
I bind my outgoing to loopback.. That never goes down ;)
And why would you have it listen on your wan? You serving up dns off your wan interface? When it talks outbound, that traffic would be natted to your public IP anyway, etc.
@johnpoz Just to say thank-you and that I set my resolver as per your advice:
๏ธ
[yes, I nearly forgot about it...]
-
For these two images - what about this one :
Trust your firewall.
Do not trust the admin.Select for both : "All", save, apply, and call it a day.
Netgate delivered pfSense with the "both All" selected and said : that's "ok and save and useful".
Nowhere they say that you need (have to) to modify it.If doubt : Contact Netgate and try to learn them 'networking'
( and please, tell us how that went ) -
@Gertjan said in DNS unresponsive to clients:
Nowhere they say that you need (have to) to modify it.
If doubt : Contact Netgate and try to learn them 'networking'
( and please, tell us how that went )Dude, I followed sensible advice from @johnpoz. I don't need to bother Netgate - they put the option in their documentation:
The network interface(s) to which the DNS Resolver will bind when listening for queries from clients.
By default the DNS Resolver listens on every available interface and IPv4 and IPv6 address. This option limits the interfaces where the DNS Resolver will accept and answer queries. This can be used to increase security in addition to firewall rules.
๏ธ
-
@Gertjan said in DNS unresponsive to clients:
Nowhere they say that you need (have to) to modify it.
Nope nothing saying you need to modify it.. You do you - if you like all, then use all.. Is that the most secure setup or best optimal setup? What I would say is its the "safest" setup for when yo don't know what the network setup will actually be.. So its a valid "default" setup.