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.
-
@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 *.* -
@Uglybrian said in Logging DNS queries:
There are some great suggestions in this post to help minimize your DNS lookups with your ISP.
Honestly I don't care about that anymore. At most I am curious what kind of other clients they have, because any PC with enough tabs open and some online services running should generate plenty.
-
@Octopuss well if its only listening loopback that would explain why its not working, your clients talking to its lan port, its not listening on.
Do you have say a vpn or something.. This is hardware, not a vm right? You have it set to listen on what interface(s) Just your lan? For some reason your lan is taking longer to come up than when unbound starts?
But yeah there is clearly why its not working.. unbound never sees your clients queries because its not listening on the lan IP.
-
@johnpoz said in Logging DNS queries:
@Octopuss well if its only listening loopback that would explain why its not working, your clients talking to its lan port, its not listening on.
Do you have say a vpn or something.. This is hardware, not a vm right? You have it set to listen on what interface(s) Just your lan? For some reason your lan is taking longer to come up than when unbound starts?
But yeah there is clearly why its not working.. unbound never sees your clients queries because its not listening on the lan IP.
I don't have any VPN.
And yes it's standalone hardware. I ran it virtualized for a few years until I realized what horrible pain in the arse it was when something stopped working on the server, so in the end I said fuckit and bought one of those... what are they called ,appliances? It's basically a micro PC of sorts.And yes it also has localhost in the interfaces, because it throws an error when I try to remove it. It's somehow related to the forwarding mode option being checked.
-
@Octopuss can you do a test and not have it listen on your wifi.. And just the lan.. And also try it with all selected. its odd that its not listening on any.. other than local host..
But if you click to do dnssec it boots just fine and everything is up?
-
@johnpoz Like I already wrote, I cannot select just LAN. When I do that, I get this
@johnpoz said in Logging DNS queries:
But if you click to do dnssec it boots just fine and everything is up?
Yes, that's the only weird thing that happens when I disable DNSSEC.
The bottom line is I want to figure out why, not that it's a problem with any functionality (as far as I can tell). Everything works with it enabled, but you (I think) wrote I wasn't supposed to use it with forwarding mode for reasons I forgot, and I guess I want to do things properly since I don't know anything about all this.
Worst case when I don't figure it out and don't want to do a reinstall, I'll just use DNSSEC DNS servers from some regional internet organization or whatever they are: https://www.nic.cz/odvr/
-
@johnpoz So, if I select all in the network intefaces, it works right after boot.
If I select (seemingly) anything else, it just doesn't.
But then despite not having internet on my PC, DNS lookup on pfSense works
And ping as well!
But my PC has no internet. -
@Octopuss well if it is only listening on localhost for clients to talk to then yeah clients wouldn't be able to talk to it. But pfsense would be able to lookup stuff. And pinging an IP from client wouldn't need to lookup a name to know what to ping.
What is this setting?
What I mean is lan and localhost - my bad for not being specific.
For it to work, it has to be listening on an interface that clients can talk to.. What doesn't make any sense is what you show there is lan,wifi,wifi_sep and localhost.. So it should be listening on all of those - notice in mine it lists all the ips of my different interfaces its listening on.. If one of them wasn't coming up fast enough when unbound starts, why is not listening on the others..
But if it comes up when you have it set to all - that option works too. I would set network to all, and set outgoing to only the localhost.
If your set to all on network, you can turn off use dnssec and it works? I didn't try that in my 2.7.2.. I should of opened up the window when I posted the settings of my 2.7.2 - it is lan and localhost selected, not just lan.
-
@johnpoz said in Logging DNS queries:
@Octopuss well if it is only listening on localhost for clients to talk to then yeah clients wouldn't be able to talk to it. But pfsense would be able to lookup stuff. And pinging an IP from client wouldn't need to lookup a name to know what to ping.
What is this setting?
What I mean is lan and localhost - my bad for not being specific.
For it to work, it has to be listening on an interface that clients can talk to.. What doesn't make any sense is what you show there is lan,wifi,wifi_sep and localhost.. So it should be listening on all of those - notice in mine it lists all the ips of my different interfaces its listening on.. If one of them wasn't coming up fast enough when unbound starts, why is not listening on the others..
But if it comes up when you have it set to all - that option works too. I would set network to all, and set outgoing to only the localhost.
If your set to all on network, you can turn off use dnssec and it works? I didn't try that in my 2.7.2.. I should of opened up the window when I posted the settings of my 2.7.2 - it is lan and localhost selected, not just lan.
I have that set to default, that is local, fall back to remote. I presume this is conceptually better since it will use cached entries when it can instead of always asking remote servers?
I would set network to all, and set outgoing to only the localhost.
What do you mean? I thought outgoing must be WAN, otherwise
there would be no internet?@johnpoz said in Logging DNS queries:
If your set to all on network, you can turn off use dnssec and it works?
Yes.
-
@Octopuss so these settings are my 2.7.2 I just rebooted it and working fine comes up right away..
That 192.168.3.253 is my real pfsense upstream of the vm, so that would be like your isp dns.
edit:
No outbound can just be localhost, because it would nat to your wan when it tries to talk to something out on the internet.. This setting can help when your internet side takes a bit longer to come up. -
@johnpoz I have accidentally set outgoing to WAN and localhost instead of just localhost and it still didn't work, lol.
edit: Just localhost like you suggested doesn't work either.
The only thing that works with DNSSEC disabled is setting interfaces to all. -
@Octopuss really odd.
But if you set to all on network and either just all or wan on outbound it works?
edit: if network set to all, and it works or both set to all - that is a viable setup. And what it is out of the box. So if that works, and you can turn off dnssec that no need to reinstall that is for sure.
edit2: btw I just connected to my screen copy of dnstop I am running on my wan interface.. So still have about 8 hours til 24 hours.. And currently showing hair under 11k total outbound queries from box..
Your isp saying your too high with 16k in a day is just nuts. Maybe all his other users have 1 pc and turn it off when they are not using it? ;)
-
@johnpoz Network on all and outgoing on WAN works.
I'm just curious why is it acting like that. I know for a fact I didn't enable DNSSEC in past and the settings were otherwise the same.
-
@Octopuss yeah something is odd as you can see mine is set to just lan and localhost, and only localhost on wan.
Your setting of lan,wifi,wifi-sep,local host on network and just localhost on outgoing should be a viable sane setup.
But you should be good now, min ttl at 3600, no dnssec.. Your daily outbound queries should be reduced from that 16k your isp was complaining about.
edit: I would start a dnstop on your wan.. So you have your own record of how many outbound dns queries you did to his Namerserver in a 24h period.
edit2: if he still complains the only thing you could really do different is up the min ttl to like 7200 or something, and you could prob cut your queries in half if could stop all queries for AAAA. I will have to fire up bind and look at their no AAAA option to see if it prevents outbound queries when a client asks for it.
The trick of not handing them back to clients with private-address: ::/0 doesn't stop unbound from looking them up if asked, it just doesn't hand the answer back to the clients that asked for them... I will have to see if they have maybe added something that could stop it the outbound queries for AAAA in unbound.
-
@johnpoz I really don't care about their complaint, I just want to know what the hell is wrong with pfSense. But I guess I won't be able to find out.
I was thinking perhaps some firewall rules were missing (I don't understand that at all and never touched that, and when I had to add something it was lots of googling and trial and error), but then I didn't have any either back when DNSSEC was disabled. -
@Octopuss something is odd that setting is sane, the specific interfaces you want unbound to bind too and local host, because pfsense points to that to ask unbound to lookup something for pfsense.
The only thing I can think of is one of the interfaces you have selected is not coming up fast enough, and so unbound doesn't bind to anything other than localhost.. I would think if an interface is not up it should still bind to the others that are.. Maybe if your interfaces take a while to come up it just shits the bed? If you have it set to all it wouldn't really have to wait til interfaces are up.. It would just bind like this.
[2.7.2-RELEASE][admin@test.mydomain.tld]/root: netstat -anl | grep .53 tcp4 0 0 127.0.0.1.953 *.* LISTEN tcp4 0 0 *.53 *.* LISTEN tcp6 0 0 *.53 *.* LISTEN udp4 0 0 *.53 *.* udp6 0 0 *.53 *.*But if for some reason the interfaces are not up when unbound starts - that really should be logged.
edit: all and all is default.. That way sure dns is listening and works on all interfaces of pfsense - and could help users that maybe pick the wrong interfaces, etc. and then wonder why dns isn't working, etc.
-
@johnpoz Well the WAN interface is a gateway for wifi AP on the roof, but that's always on, there's no reason why there should be delays. On the other hand, when pfSense boots up, I see the gateway reports massive packetloss and/or latency for whatever reason, but then again - it has always been like that, so it makes no sense why disabling DNSSEC would cause any problems.
-
@Octopuss yeah it shouldn't that is for sure. And packetloss, you would think it still up?
So is your interface for wan actually a wifi interface in pfsense? But lets say your wan was just down, or had no ip yet.. sure ok dns can't work - but unbound should still be able to bind to your lan.. and local host. It shouldn't come up just showing bound to localhost.
Or is it a wire that runs to box that gets your internet from wifi.. But like said even if wan was down.. unbound should still bind to the lan interface not just localhost.
Maybe I will try and simulate by turning off the interface on wan before I reboot it in my VM..
-
This post is deleted!
