Logging DNS queries
-
@Octopuss You might want to make sure your not trying to do any of the advanced stuff with dnssec if you turn it off in advanced.
I have never seen an issue with those being on but dnssec being off on the normal check box.. But I only ever turn dnssec off for testing for someone else. And have never actually rebooted pfsense with those advanced setting still checked but dnssec turned off.
Like I said the only time I ever reboot pfsense is on update.
What version are you running of pfsense 24.11 or CE 2.7.2 ?
edit: I could try and duplicate your issue in one of my VMs of pfsense - but not going to reboot my main physical pfsense box ;) heheh
-
@johnpoz I am on 2.7.2.
I thought the advanced settings wouldn't matter if I disable the feature in the general tab.
Anyway, I'll try. Perhaps I found a bug. -
@Octopuss yeah if the normal checkbox is set to not do dnssec, those setting for sure shouldn't come in to play.. But yeah maybe you found something weird.. So if your on 2.7.2 I will try and duplicate in my VM of that.
-
@johnpoz Nope, even with the advaned settings unchecked it's still borked. It's even weirdly borked, because some websites work and some don't, namely this forum and Facebook, but others too I guess.
I really think I should do a reinstall, this seems hopelessly screwed. -
For your reference here are some stock settings on 24.11 using resolver mode and ISC as backend. Python module is enabled as I use PFBlocker.
-
@Octopuss said in Logging DNS queries:
because some websites work and some don't
If unbound is not running - no sites would work, unless your client is just using its cache.. There is zero reason to do a full reinstall. Let me fire up my VM and see if can duplicate.. But not having dnssec check sure and the hell should not keep unbound from starting that is for sure.
-
@johnpoz said in Logging DNS queries:
If unbound is not running - no sites would work, unless your client is just using its cache..
I don't know! All I know pinging by hostname and some website don't work after reboot unless I restart the service.
-
@Octopuss ok I can not duplicate your problem..
Here are my settings, reboot of pfsense and soon as it comes up I can do a query and get answer.. In forwarding mode as you can, pointing to my upstream physical pfsense IP.. dnssec is off, etc..
I then went to change the min ttl to 3600, and go this warning
So unchecked that and then it saved.. Rebooted and again no problems, comes right up - if I do a query now can see that my min ttl is set.
Only thing that comes to mind maybe - do you have the patches installed.. None of them specific jumped out at me that should matter for this.. But I do have all the patches installed.
Vs trying to ping - do an actual query.. Use nslookup, or dig or whatever your fav dns tool is.. Pinging from your pc is going to use its local cache, So yeah its quite possible something is cached and others are not.. Doing a directed query would tell you if unbound is up, and your getting some error like nx or servfail, or if just timing out, etc.
I changed the server nslookup pointed too - because my pc defaults to using my pihole, unbound on my pfsense vm is on 192.168.9.34
-
@johnpoz I changed the settings a bit (they were mostly the same) so they mirror yours, and it still doesn't work withour restarting it.
I don't know what the patches are so I probably didn't touch them.Oh and
-
@Octopuss so you have no patches installed? I would install the patches package, and then apply all the recommended patches.
-
@johnpoz I can do that, but that's irrelevant to this problem I believe. I mean everything worked fine until I disabled DNSSEC as per your recommendation for forwarding mode or something :D
I don't even know where the patches are.
Found the patches, no difference like I expected :( -
@Octopuss they are in the package manager..
Here is the thing - I can't replicate your problem.. I have patches installed. You have an issue, no patches installed.. It would seem pretty logical that possible the patches fixed an issue that your running into.. Because I can not duplicate your problem.
I mean nothing jumps out at me in the patches that could fix whatever your seeing.. But might as well be up to date to see if that does fix it before doing a complete reinstall.
What I can tell you for sure - is I can not duplicate the problem on my 2.7.2 VM
Also what else I can tell you is doing dnssec or not doing dnssec should not force you to restart unbound once pfsense starts.
-
@johnpoz Like I said, I will simply reinstall the entire thing from scratch and redo all the settings manually when I find the motivation to lose several hours of my life, lol.
-
@Octopuss or you could install the patches in like 2 minutes and do a reboot and see if you don't have to reinstall.. And more than likely whatever issue your running into - not sure how a reinstall is going to correct the problem.. This is freebsd, this not windows me ;)
In all the years I have been using pfsense, on all kinds of different hardware.. Have only once had to do a reinstall.. And that was crashed update.. So I had to do a clean install.
-
@Octopuss Please keep us updated. I will be curious about your final resolution. I understand, from what I interpret.........your frustration.
-
@johnpoz said in Logging DNS queries:
or you could install the patches in like 2 minutes and do a reboot and see if you don't have to reinstall
You seem to have missed the edited part of my post where I said it made no difference.
@johnpoz said in Logging DNS queries:
not sure how a reinstall is going to correct the problem.. This is freebsd, this not windows me ;)
Assuming it's a combination of settings, reinstall will solve it, because there's so much stuff that can be combined together and is possibly interconnected one way or another that there's no way to troubleshoot this. -
@Uglybrian said in Logging DNS queries:
@Octopuss Please keep us updated. I will be curious about your final resolution. I understand, from what I interpret.........your frustration.
I really don't know what to make of this. It could be some obscure bug or it could be a combination of settings or some black magic.
-
I have been following along and was surprised by-your unbound behavior by simply turning off DNSSEC.
Since johnpoz could not replicate what was happening . I would determine it to be black magic.
There are some great suggestions in this post to help minimize your DNS lookups with your ISP. Even though they are in the range of normal.
The minimum TTL for RR sets to be set at 3600 is something I changed a couple of years ago when I read about it in a previous johnpoz post. Like him, I also have not ran into any issues.
I also think you should try resolving instead of forwarding. I believe you will find it just as fast as forwarding and not notice the difference.If you do determine you would just rather reinstall. I would take a back up copy and instead of reinstalling go to diagnostics and click on factory defaults.
Can’t wait to see what happens next.
-
@Octopuss what does your log say when you reboot and unbound isn't working? Is the service not running at all? ie it didn't start or did it start and is just not bound to something? If its running lets see output of
[24.11-RELEASE][admin@sg4860.home.arpa]/root: unbound-control -c /var/unbound/unbound.conf status version: 1.22.0 verbosity: 2 threads: 4 modules: 2 [ validator iterator ] uptime: 20638 seconds options: control(ssl) unbound (pid 65878) is running...and this
[24.11-RELEASE][admin@sg4860.home.arpa]/root: netstat -anl | grep -w '53' tcp4 0 0 127.0.0.1.53 *.* LISTEN tcp4 0 0 192.168.7.253.53 *.* LISTEN tcp4 0 0 192.168.4.253.53 *.* LISTEN tcp4 0 0 192.168.6.253.53 *.* LISTEN tcp4 0 0 192.168.2.253.53 *.* LISTEN tcp4 0 0 192.168.110.253.53 *.* LISTEN tcp4 0 0 192.168.9.253.53 *.* LISTEN tcp4 0 0 192.168.3.253.53 *.* LISTEN tcp4 0 0 10.1.1.253.53 *.* LISTEN udp4 0 0 127.0.0.1.53 *.* udp4 0 0 192.168.7.253.53 *.* udp4 0 0 192.168.4.253.53 *.* udp4 0 0 192.168.6.253.53 *.* udp4 0 0 192.168.2.253.53 *.* udp4 0 0 192.168.110.253.53 *.* udp4 0 0 192.168.9.253.53 *.* udp4 0 0 192.168.3.253.53 *.* udp4 0 0 10.1.1.253.53 *.* [24.11-RELEASE][admin@sg4860.home.arpa]/root:That will show you what IPs is listening on.. If you do not see it listening on anything - then yeah its never going to work..
If it fails to start completely there should be something in the logs saying why it didn't start.
-
@johnpoz said in Logging DNS queries:
@Octopuss what does your log say when you reboot and unbound isn't working? Is the service not running at all? ie it didn't start or did it start and is just not bound to something? If its running lets see output of
[24.11-RELEASE][admin@sg4860.home.arpa]/root: unbound-control -c /var/unbound/unbound.conf status version: 1.22.0 verbosity: 2 threads: 4 modules: 2 [ validator iterator ] uptime: 20638 seconds options: control(ssl) unbound (pid 65878) is running...and this
[24.11-RELEASE][admin@sg4860.home.arpa]/root: netstat -anl | grep -w '53' tcp4 0 0 127.0.0.1.53 *.* LISTEN tcp4 0 0 192.168.7.253.53 *.* LISTEN tcp4 0 0 192.168.4.253.53 *.* LISTEN tcp4 0 0 192.168.6.253.53 *.* LISTEN tcp4 0 0 192.168.2.253.53 *.* LISTEN tcp4 0 0 192.168.110.253.53 *.* LISTEN tcp4 0 0 192.168.9.253.53 *.* LISTEN tcp4 0 0 192.168.3.253.53 *.* LISTEN tcp4 0 0 10.1.1.253.53 *.* LISTEN udp4 0 0 127.0.0.1.53 *.* udp4 0 0 192.168.7.253.53 *.* udp4 0 0 192.168.4.253.53 *.* udp4 0 0 192.168.6.253.53 *.* udp4 0 0 192.168.2.253.53 *.* udp4 0 0 192.168.110.253.53 *.* udp4 0 0 192.168.9.253.53 *.* udp4 0 0 192.168.3.253.53 *.* udp4 0 0 10.1.1.253.53 *.* [24.11-RELEASE][admin@sg4860.home.arpa]/root:That will show you what IPs is listening on.. If you do not see it listening on anything - then yeah its never going to work..
If it fails to start completely there should be something in the logs saying why it didn't start.
[2.7.2-RELEASE][admin@rozcestnik.lan]/root: unbound-control -c /var/unbound/unbound.conf status version: 1.18.0 verbosity: 1 threads: 4 modules: 1 [ iterator ] uptime: 69 seconds options: control(ssl) unbound (pid 333) is running...[2.7.2-RELEASE][admin@rozcestnik.lan]/root: netstat -anl | grep -w '53' tcp4 0 0 127.0.0.1.53 *.* LISTEN udp4 0 0 127.0.0.1.53 *.*
