Is this normal behavior for the Resolver to act that way?
-
@johnpoz I wiil try it and report back. I will even strip my FW of packages and NAT relating to DNS forwarding and OpenVPN client that I have.
Thank you for your generosity in all these matters.
UPDATE:
I can confirm that selecting only Localhost for outgoing interface works, as you showed.
BUT the problem remains for me. DNS is not working after a reboot, if WAN is not also selected. After the reboot, when DNS is not working, restarting unbound brings it back. Again, here, the problem only shows after a reboot if WAN is not selected in Outgoing Network InterfacesI need to test further without any packages and custom NATs. But I doubt that will be it. I also have a floating rule on the WAN interface to block any communication on port tcp/udp 53 (I only use 853). But it does not seem to trigger as I am logging this rule and nothing shows in the logs.
-
@marchand-guy said in Is this normal behavior for the Resolver to act that way?:
Again, here, the problem only shows after a reboot if WAN is not selected in Outgoing Network Interfaces
Not the listening interfaces?
What outbound NAT rules are you using?
-
@stephenw10 said in Is this normal behavior for the Resolver to act that way?:
Not the listening interfaces?
What outbound NAT rules are you using?
No, the problem seems to be related to the selection in Outgoing Network Interfaces.
My outbound NAT rules are as follows:
-
Hmm, I can't replicate that.
Check the state table when DNS is failing. Are there DNS states? On which interface?
-
@stephenw10 Will do but not now. The wife is annoyed when I cut her internet
Good tip on checking the states while failing.
Thank you. -
@stephenw10 If you can't replicate, it means it's particular to my installation. I will need time to investigate.
Thank you
-
How are you testing? After reboot I tested from Diag > DNS Lookup and can see Unbound responding on localhost.
I could imagine the internal forward rule doing something odd at boot perhaps.
-
@stephenw10 Ok! Thank you for sharing that. That is NOT how I test. I test from different machines, starting with my computer. None of my browser bookmarks respond after a reboot of the FW. Until I restart unbound, as stated.
-
Mmm, so it could be some LAN side issue. Try checking from Diag > DNS Lookup locally to narrow it down.
-
@stephenw10 Diag DNS Lookup responds after 16 seconds! No replies on the LAN side with my computer. At this point, the problem is on my side. I will continue to investigate and report anything useful.
Thank you
-
@marchand-guy did you mean 16ms? no client would wait 16 seconds for a response before giving up.. 2 seconds or 5 seconds are normally time limits for dns response.
You could ask a ns on the other side of the planet, and he could ask another ns on your side of the planet and it still shouldn't be anywhere close to 16 seconds.. Something is wrong if your measuring dns response in seconds vs ms.
-
@johnpoz You read it right 16 SECONDS. Clearly, after a reboot, the DNS service is defective until i manually restart unbound from the GUI. I need to backtrack everything I did untill I find the setting that creates this ptoblem. Although I can't stop wondering how many of you use SSL/TLS for outgoing DNS Queries to Forwarding Servers, plus, have not selected All interfaces by default as I did, plus, have disabled IPv6 (even though it is still showing on the dashboard as a listening address for DNS), and have rebooted with that configuration,
-
@marchand-guy said in Is this normal behavior for the Resolver to act that way?:
(even though it is still showing on the dashboard as a listening address for DNS),
there was just a thread about how to make that go away if it bugs you.. That ::1 is just ipv6 loopback. Was that you?
Dashboard isn't a listening address, that is NS that pfsense can use. Not IPs of unbound listening on.
I can tell you there are quite a few users doing the tls forwarding.. I personally don't see the point.. But as you can see from my previous test it works just fine - and makes no sense that it wouldn't work unless your listening on your wan..
You sure you don't have clients pointing to your wan address or something?
Taking a look at your outbound nats - yeah those are borked if you ask me, and could explain your issues maybe - your forcing traffic out your vpn and have no nat for just your normal lan side networks to be able to use your wan IP natted. You followed some idiot guide from some vpn services didn't you.. There is zero reason to do manual outbound nat - just use hybrid and map what you would need for vpn interface you want to route traffic out.
example: I can route anything I want out my vpn connection if I so desire..
Those other outbound nats are to talk to my modem on its 192.168.100 address and I do source natting to talk to cameras behind a nvr because they use the nvr as their gateway.
-
Yup I use forwarding to DoT in 2.8 here without issue.
What does DNS Lookup actually show? For example:
That's with DNS set to 'use local, fall back to remote' in general setup.
If you have other servers that are not responding you will see significant delays.
-
@johnpoz Borked outbound NAT, you say? Here they are again:
I control what goes trough the VPN interface with rules that specify the VPN1 interface. All other rules use the default WAN interface, as it should.
Anyway, I need to investigate further.Thank you.
-
@stephenw10 The "recipe" for ssl/tls forwarding specifies "Set DNS Resolution Behavior to Use local DNS (127.0.0.1), ignore remote DNS Servers"
https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html
-
@marchand-guy your previous post was missing this one
-
@johnpoz I know. That's why I reposted it. I should have guessed that you would make the effort of looking at it
-
@marchand-guy said in Is this normal behavior for the Resolver to act that way?:
"Set DNS Resolution Behavior to Use local DNS (127.0.0.1), ignore remote DNS Servers"
yeah technically that is true - or you could have a scenario where pfsense directly talks to servers you have in general without the tls. So guess you have to live with the ::1 listed as NS you could talk to ;) Or you could run into a scenario where pfsense doesn't use tls to talk to your remote tls server you want to talk to. When itself wants to resolve something - like is there an update available, need to pull the list of available packages.. etc. but clients talking to pfsense IP for dns would not.
-
Yup that's why I mentioned it since you would normally only see local host there if you have followed the guide.
But importantly you should not see anything that's present and unresponsive.
