DNS Setup
-
Also : the Resolver doesn't need any additional setup to function.
No need to do what so ever - NO DNS IPs to enter, no need to forward. Nothing.
In other words ; out of the box, it works.
That it, the WAN interface must work.What did you see Status > System Logs > System > DNS Resolver ?
-
@ghostshell said in DNS Setup:
Per the docs I added 2 external DNS servers unde
Where in the docs does it say to do such a thing?
My guess is running a vpn - and the vpn doesn't like other dns used other than them..
As stated unbound just works out of the box.. Nothing to do - but its possible you have tinkered with its settings? The only time unbound would not work out of the box is your wan connection block talking to dns, or limit what dns you can talk to. Or your connection is just horrible on latency - like sat connection.
-
for both sections "All"
-
@steveits I see the external set answering and nothing from 127.0.0.1
-
https://docs.netgate.com/pfsense/en/latest/troubleshooting/dns.html
also turned off rebinding per this
https://redmine.pfsense.org/issues/10685
-
@gertjan For a long time I never used it so its just been the default, I wanted to use pfblockerng so I just started using pfsense as the DNS. I did tinker, but after I noticed that things were not working. After trying the troubleshooting steps in the guide I posted and that one setting I stopped to avoid more issues. I noticed when I did a DNS lookup in the control panel 127.0.0.1 always gave no response. At this point I wondered why. I enabled forward in the resolver, enabled python mode as pfblockerng did that when I enabled it there, then diabled DNSSEC per that guide as troubleshooting steps, other then that I disabled rebinding. All other settings were left as is/pre populated.
-
@gertjan You mention the FW blocking DNS, if that was the case, if I set my laptop to use say google's DNS, if it was blocked wouldn't that not work? I ask as thats how Ive been testing and when I do this everything works well. Only have issues using pfsense as the DNS.
-
@ghostshell said in DNS Setup:
Only have issues using pfsense as the DNS.
Again :
Also : the Resolver doesn't need any additional setup to function.
No need to do what so ever - NO DNS IPs to enter, no need to forward. Nothing.
In other words ; out of the box, it works.
That it, the WAN interface must work.Which brings you :
@ghostshell said in DNS Setup:
For a long time I never used it so its just been the default,
So it worked.
@ghostshell said in DNS Setup:
I wanted to use pfblockerng so
You didn't need to anything to the Resolvers settings.
Just be sure these are set as indicated :DNSSEC can be set (optional). It's set by default.
The Resolver is resolving - so not set by default.@ghostshell said in DNS Setup:
You mention the FW blocking DNS,
Did I ?
Did you block DNS TCP UPP port 53 some where ?Default, unbound listens to 127.0.0.1 :
and because I never believe a GUI for it's word (image) as I have a way to test that :
[2.5.2-RELEASE][admin@pfsense.local.net.net]/root: sockstat -4l | grep 'unbound' unbound unbound 7136 5 udp4 *:53 *:* unbound unbound 7136 6 tcp4 *:53 *:* unbound unbound 7136 7 tcp4 127.0.0.1:953 *:*
The first two lines confirm these two settings :
Note : *:53" means : listen to all local NIC (IP's) on port 53 (TCP IPv4 and UDP IPv4)
The third line shows :
and only listens locally (127.0.0.1).
As unbound is listining on any NIC, I can do this just fine :
Ask to 127.0.0.1 what the IP of www.google.com is :[2.5.2-RELEASE][admin@pfsense.my.net]/root: dig @127.0.0.1 www.google.com +short 64.233.162.106 64.233.162.147 64.233.162.105 64.233.162.103 64.233.162.104 64.233.162.99
I could replace the @127.0.0.1 for any of my LAN type IP's. I could even use the WAN(s) IP !
Btw : look again at the sockstat command result above.
The unbound process number is "7136" an should not change every minute or so.You can re check with :ps -ax | grep "unbound"
after all, if unbound was restating very often, it would really look like it = DNS isn't functioning. During the restarts it can't answer your DNS requests.
-
root: sockstat -4l | grep 'unbound' unbound unbound 80578 6 udp4 *:53 *:* unbound unbound 80578 7 tcp4 *:53 *:* unbound unbound 80578 8 tcp4 127.0.0.1:953 *:*
ps -ax | grep "unbound" 80578 - Is 0:51.51 /usr/local/sbin/unbound -c /var/unbound/unbound.conf 95420 - S 0:51.41 /usr/local/sbin/lighttpd_pfb -f /var/unbound/pfb_dnsbl_lighty.conf 1412 0 S+ 0:00.00 grep unbound
Note: when pfblockng updates part of the update shows it stops and starts ubound so the PID does seem to change per that update process. I can post the update process to show you what I mean if needed.
Many thanks for your screen shots and info. After matching your settings I tried dig and get this:
dig @127.0.0.1 www.google.com net.c:536: probing sendmsg() with IP_TOS=b8 failed: Can't assign requested address ; <<>> DiG 9.16.12 <<>> @127.0.0.1 www.google.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached dig @192.168.1.1 www.google.com +short net.c:536: probing sendmsg() with IP_TOS=b8 failed: Can't assign requested address 142.250.68.68 dig @localhost www.google.com +short net.c:536: probing sendmsg() with IP_TOS=b8 failed: Can't assign requested address 142.250.68.68
Found this and I have the same issues, I am about to upgrade from 2.5.1, but seems to be matching my problems.
https://forum.netgate.com/topic/162791/dns-randomly-stops-working/12
-
@ghostshell said in DNS Setup:
Note: when pfblockng updates part of the update shows it stops and starts ubound so the PID does seem to change per that update process. I can post the update process to show you what I mean if needed.
Exact. I know ;)
And not only pfBlocker-NG can/will restart unbound often.@ghostshell said in DNS Setup:
I am about to upgrade from 2.5.1,
Oh.... the issue is solved then.
2.5.2 exists, and solved a stability issue with unbound.Even when you do not upgrade right away, you should look at the release notes.
Checkout what has been said under "DNS Resolver".I've seen the same errors, when using 2.5.0 and 2.5.1 : on 'localhost', processes using ports to listen 'vanished', like localhost (127.0.0.1) itself crashed.
2.5.2 corrected that. -
@gertjan OK, I will upgrade when I can, I have not had much time to do much on my home net due to work, sorry I did not mention my version earlier. Only came to that conclusion when I found that other post after you had me try dig and then searched that error. Now I know what to check and what info to always post. Thanks again.