Pfsense and hostname resolution
-
@rjcab well that is some bad wording it seems.
If you want pfsense to ask 8.8.8.8 for dns, that is forwarding mode, and yes your 8.8.8.8 needs to be in dns settings. Unbound in forwarding mode - and turn off dnssec in unbound.. Using dns when you forward is going t be nothing but problems.
Clients should be asking pfsense for dns, you would not hand the clients 8.8.8.8 in dhcp. by default dhcp hands out pfsense on that interface to clients for dns.
That settings is for pfsense itself, and has nothing to do with clients on your network.
-
@johnpoz thanks for the clarification. So new am a bit lost, I follow only your advice but not working so far.
When I look at what I want it seems very easy but actually tricky to configure :( -
@rjcab said in Pfsense and hostname resolution:
When I look at what I want it seems very easy but actually tricky to configure :(
Starting from a pfSense with 100 % default settings :
- don't activate the new KEA DHCP server - make sure that ISC DHCO is active. [ so basicly, do nothing ]
- option A) On the unbound / resolver main settings page, make sure this option is set :
(the first DHCP Registration)
Or, Option B) don't cehck "DHCP Registration", as Static DHCP is already checked : add for every device a DHCP MAC Lease like this :
On the DHCP server page, at the bottom.
And now you're good.
Remember : don't switch to KEA.Notice : don't need to forward - why would you ? (can you tell me why you think you have to forward to some DNS server like 8.8.8.8 ? ) no need to add 1.1.1.1 or 8.8.8.8 etc.
Everything works
-
Well done :-)
I missed that
-
@rjcab what are you doing normal dhcp, or your previous posted image showed static reservations. You do not need to register dhcp if your doing reservations for all your devices.
This is a reservation, and they are loaded when unbound starts..
And they will resolve be it the client is on or off, or has gotten its reservation or not..
Now if you want to resolver xyz.yourdomain.tld that is some dhcp client that you have not set a reservation for - then yes you would have to register dhcp clients.
-
@johnpoz I did come here too when my config went to shit. I changed several configurations and then FQDN just broke and also DNS registrations between different networks. Why the hell do they scare you too go to KEA when the damn thing is not finished at all. Because i did other configuration in custom options i did think it was me that made a mistake in configuration and pulled my hair out for 2 hours. But it works out to be pfSense devs pushing shit out that ain't ready yet.
-
thanks a lot for your support
-
Now I have another issue:
I got 502 Bad Gateway, nginx message so I did 16) Restart PHP-FPM and it works for several minutes and then down again.
I went to the log files and I saw a lot of:could not connect to /var/run/php-fpm.socket pfsenseI found on internet and some guys are talking about ethernet drivers. I have one interface LAN embedded with the NUC and I have an USB ethernet plug (WAN).
WAN (wan) -> ue0 -> v4: 192.168.10.253/24 LAN (lan) -> re0 -> v4: 192.168.1.1/24When I unplug the usb it seems working. The USB plug is well recognised.
If you have an idea :-)
-
Hello,
One again. My previous post, I don't know but is work with a fresh install except for DNS Resolver.
I did as below:
If I remove the DNS 8.8.8.8 because it cannot resolve IP/Hostname I don't have internet anymore but hostname resolving works.
I one again made a mistake :(
-
@rjcab if you enable forwarding you need to uncheck the option to use DNSSEC.
-
@rjcab said in Pfsense and hostname resolution:
except for DNS Resolver
Why ?
Ok, it's a free world, but why do you have to give all your DNS requests to Alphabet ?
What's in it for you ??Also, Netgate decided to use the Resolver and made it resolve ... because that's what is best since the invention of DNS way back, in the last century. If any (commercial of not) other resolver was better, they would have made it 'default'. Notice this : they didn't. And I trust their choice.
Better : 8.8.8.8 is a ... a resolver. So why would a resolver (put in forwarding mode) has to ask a resolver what it can do itself ?Again : forwarding isn't bad, and I can image their are for some scenarios even some advantages.
But out of the box, DNS of pfSense works fine, and you get the free DNSSEC as a bonus.So, why ?
-
I haven't explained correctly.
I am newbie with pfsense and I just want to be able to resolve hostname within my LAN.
with the above conf it doesn't work :( -
@rjcab well no duh... How would 8.8.8.8 know about your local resources?
If you want to resolve your local stuff - you need your client to point to pfsense for dns.. So you can register your static/reservations of your dhcp clients. Or manually create records.. Then you can have unbound/dnsmasq forward or resolve for your internet stuff. But pointing your clients to 8.8.8.8 or any other external dns is never going to be able to resolve your local stuff.
Remove that from your dhcp options, let your clients renew their lease so they point to pfsense IP for dns - then you will be able to resolve local resources.
-
Yes thanks.
I did remove 8.8.8.8 and DNS resolver works:
~ ping jeedom.local.lan PING jeedom.local.lan (192.168.1.12): 56 data bytes 64 bytes from 192.168.1.12: icmp_seq=0 ttl=64 time=10.160 msbut:
➜ ~ ping google.com ping: cannot resolve google.com: Unknown host ➜ ~ ping google.comI don't know where is my mistake
-
@rjcab if your going to forward with unbound.. make sure you disable dnssec.. It can be very problematic when you forward, and serves no point.
Or just uncheck forwarding in unbound and let it resolve.
-
like this:
but dosen't work :(
-
@rjcab well why is the question - is your connection blocking roots? dns in general - are you using some vpn? There have been a bunch of threads lately about nord intercepting dns traffic for example..
from a cmd line on pfsense do a simple dig trace..
23.09.1-RELEASE][admin@sg4860.home.arpa]/root: dig www.googe.com +trace ; <<>> DiG 9.18.16 <<>> www.googe.com +trace ;; global options: +cmd . 65798 IN NS j.root-servers.net. . 65798 IN NS k.root-servers.net. . 65798 IN NS l.root-servers.net. . 65798 IN NS m.root-servers.net. . 65798 IN NS a.root-servers.net. . 65798 IN NS b.root-servers.net. . 65798 IN NS c.root-servers.net. . 65798 IN NS d.root-servers.net. . 65798 IN NS e.root-servers.net. . 65798 IN NS f.root-servers.net. . 65798 IN NS g.root-servers.net. . 65798 IN NS h.root-servers.net. . 65798 IN NS i.root-servers.net. . 65798 IN RRSIG NS 8 0 518400 20240409050000 20240327040000 30903 . uF8On7dU364u/1APqsZDUQ/yELDC0Q2qBe/VOS9rFdj0GWeEx23rJO7e u1RBxmM8cYPhXGREOoSCd7eZdJOX+S935JjmvCAQ2VKX9oWPq4SSYl1O S4st+q/LZvE6PSJcrEr+C3lGW0nk9X00CSeMspy5CNpcql9FP9L+AfWI 2BoSiph4C1Y4Sjck2i40KyM2r619CJtwgendnDVaN17ADJoObB1Hh7VH TvCCNtSICUxptHxNOEgIUa9VLcRFLXZytwvxhN0DkeK6j/jBrv6W3IAS uYUzYYpfZhyp+ip97758xUpIHtNQzSwdZetrv+EC5mDWPCMvfnTDcXTx zkIS+g== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 86400 IN DS 19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A com. 86400 IN RRSIG DS 8 1 86400 20240409170000 20240327160000 30903 . BeqXEhueT8CzqQiy1AF0tlI2GOSdpCvFv7WpfE87quXLLJDCPc9dQvm9 6jbzwIyt3SzdqDQg+SJxTYoTi4EvEMJxwGcnQAJAm5YcrVL8Lg3Mw4Uo r2p/Xb0eCsUUgDJOu7sU3BOmIzdwelAtfd/j2uqkVNtQIu67reI95xux kypY/sZekggzudrrh6AXZgZDwENLuPZUpZdYNkU5dMPrhbOiQpumPEfJ n/Z4N7Aq3sjof+MV9Zv2ySP/2vfxoCmQfkeya3jB1LvUeyWtXxdxpsEo jSKux31/CrhT3Z+NED9mv7Qxyb6DiFjeft2Fwo23oZldSdlBFJXd3kKL 4qDL1w== ;; Received 1176 bytes from 202.12.27.33#53(m.root-servers.net) in 54 ms googe.com. 172800 IN NS ns1.hsicell.com. googe.com. 172800 IN NS ns2.hsicell.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 13 2 86400 20240402042515 20240326031515 4534 com. ychk678G5UM6KBOrkgzAFJFDbABT0ZGSxn9UfrDSR8PN61oqXASJnuv7 G/ZyNEA4NZ0AQjDIthrA9VDCDOBOLg== 1TIGO4C7QL50GVJJT0D07PBKRG635RSM.com. 86400 IN NSEC3 1 1 0 - 1TIGST5CJ1UA1R58QTH9RGKOM94L5MF8 NS DS RRSIG 1TIGO4C7QL50GVJJT0D07PBKRG635RSM.com. 86400 IN RRSIG NSEC3 13 2 86400 20240402044039 20240326033039 4534 com. L6WtUXKT8ZbYJDaLEA74DIygNdCM6qwI3z5luRiR3ou7SjdY81Xg2lz7 6EQKPaeZ7b5IVzpYcz/ft26Bss+GFA== ;; Received 475 bytes from 192.55.83.30#53(m.gtld-servers.net) in 8 ms www.googe.com. 3600 IN A 162.243.10.151 ;; Received 58 bytes from 192.241.232.216#53(ns2.hsicell.com) in 66 ms [23.09.1-RELEASE][admin@sg4860.home.arpa]/root:This is exactly what unbound does in resolve mode - if that doesn't work, then no your not going to be able to resolve.
-
Hello @johnpoz
Thanks again for your support.
here what I've done:[2.7.2-RELEASE][admin@pfSense.local.lan]/root: dig www.google.com +trace ; <<>> DiG 9.18.19 <<>> www.google.com +trace ;; global options: +cmd ;; Received 28 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms [2.7.2-RELEASE][admin@pfSense.local.lan]/root: ping google.com ping: Unknown host [2.7.2-RELEASE][admin@pfSense.local.lan]/root: ping jeedom.local.lan PING jeedom.local.lan (192.168.1.12): 56 data bytes 64 bytes from 192.168.1.12: icmp_seq=0 ttl=64 time=0.265 ms 64 bytes from 192.168.1.12: icmp_seq=1 ttl=64 time=0.261 ms ^C --- jeedom.local.lan ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.261/0.263/0.265/0.002 ms -
@rjcab said in Pfsense and hostname resolution:
; <<>> DiG 9.18.19 <<>> www.google.com +trace
;; global options: +cmd
;; Received 28 bytes from 127.0.0.1#53(127.0.0.1) in 1 mswell you got something wrong there for sure if you can not even get the root servers back...
So no I don't see how you could "resolve" anything.
-
more I deep dive in Pfsense, less I am good at.
*** Welcome to pfSense 2.7.2-RELEASE (amd64) on pfSense *** WAN (wan) -> re1 -> v4: 192.168.10.253/32 LAN (lan) -> re0 -> v4: 192.168.1.1/24And from terminal pfsense I am not able to ping WAN interface of my Box router which is 192.168.10.254 from a fresh install:
[2.7.2-RELEASE][root@pfSense.local.lan]/root: ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.110 ms 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.134 ms ^C --- 192.168.1.1 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.110/0.122/0.134/0.012 ms [2.7.2-RELEASE][root@pfSense.local.lan]/root: ping 192.168.10.254 PING 192.168.10.254 (192.168.10.254): 56 data bytes ping: sendto: No route to host ping: sendto: No route to hostSeems I have a route issue but automatic rules are here:
