DNS Resolver sudden stop and filterdns PID 48934
-
@gertjan 2a7701126aae53348b3a1ddd17f745e4
same as yours, this message happens directly after the pfblockerng latest update, btw i have the same setup in the cloud (proxmox vm) and all works well. the only difference between them is the vm image has Hardware Checksum Offloading and others checked in the Advanced Networking, too annoying problem :(
-
There might be a way to get rid of the errors.
This file : /usr/local/www/pfblockerng/www/index.php is probably the start of the PHP section that builds the web page that users see when they try to visit a DNSBL blocked page.
I see mow the issue. That is, when I visit https://pfsense.me.net/pfblockerng/www/ manually it hit the error right away.
I advise you all to disable that web server that shows the DNS blocked page as it is rather useless, and very soon it won't work anyway.
( because of the MITM concepts, TLS, how https works, your browser won't show that page any more, etc etc )So :
and done.
-
@gertjan I did what you said and also restarted the firewall same Crash report
Crash report begins. Anonymous machine information:
amd64
12.2-STABLE
FreeBSD 12.2-STABLE d48fb226319(devel-12) pfSenseCrash report details:
PHP Errors:
[02-Mar-2021 14:13:18 Asia/Beirut] PHP Fatal error: Uncaught Error: Class 'Net_IPv6' not found in /etc/inc/util.inc:680
Stack trace:
#0 /etc/inc/util.inc(657): is_ipaddrv6('pagead2.googles...')
#1 /usr/local/www/pfblockerng/www/index.php(59): is_ipaddr('pagead2.googles...')
#2 {main}
thrown in /etc/inc/util.inc on line 680No FreeBSD crash data found.
Could we do something else?
-
and in your opinion what is the solution of the following log entry in the DNS Resolver
filterdns 37490 (PID) failed to resolve host xxx will retry later again.
-
@ramikilany said in DNS Resolver sudden stop and filterdns PID 48934:
failed to resolve
When unbound fails, it stops. Resolving stops. For your LAN based device and any process on pfSense itself. filterdns is just one of such processes.
-
@gertjan after a while the message does not appear again, till now it is the solution.
already thank you for your patience and for this great solution.
Thumbs Up.
-
@gertjan how may I troubleshoot the failure of the unbound service? To know how to fix this issue if you cloud help me again.
-
@ramikilany said in DNS Resolver sudden stop and filterdns PID 48934:
how may I troubleshoot the failure of the unbound service?
The issue at the top isn't a unbound issue but a pfBlockerNG issue.
Something (some one) is hitting the PFB "block page". Who is it ? (hint : look in the logs ....)
De activate this page as stated above.
Or de active DNSBL - dooes that help ?Btw : you are not using unbound in the default mode, you forward to Google & co.
That complicates things.Unbound uist run in resolver mode for pfBlockerNG to work.
This one :
@ramikilany said in DNS Resolver sudden stop and filterdns PID 48934:
filterdns 48934 failed to resolve host pt1 will retry later again
is also not real an error.
"pt1" isn't valid hos name. -
How may I use the unbound in the default mode? what is the best practice to set up the forward servers ( not Google for example) and the solution that you have posted above works with me (Null Block)
Kindly if you can describe how that the unbound must run in resolver mode for pfBlockerNG to works perfectly
NB: pt1 is a computer name in my domain network.
-
@ramikilany said in DNS Resolver sudden stop and filterdns PID 48934:
Kindly if you can describe how that the unbound must run in resolver mode for pfBlockerNG to works perfectly
As already mentioned : use the default settings.
They work.@ramikilany said in DNS Resolver sudden stop and filterdns PID 48934:
NB: pt1 is a computer name in my domain network.
Should be a fully qualified : like "pt1.local.tld". That way, unbound will know it's local, can resolve it directly, and won't send it to Google or OpenDNS, as these can't know what you have in your LAN anyway.
@ramikilany said in DNS Resolver sudden stop and filterdns PID 48934:
what is the best practice to set up the forward servers
The best way to use forward servers is : not using them. You don't need them (they need you and do not pay you for it ....)
-
@ramikilany said in DNS Resolver sudden stop and filterdns PID 48934:
[02-Mar-2021 09:14:55 Asia/Beirut] PHP Fatal error: Uncaught Error: Class 'Net_IPv6' not found in /etc/inc/util.inc:680
The solution :
https://github.com/pfsense/FreeBSD-ports/commit/8b27bcf00d06eeeed4e2ea5a5fdc23edf1b4ba23
look at the bottom of the page :
Works :
-
Great and professional support from a super great man. Thank you for your help.
-
The DNS unbound sudden stop still exict, some times it work with just restart the DNS resolver unbound service and sometime I need to reboot the pfsense firewall.
When it stops the internet connection goes from the network and every thing stops working.
How may I fix this critical issue?
-
What pfSense version ?
See, for example, here : https://forum.netgate.com/topic/115482/frequent-unbound-restarts/79 about how to post the details so the issue can be seen right away.
-
@gertjan said in DNS Resolver sudden stop and filterdns PID 48934:
https://forum.netgate.com/topic/115482/frequent-unbound-restarts/79
Version 2.5.0-RELEASE (amd64)
built on Tue Feb 16 08:56:29 EST 2021
FreeBSD 12.2-STABLEand now it stops here is the log line:
Mar 4 11:10:42 unbound 13528 [13528:0] info: service stopped (unbound 1.13.1). -
when go to Diagnostics and DNS lookup and test google.com for example it shows this result:
Timings
Name server Query time
127.0.0.1 No response
172.16.99.1 1 msecthe local DNS is stooped and not responding
this happens now every 2 hours
-
Cool.
lol :unbound stopped.
and it said it stopped.That what you are telling.
More details are needed.
Please, read https://forum.netgate.com/topic/115482/frequent-unbound-restarts/79
You will find logs - and you can (have to) compare with other logs.
So, when, you find :
Mar 4 11:10:42 unbound 13528 [13528:0] info: service stopped (unbound 1.13.1).
in the resolver log, you can see in the other logs who tolled it to do so.
Like :
Mar 4 11:10:42 pfSense dhcpleases[3459]: Sending HUP signal to dns daemon(13528)
Process 13528 is unbound.
Btw : dhcpleases doesn't stop unbound, it restarts unbound.
No process will stop unbound, except you in the GUI.
-
In the logs in the same time that the unbound stopped their was nothing to inform us what was the problem causing this sudden stop.
In the forums I tried to uncheck the 2 options in DNS Resolver settings:
-
Register DHCP leases in the DNS Resolver
-
Register DHCP static mappings in the DNS Resolver
and it works with and no more sudden stop any more but for example in Status / Traffic Graph when monitoring the bandwidth with the option FQDN it shows only IP so I must take the IP and check it in the DHCP leases to know the FQDN. And this is one example of the problems that may happen when not checking the 2 check boxes mentioned above.
Is there any way to fix the sudden stops of unbound service while keep checking these 2 boxes or if we could register the DHCP client in the DNS Resolver in other way.
-
-
@ramikilany said in DNS Resolver sudden stop and filterdns PID 48934:
In the logs in the same time that the unbound stopped their was nothing to inform us what was the problem causing this sudden stop.
Check again.
And this is not a wild guess : check the Status > System Logs > DHCP page.
Compare the "Renew ...." events with what unbound does.@ramikilany said in DNS Resolver sudden stop and filterdns PID 48934:
In the forums I tried to uncheck the 2 options in DNS Resolver settings:
Register DHCP ...............
Register DHCP static mappings in the DNS Resolver
It has never been said that "Register DHCP static mappings in the DNS Resolve" should be unchecked.
Only this one :
Lease that are marked as "Static" do not HUP unbound, as their info is loaded at start up and do not change any more.
@ramikilany said in DNS Resolver sudden stop and filterdns PID 48934:
Is there any way to fix the sudden stops of unbound service while keep checking these 2 boxes or if we could register the DHCP client in the DNS Resolver in other way.
As said many times :
Uncheck the box - see image above.
AND - your not done yet - ADD for every device that needs to be known in the network with its host name, a Static lease :only now you corrected the issue, and compensated for side effect.
For me, unbounds restarts rarely. As such, DNS resolving and the the DNS cache works fine.
-
Status > System Logs> System > DNS Resolver:
Mar 18 12:39:58 unbound 24774 [24774:0] info: start of service (unbound 1.13.1). Mar 18 12:39:52 unbound 24774 [24774:0] notice: Restart of unbound 1.13.1. Mar 18 12:39:52 unbound 24774 [24774:0] info: service stopped (unbound 1.13.1). Mar 18 12:39:38 unbound 24774 [24774:0] info: start of service (unbound 1.13.1). Mar 18 12:39:33 unbound 24774 [24774:0] notice: Restart of unbound 1.13.1. Mar 18 12:39:33 unbound 24774 [24774:0] info: service stopped (unbound 1.13.1). Mar 18 12:34:57 unbound 24774 [24774:0] info: start of service (unbound 1.13.1). Mar 18 12:34:52 unbound 24774 [24774:0] notice: Restart of unbound 1.13.1. Mar 18 12:34:52 unbound 24774 [24774:0] info: service stopped (unbound 1.13.1). Mar 18 12:34:48 unbound 24774 [24774:0] info: start of service (unbound 1.13.1). Mar 18 12:34:43 unbound 24774 [24774:0] notice: Restart of unbound 1.13.1. Mar 18 12:34:43 unbound 24774 [24774:0] info: service stopped (unbound 1.13.1). Mar 18 12:34:15 unbound 24774 [24774:0] info: start of service (unbound 1.13.1). Mar 18 12:34:10 unbound 24774 [24774:0] notice: Restart of unbound 1.13.1. Mar 18 12:34:10 unbound 24774 [24774:0] info: service stopped (unbound 1.13.1). Mar 18 12:34:02 unbound 24774 [24774:0] info: start of service (unbound 1.13.1). Mar 18 12:33:57 unbound 24774 [24774:0] notice: Restart of unbound 1.13.1.
Status > System Logs> DHCP:
Mar 18 12:39:52 dhcpleases 17571 Sending HUP signal to dns daemon(24774) Mar 18 12:39:44 dhcpd 40341 DHCPACK on 192.168.3.68 to f4:4d:30:6f:be:ef (ad13) via re0.3 Mar 18 12:39:44 dhcpd 40341 DHCPREQUEST for 192.168.3.68 from f4:4d:30:6f:be:ef (ad13) via re0.3 Mar 18 12:39:44 dhcpd 40341 reuse_lease: lease age 0 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.3.68 Mar 18 12:39:44 dhcpd 40341 DHCPACK on 192.168.3.68 to f4:4d:30:6f:be:ef (ad13) via re0.3 Mar 18 12:39:44 dhcpd 40341 DHCPREQUEST for 192.168.3.68 from f4:4d:30:6f:be:ef (ad13) via re0.3 Mar 18 12:39:33 dhcpleases 17571 Sending HUP signal to dns daemon(24774) Mar 18 12:39:27 dhcpd 40341 DHCPACK on 192.168.3.52 to e0:69:95:3c:09:27 (cc1) via re0.3 Mar 18 12:39:27 dhcpd 40341 DHCPREQUEST for 192.168.3.52 from e0:69:95:3c:09:27 (cc1) via re0.3 Mar 18 12:38:45 dhcpleases 17571 Sending HUP signal to dns daemon(24774) Mar 18 12:38:36 dhcpd 40341 DHCPACK on 192.168.4.60 to 7c:a1:77:ba:58:79 (HUAWEI_Y7_Prime_2018-2065) via re0.4 Mar 18 12:38:36 dhcpd 40341 DHCPREQUEST for 192.168.4.60 from 7c:a1:77:ba:58:79 (HUAWEI_Y7_Prime_2018-2065) via re0.4 Mar 18 12:38:36 dhcpd 40341 reuse_lease: lease age 0 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.4.60 Mar 18 12:38:36 dhcpd 40341 DHCPACK on 192.168.4.60 to 7c:a1:77:ba:58:79 (HUAWEI_Y7_Prime_2018-2065) via re0.4 Mar 18 12:38:36 dhcpd 40341 DHCPREQUEST for 192.168.4.60 from 7c:a1:77:ba:58:79 (HUAWEI_Y7_Prime_2018-2065) via re0.4 Mar 18 12:38:28 dhcpleases 17571 Sending HUP signal to dns daemon(24774) Mar 18 12:38:21 dhcpd 40341 DHCPACK on 192.168.3.177 to 1c:66:6d:96:53:ce (fd7) via re0.3 Mar 18 12:38:21 dhcpd 40341 DHCPREQUEST for 192.168.3.177 from 1c:66:6d:96:53:ce (fd7) via re0.3 Mar 18 12:38:14 dhcpd 40341 DHCPACK on 192.168.4.104 to ba:df:d3:8b:d8:41 (iPhone6MBISSAR) via re0.4 Mar 18 12:38:14 dhcpd 40341 DHCPREQUEST for 192.168.4.104 (192.168.4.254) from ba:df:d3:8b:d8:41 (iPhone6MBISSAR) via re0.4 Mar 18 12:38:14 dhcpd 40341 reuse_lease: lease age 6778 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.4.104 Mar 18 12:38:13 dhcpd 40341 DHCPOFFER on 192.168.4.104 to ba:df:d3:8b:d8:41 (iPhone6MBISSAR) via re0.4 Mar 18 12:38:13 dhcpd 40341 DHCPDISCOVER from ba:df:d3:8b:d8:41 (iPhone6MBISSAR) via re0.4 Mar 18 12:38:13 dhcpd 40341 reuse_lease: lease age 6777 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.4.104 Mar 18 12:38:04 dhcpd 40341 DHCPOFFER on 192.168.4.104 to ba:df:d3:8b:d8:41 (iPhone6MBISSAR) via re0.4 Mar 18 12:38:04 dhcpd 40341 DHCPDISCOVER from ba:df:d3:8b:d8:41 (iPhone6MBISSAR) via re0.4 Mar 18 12:38:04 dhcpd 40341 reuse_lease: lease age 6768 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.4.104 Mar 18 12:37:53 dhclient 44348 Creating resolv.conf Mar 18 12:37:53 dhclient 43748 RENEW Mar 18 12:37:24 dhcpd 40341 DHCPACK on 192.168.3.139 to 1c:69:7a:02:6b:f9 (ph6) via re0.3 Mar 18 12:37:24 dhcpd 40341 DHCPREQUEST for 192.168.3.139 from 1c:69:7a:02:6b:f9 (ph6) via re0.3 Mar 18 12:37:24 dhcpd 40341 reuse_lease: lease age 1022 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.3.139 Mar 18 12:36:13 dhcpleases 17571 Sending HUP signal to dns daemon(24774) Mar 18 12:36:08 dhcpd 40341 DHCPACK on 192.168.3.125 to f4:4d:30:6e:49:c8 (ic2) via re0.3 Mar 18 12:36:08 dhcpd 40341 DHCPREQUEST for 192.168.3.125 (192.168.3.254) from f4:4d:30:6e:49:c8 (ic2) via re0.3 Mar 18 12:36:08 dhcpd 40341 DHCPOFFER on 192.168.3.125 to f4:4d:30:6e:49:c8 (ic2) via re0.3 Mar 18 12:36:07 dhcpd 40341 DHCPDISCOVER from f4:4d:30:6e:49:c8 via re0.3 Mar 18 12:36:00 dhcpleases 17571 Sending HUP signal to dns daemon(24774) Mar 18 12:35:54 dhcpd 40341 DHCPACK on 192.168.3.187 to f4:4d:30:6e:42:4c (ic1) via re0.3 Mar 18 12:35:54 dhcpd 40341 DHCPREQUEST for 192.168.3.187 (192.168.3.254) from f4:4d:30:6e:42:4c (ic1) via re0.3 Mar 18 12:35:54 dhcpd 40341 DHCPOFFER on 192.168.3.187 to f4:4d:30:6e:42:4c (ic1) via re0.3 Mar 18 12:35:53 dhcpd 40341 DHCPDISCOVER from f4:4d:30:6e:42:4c via re0.3 Mar 18 12:35:26 dhcpleases 17571 Sending HUP signal to dns daemon(24774) Mar 18 12:35:17 dhcpd 40341 DHCPACK on 192.168.3.130 to f4:4d:30:6f:58:33 (ad8) via re0.3 Mar 18 12:35:17 dhcpd 40341 DHCPREQUEST for 192.168.3.130 from f4:4d:30:6f:58:33 (ad8) via re0.3 Mar 18 12:34:52 dhcpleases 17571 Sending HUP signal to dns daemon(24774) Mar 18 12:34:46 dhcpd 40341 DHCPACK on 192.168.3.246 to f4:4d:30:6f:5b:9f (ob3) via re0.3 Mar 18 12:34:46 dhcpd 40341 DHCPREQUEST for 192.168.3.246 from f4:4d:30:6f:5b:9f (ob3) via re0.3 Mar 18 12:34:43 dhcpleases 17571 Sending HUP signal to dns daemon(24774) Mar 18 12:34:37 dhcpd 40341 DHCPACK on 192.168.3.216 to fc:45:96:84:48:e8 (ph5) via re0.3 Mar 18 12:34:37 dhcpd 40341 DHCPREQUEST for 192.168.3.216 from fc:45:96:84:48:e8 (ph5) via re0.3 Mar 18 12:34:10 dhcpleases 17571 Sending HUP signal to dns daemon(24774) Mar 18 12:34:04 dhcpd 40341 DHCPACK on 192.168.3.91 to 94:c6:91:a7:b0:f9 (cn10) via re0.3 Mar 18 12:34:04 dhcpd 40341 DHCPREQUEST for 192.168.3.91 from 94:c6:91:a7:b0:f9 (cn10) via re0.3 Mar 18 12:34:02 dhcpd 40341 DHCPACK on 192.168.2.45 to 0e:4f:8c:37:b4:20 via re0.2 Mar 18 12:34:02 dhcpd 40341 DHCPREQUEST for 192.168.2.45 from 0e:4f:8c:37:b4:20 via re0.2 Mar 18 12:33:56 dhcpleases 17571 Sending HUP signal to dns daemon(24774) Mar 18 12:33:51 dhcpd 40341 DHCPACK on 192.168.3.210 to f4:4d:30:6e:18:5d (ma1) via re0.3 Mar 18 12:33:51 dhcpd 40341 DHCPREQUEST for 192.168.3.210 from f4:4d:30:6e:18:5d (ma1) via re0.3 Mar 18 12:33:46 dhcpd 40341 DHCPACK on 192.168.4.76 to d8:c7:71:f4:17:57 (HUAWEI_nova_2_Plus-6660dc) via re0.4 Mar 18 12:33:46 dhcpd 40341 DHCPREQUEST for 192.168.4.76 from d8:c7:71:f4:17:57 (HUAWEI_nova_2_Plus-6660dc) via re0.4 Mar 18 12:33:46 dhcpd 40341 reuse_lease: lease age 1190 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.4.76 Mar 18 12:33:46 dhcpd 40341 DHCPACK on 192.168.4.76 to d8:c7:71:f4:17:57 (HUAWEI_nova_2_Plus-6660dc) via re0.4 Mar 18 12:33:46 dhcpd 40341 DHCPREQUEST for 192.168.4.76 from d8:c7:71:f4:17:57 (HUAWEI_nova_2_Plus-6660dc) via re0.4 Mar 18 12:33:46 dhcpd 40341 reuse_lease: lease age 1190 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.4.76 Mar 18 12:33:22 dhcpleases 17571 Sending HUP signal to dns daemon(24774) Mar 18 12:33:13 dhcpd 40341 DHCPACK on 192.168.3.163 to f4:4d:30:6e:15:d5 (ad4) via re0.3 Mar 18 12:33:13 dhcpd 40341 DHCPREQUEST for 192.168.3.163 from f4:4d:30:6e:15:d5 (ad4) via re0.3 Mar 18 12:33:08 dhcpleases 17571 Sending HUP signal to dns daemon(24774)
In case of ADD for every device that needs to be known in the network with its host name, a Static lease in some VLans I have more than 200 IPs and I need to access them remotely by FQDN for support and it is not logic to set static IP Mappings for more than 400 device (I have mobiles and phones Network and IoT and more than 200 PC for a system) that is why I need to check the Register DHCP leases in the DNS Resolver, and the problem was working perfectly in version 2.4.5 p1 after the latest update this problem exists.
Does the logs are enough to troubleshoot the problem? If you want also I can give you access to the firewall.