Filterdns stops working
-
Here is the output of dnslookup for heise.de:
Results Result Record type 193.99.144.80 A 2a02:2e0:3fe:1001:302:: AAAA Timings Name server Query time 127.0.0.1 14 msec 127.0.0.1 0 msec 8.8.8.8 13 msec 9.9.9.9 13 msec 81.173.194.77 8 msec 194.8.194.60 9 msechttps://redmine.pfsense.org/issues/8001 might be related.
Yep, i guess its the same bug.
Somewhere in this forum someone mentioned it could help to put in 127.0.0.1 as first DNS in general setup (thats why it is shown twice in the output above). That way one DNS always answers even when the others dont respond. -
I don't understand why you are mixing "normal" name servers like 8.8.8.8 with 9.9.9.9 - They will give different answers to the same queries. 8.8.8.8 might return A / AAAA records where 9.9.9.9 might return NXDOMAIN. This can make troubleshooting difficult.
If you want to use quad9 properly you have to use dnsmasq (DNS Forwarder), or unbound (DNS Resolver) in forwarding mode, or disable the local forwarder/resolver and tell pfSense to use quad9 exclusively and disable the localhost nameserver from the list using the checkbox on the general settings page.
Having 127.0.0.1 listed twice is also pretty much nonsense.
Is anything being logged in the resolver log that might point to what it doesn't like?
I currently have a name that's not resolving and I get:
filterdns failed to resolve host vpn1.redacted.com will retry later again.
That does get an instant NXDOMAIN, however.
The filterdns debug level is hard-coded in /etc/inc/filter.inc
You might try changing -d 1 to -d 3 there and seeing if anything meaningful is logged.
/* * FilterDNS has three debugging levels. The def ault chosen is 1. * Available are level 2 and greater then 2. */ if (isset($config['system']['aliasesresolveinter val']) && is_numeric($config['system']['aliasesresolveinterval'])) { $resolve_interval = $config['system']['a liasesresolveinterval']; } else { $resolve_interval = 300; } mwexec("/usr/local/sbin/filterdns -p {$g['varrun _path']}/filterdns.pid -i {$resolve_interval} -c {$g['varetc_path']}/filterdns.c onf -d 1"); /* <---- Change it here */ -
ok, deleted 9.9.9.9 and 127.0.0.1 from dns server settings.
i have configured unbound in forwarding mode.
the resolver.log doesnt show anything suspicious. the entries where name couldnt be resolved are already removed from all aliases (they were just old entries).
i will try changing the debug-level and see what is beeing logged, thx for the tip.i will also reboot the pfsense tomorrow, then i hopefully only have 1 instance of filterdns running.
-
There can be several different filter DNS processes running legitimately. There can be one for aliases and one for IPsec endpoints that must be resolved, for instance. There might be others.
ps axww | grep filterdns
should show them. That should also show the different config files they are using, etc.
-
As IPsec-endpoints he have IPs, so that wont need filterdns.
According to the ps axww all processes use the same config file (/var/etc/filterdns.conf) and the same .pid-file.
I guess that are instances that i manually started to make the name resolution for aliases work again. -
ok, after the restart of the pf i only have one filterdns-process running and the names are resolved correct.
lets hope it stays this way :) -
i have the same problem. after several days, filterdns stopped working. just a reboot of the pfsense solve the problem for the next few days.
i just have 5 fqdn (dynamic dns) entrys in my ip alias table.(2.4.2 p1)
-
this is annoying, it happened again this night. yesterday after 11pm no more updates.
for the moment i will add a cronjob to restart filterdns every hour.
 -
I have the exact same issue on 2.4.2-RELEASE-p1. I really hope someone finds a fix to this issue.
maybe the cronjob is what i need for now?
-
this is annoying, it happened again this night. yesterday after 11pm no more updates.
for the moment i will add a cronjob to restart filterdns every hour.Can you share your cron job with me? I'm not that familiar with cronjob's and i have the same issue. would like a temp fix for now until they fix the bug.
-
Can you share your cron job with me? I'm not that familiar with cronjob's and i have the same issue. would like a temp fix for now until they fix the bug.
sure….
look at the picture belowContent of cron_filterdns.sh
#!/bin/sh pkill filterdns /usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 240 -c /var/etc/filterdns.conf -d 1
 -
When the problem happens, does /var/run/filterdns.pid contain a valid PID for filterdns? (Check the "ps uxaww" output to find the filterdns pid)
If you do "killall -HUP filterdns" do the entries resolve again, or are they still missing?
The code in place now tries not to restart filterdns unless it absolutely has to, but perhaps there is some issue when it's running for prolonged periods were it gets confused or fails to update when expected.
-
i will disable my cronjob and give you feedback when it happens again @jimp
-
a little update from me:
after the reboot 8 days ago everything still works (with the modification of the aliases). -
and again, no more update after 11pm.
"killall -HUP filterdns" has no effect at all.
-
ok, problem is back on my system :'(
When the problem happens, does /var/run/filterdns.pid contain a valid PID for filterdns? (Check the "ps uxaww" output to find the filterdns pid)
yes, its the pid of the running filterdns-process.
If you do "killall -HUP filterdns" do the entries resolve again, or are they still missing?
it doesnt change anything on my machine.
one thing changed:
the old entries were not deleted this time. but they are not updated.
new entries are not resolved but they are added to the filterdns.conf.also the mentioned cron-job from m0nji doesnt seem to be a good idea, since the "pkill filterdns" doesn't end the filterdns-process (at least not on my pf). that means only more and more instances of filterdns will start.
is there any way to really kill that process so i can start a fresh instance?
-
I have the same problem!
No filterDNS in the system->DNS Resolver logs after a week or some days. -
Somebody with a solution?
-
not really a solution, only a workaround:
run "killall -9 filterdns" in the shell and then "/usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 300 -c /var/etc/filterdns.conf -d 1" (or save and apply an existing alias). you could also put them in a cron as already mentioned.since the error happened to me again, i checked the resolver.log again to see if there is any information what the reason could be. even with debug level 3 there is no clue.
the last working entries are some normal adding and clearing entries and some information about some static entries.
the next time filterdns should run, it starts with a "Received signal Hangup(1)" entry and only one entry gets deleted and the static entries are listed.
after that every time filterdns should run (automatically or after a manual save&apply of an alias), only the hangup-message is in log.ps: seems this thread is about the same problem. maybe both threads should be merged.
-
I can confirm, same issue is happening with me. It seems to be it, it started happening after pfSense upgrade in Sept-Nov 2017. I am using development snapshot from 10th of January, issue still persists.
am using Policy Based Routing (PBR) and heavily rely on a lot of aliases: it took time to realize that tables of IP addresses (referring hostname based aliases) are not updated.
So temporary workaround so far is same, what you have suggested:
killall -9 filterdns
rm /var/pid/filterdns.pid (not sure if it correct path, just writing from my head)and then start filterdns process again (or refresh aliases).
In fact, starting filterdns (with proper arguments) sometimes did not help, I had to kill the process again and refresh (edit-save-apply) one of aliases lists.
