Dns resolver problem
-
Hello I don't understand why but if I enable those two items, navigation, or rather the resolution of the dns becomes very slow, sometimes I have to refrash the page to open it correctly.
in fact, if I disable them, navigation returns fast.
what can i do to fix it? -
You appear to be running the pfBlockerNG package (likely with DNSBL enabled).
When you check the DHCP Registration box, each time a DHCP client of the firewall renews its lease the
unbound
DNS Resolver will be restarted so it will read the DHCP leases file again (to obtain IP to hostname info).With DNSBL and large block lists enabled, it can take quite some time for
unbound
to restart. During the restart interval your system has no DNS functionality. LAN clients will see that as a sort of loss of connectivity because no domain name to IP resolution can happen.Some LAN devices (particularly smart home gadgets) will renew their DHCP lease quite often resulting in frequent DNS restarts. pfBlockerNG will also restart
unbound
each time it updates a downloaded list. Taken together these instances can result in a lot ofunbound
downtime.Until the pfSense developers rework the way dynamic DHCP hostnames are handled, it is best to leave the DHCP Registration box unchecked.
-
@bmeeks Thank you so much for your professional response.
Now at least I know the reason why everything slowed down.Thanks again
-
Because you're using pfBlockeng, activate the 'python' mode.
Right now, you saw that the resolver is often unavailable - and for a rather long duration.
You understand it now : You did everything to create this situation, and to make the worse of it ;)
This option :
is by default not activated. '...... for reasons ....' (see the other 1000+ forum posts about the subject.
You can activate it - and nothing will happen if you use one or two LAN devices, and all using Static IP settingsThis means there won't be any DHCP "leases" activity.
Or use Static MAC DHCP leases for all your devices.
This issue is being redesigned and rewritten right now, and soon, "DHCP Registration" won't have the 'resolver restart issue" any more.This option :
can be activate without any consequences.
Static leases are read when the system start - or when, you (the admin) add/remove/modify one.
That's normally a very rare event. -
@Gertjan and this how should i configure them?
-
Python Control : Click on the
and read.
If you say : "hey, I need that", then activate it.
No nasty side consequences afaik.TLD Allow / IDN Blocking : like salt and pepper : add according to your taste.
Regex blocking : be careful : very powerful and aggressive blocking. If the word 'regex' doesn't mean anything to you, stay away.
NoAAAA : if you want to force IPv4 to certain hosts.
Group Policy : These IPv4/IPv6 will not be filtered. Like : your PC isn't DNSBL filtered, everybody else (not listed) : they will be filtered.
-
@Gertjan hi all clear, thanks again, for solving my problem.
one question, but is it possible to associate a web page that informs that the site has been blocked by pfsense? just to figure out who blocked what? -
why?
-
As you've discovered, "DHCP Registration" restarts unbound (the resolver) 'all the time'.
This was creating severe issues- memory loss, restart problems etc.This was somewhat resolved with latest pfBlockerng and latest pfSense (23.05).
Make life easy on yourself : "DHCP Registration" => do not activate it.@wifi75 said in Dns resolver problem:
one question, but is it possible to associate a web page that informs that the site has been blocked by pfsense? just to figure out who blocked what?
That's what
is all about.
But ...... here it comes : this only works for http:// access.
Not https://.....
Better yet : you don't want it to work for https://....So, again :
@wifi75 said in Dns resolver problem:
one question, but is it possible to associate a web page that informs that the site has been blocked by pfsense? just to figure out who blocked what?
This was working just fine in the good old days, when there was http://....
These days, http://.... is being abandoned fast - and in most case even impossible : there won't be any http:// site anymore very soon.
edit : and if you find one, run. Don't look back, run away from it. Don't go there. See it as driving on the wrong side of the road : it's, for a short moment' thrilling .... interesting .... strange .... and then your live stops.test for yourself : connect to your bank using http://
facebook.com
twitter.com
etc etc etc.Did it work ?
Noop, of course not.Google doesn't even index http://, for many years now.
Now : the same question again :
If you could intercept https:// traffic, your neighbor could do also.
Your ISP.
All 3 letter agency could do also.
Etc.Again : that's what you want ?
So, final words : having a nice page showing the user that he wanted to visit a blocked web site is impossible.
-
@Gertjan said in Dns resolver problem:
showing the user that he wanted to visit a blocked web site is impossible
Never say that ;)
But yeah its pretty freaking difficult to do with https, you would have to generate on the fly a cert that matches where he was wanting to go www.somewhere.tld and also that browser would have to trust the CA that created said cert on the fly.
And if the site was using something like pinning, and he had been there before - again he prob going to scream at you that this cert isn't right, etc.
If it was easy it would really break the whole end to end trust thing ;) its not impossible but yeah the client is doing everything it can to know that the https connection is trusted and secure from the client to the server.. Now if you control the client and get him to trust certs you create, then sure pretty easy to do mitm.. But it also become resource hungry creating certs on the fly for any fqdn the client might be going to.