Thanks everybody, I founded my error : a typo in the Dnsname! This case can be closed.

Mine has intermittent issues resolving yelp.to. and forums.lawrencesystems.com. If I wait a bit it will resolve eventually. Not sure what's causing this... [22.05-RELEASE][admin@pf]/root: dig yelp.to +trace ; <<>> DiG 9.16.26 <<>> yelp.to +trace ;; global options: +cmd . 83331 IN NS m.root-servers.net. . 83331 IN NS a.root-servers.net. . 83331 IN NS b.root-servers.net. . 83331 IN NS c.root-servers.net. . 83331 IN NS d.root-servers.net. . 83331 IN NS e.root-servers.net. . 83331 IN NS f.root-servers.net. . 83331 IN NS g.root-servers.net. . 83331 IN NS h.root-servers.net. . 83331 IN NS i.root-servers.net. . 83331 IN NS j.root-servers.net. . 83331 IN NS k.root-servers.net. . 83331 IN NS l.root-servers.net. . 83331 IN RRSIG NS 8 0 518400 20230204050000 20230122040000 951 . kgDwg7Khx9LoLCgFrS84CkJLkSDNOuBqtLAMat2craBdop37SNc716B3 g31YTlQxXL/y3vnRaxukwEk6MeC/ITL+YR+A3yzaiatUxg/+MacqmkGj m2F2TJ51Qem2yFHQJpiWwD6AWrfE2y2Volt4TAU6np9QkFVEBkcZzVp/ sGF89zD1frlpoZpnjaIXTI6R7vMb7yN1QXi7G6Jnp2f9b5gNU+3WaCU9 eDatxWHltAxh/3szYS2T7nbrkx35KuY2QkyGUZLEz+rSHgQ1AeCqvkBY oNTW/GJ7+V17xjpRgMcZumW9LDl544pheMs/fvaj+JRsFYfBbI1GmmEU v81cow== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms to. 172800 IN NS colo.tonic.to. to. 172800 IN NS tonic.to. to. 172800 IN NS sydney.tonic.to. to. 172800 IN NS newyork.tonic.to. to. 172800 IN NS helsinki.tonic.to. to. 172800 IN NS frankfurt.tonic.to. to. 172800 IN NS singapore.tonic.to. to. 86400 IN NSEC today. NS RRSIG NSEC to. 86400 IN RRSIG NSEC 8 1 86400 20230204050000 20230122040000 951 . nGj5h4bpgG1raL4+Tu/h065iVwAs8EWsQ8EKR+63cAxzPmGwYtiMgWr0 x/gMZYV89+DRqLRmeHVrHNgCeLCMhkoteqcLOjovfMiFCgVhUuGKN7qg OcqO1yrig2tn6n3H3OQh5T5iICC8WPhMCUgou0INmdM9RDO8Iavx4bv7 dRsZFy/m8Mw9D3n6IOUvRJXmtuSvgmtGiSQyWttaz35ZkVR0STK8Sr5v dYM5iW37qmqO3uatOipxefMS87F+z+v+yqQGpgdWxqulmPzFO3Tuk41L nbbiB+8uwAhvyZTfAs22izl+avw0X1fG34kB9WkS0l6fRp0XYCD/uxEe qnrZWA== couldn't get address for 'colo.tonic.to': not found couldn't get address for 'tonic.to': not found couldn't get address for 'sydney.tonic.to': not found couldn't get address for 'newyork.tonic.to': not found couldn't get address for 'helsinki.tonic.to': not found couldn't get address for 'frankfurt.tonic.to': not found couldn't get address for 'singapore.tonic.to': not found dig: couldn't get address for 'colo.tonic.to': no more [22.05-RELEASE][admin@pf]/root: dig forums.lawrencesystems.com. +trace ; <<>> DiG 9.16.26 <<>> forums.lawrencesystems.com. +trace ;; global options: +cmd . 83286 IN NS i.root-servers.net. . 83286 IN NS j.root-servers.net. . 83286 IN NS k.root-servers.net. . 83286 IN NS l.root-servers.net. . 83286 IN NS m.root-servers.net. . 83286 IN NS a.root-servers.net. . 83286 IN NS b.root-servers.net. . 83286 IN NS c.root-servers.net. . 83286 IN NS d.root-servers.net. . 83286 IN NS e.root-servers.net. . 83286 IN NS f.root-servers.net. . 83286 IN NS g.root-servers.net. . 83286 IN NS h.root-servers.net. . 83286 IN RRSIG NS 8 0 518400 20230204050000 20230122040000 951 . kgDwg7Khx9LoLCgFrS84CkJLkSDNOuBqtLAMat2craBdop37SNc716B3 g31YTlQxXL/y3vnRaxukwEk6MeC/ITL+YR+A3yzaiatUxg/+MacqmkGj m2F2TJ51Qem2yFHQJpiWwD6AWrfE2y2Volt4TAU6np9QkFVEBkcZzVp/ sGF89zD1frlpoZpnjaIXTI6R7vMb7yN1QXi7G6Jnp2f9b5gNU+3WaCU9 eDatxWHltAxh/3szYS2T7nbrkx35KuY2QkyGUZLEz+rSHgQ1AeCqvkBY oNTW/GJ7+V17xjpRgMcZumW9LDl544pheMs/fvaj+JRsFYfBbI1GmmEU v81cow== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20230204050000 20230122040000 951 . D9wfP4fjVUFOevkn3EmmvrjEwNcfNsIVQnMpQ07PJ1DNXM0XDMfTtUkI zBJPRG+tPrk186yy0F2VOeh3200WZiSVALd3JSq79ieZWUSDCQ/EzVBq +CgSQkJjmPm47u7FPK4fFmTL2BP1nv7Bwuxu5zQMa5WEjABQVWqGTmry Fcg7Z4omeIAgb5SiR+sFQuXlbA7fCqlsHK4coNvYsAXnuJEEKSAZ/oUN WigITLfgaJ6qHandU44wi8XHTMp33L+54Uy25PsTizyH8zc6QE3/+QN7 W/yaEn85ra0YVOIzExvs0/j769wXx+WSXcuU9JfDbYegkk3TvvtS/W1O gE/nQQ== ;; Received 1186 bytes from 193.0.14.129#53(k.root-servers.net) in 153 ms lawrencesystems.com. 172800 IN NS ns1.lawrence.technology. lawrencesystems.com. 172800 IN NS ns2.lawrence.technology. lawrencesystems.com. 172800 IN NS ns3.lawrence.technology. lawrencesystems.com. 172800 IN NS ns4.lawrence.technology. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20230126052302 20230119041302 36739 com. jU0jDdLit4qUktHrFwTh+jVxOYvRWcbFuSbj/IE2LkQ7FMcmUETuXuDV NZcBXYqVwxSiWjo38Q/x4o84qu10aLafUtUXlCe3uS8Ogkz9YWi9QEuh XmQmhYX9c0RIb0oKg/EGx5K6MflaG2aANx0QZCKefO0w0ejXTrzjXjUW Nhfb8NqRD4c2M1Sw4kdaUhBfiuq/rW2fL8WvyVEH3baXrw== U6O0OCQU8V5GTBRGTLMHBJ4G87A1EE0L.com. 86400 IN NSEC3 1 1 0 - U6O18CIKNDUF3GMAVN7R2VOV25LFBOK3 NS DS RRSIG U6O0OCQU8V5GTBRGTLMHBJ4G87A1EE0L.com. 86400 IN RRSIG NSEC3 8 2 86400 20230127063104 20230120052104 36739 com. pyXaWNOuNrS0orReEht37LeN6mqL0N1cnh/sA+EPdoqsJvDkuiBMpG3L anzx2jeVxtpYKL8PcAVFZ6/BOsgwL8gDZvOx8Zy9MLp4umRsyD78LnXn ytjok7zgJFSLV5WVrVZ/iF2Px3H+97wHovxiZ9S59v/2JKW8+JA+IU1s 3YA8BvwA+Qd3XLKxURK5UcLTytxTM/r727t21eMcQMKBsg== couldn't get address for 'ns1.lawrence.technology': not found couldn't get address for 'ns2.lawrence.technology': not found couldn't get address for 'ns3.lawrence.technology': not found couldn't get address for 'ns4.lawrence.technology': not found dig: couldn't get address for 'ns1.lawrence.technology': no more

@jpvonhemel its a random one - it will change as you change wifi networks.. And can change on its own on new connection.. Not a Fan to be honest that is for sure. https://support.apple.com/en-us/HT211227 Use private Wi-Fi addresses on iPhone, iPad, iPod touch, and Apple Watch The only good thing about it - is it is easy enough to turn off ;) It should from my understanding use that same random mac on your network, unless you reset it or forget that network... But then there is always this "if your device hasn’t joined the network in 6 weeks, it uses a different private address the next time it connects to that network" So if your device hasn't been on your network in a while, and it reconnects will use a different mac.. So yeah it can be problematic trying to create specific firewall rules for specific devices with such a "feature" ;)

@steveits said in DNS Resolver Not Working/Logging: @johnsoga so it needed an ACL? Does that interface have a gateway? Internal interfaces should be allowed. https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-acls.html Not sure about the log Q, sorry. Hmmm good catch I see what you mean from the documentation: "By default, IPv4 and IPv6 networks residing on internal interfaces of this firewall are permitted. Additional networks must be allowed manually." I would think this interface would considered internal idk how/where that configuration is made, but to answer your question, nope, no gateway. [image: 1673927195699-screen-shot-2023-01-16-at-10.42.50-pm-resized.png]

This has been addressed in the latest snapshots. We are testing the changes and will include them in 23.01 which is due soon. The issue is multifaceted. I've submitted upstream patches to both Unbound and the MaxMind DB Python module. The MaxMindDB Python module had several issues. The major issue though was a reference counting bug causing the Python garbage collector to prematurely free a heap-allocated structure. This led to a use-after-free causing Unbound to segfault. Unbound reloads the built-in Python interpreter every time Unbound is reloaded either by a SIGHUP signal or using the unbound-control interface. Python was not designed to be reloaded like that in the same process. I've fixed the refcounting bug in Maxmind, and patched Unbound so Python is only initialized and unwound once. I've also upgraded Python from 3.9 to 3.11. The memory usage should be significantly improved. The next improvement would be to rewrite the integration with ISC DHPCD to use a better interface with Unbound. That likely will have to wait until 23.05

@pgomes2000 Let's say you use vlan 10 for the WAN and VLAN 11 for the LAN. You can use any number you want between 2 and 4093. You would connect the nic from the laptop to one port on the switch. This port will need both vlans tagged on it. It's called a "trunk" port. Then you would untag vlan 10 on another port. That port will connect to your internet. Untag vlan 11 on any other ports you want to be LAN ports.

@gulzoa712 no they wouldn't answer ping.. they are not valid fqdn.. Your kmaster.home.arpa would resolve - but not going to resolve with just kmaster unless your search suffix on your client is actually set to home.arpa [image: 1673439215917-searchsuffix.jpg] is 15.213 and .212 actually DNS? Why are you pointing pfsense to those for dns? Are you even forwarding - unless your forwarding there is almost no reason to set dns in general. Out of the box pfsense resolves, it does not need you to set any dns unless your going to forward to them.

@johnpoz I know, I just needed to test this out, it will be removed and a local zone will end up being used on the network as an override.

@tikiyetti for starters you should really update pfsense, that version is quite dated. If you want to do your own dnssec, then yes you should just resolve which is what unbound does out of the box. Or if your wanting to forward then just pick a dns that does it already and uncheck dnssec in unbound. I am not aware of any of the major dns providers that do not do dnssec out of the box - some of them have special IPs you can point to that don't do it - like the 9.9.9.10 IP for quad9, etc.. But pretty much any of the major players are doing it out of the box. So there is little point to having unbound try and do it if your forwarding - more likely than not just going to cause you possible issues at some point or another. Its just extra work for something that is already being done. If you order a cheeseburger, do you scrape off the cheese when you get it an put your own cheese on? If you want to control putting cheese on your burger, just order it plain (resolve) and then do your own thing for the cheese ;)

A quickie python script to help anyone (hint: need to paste lowercase characters into the pfsense dialog) #!/usr/bin/env python3 import sys for arg in sys.argv[1:]: print(f"{int(arg):02x}:", end="") An example use for route 192.168.55.0/24 using gateway 192.168.3.2. $ ./hex.py 24 192 168 55 192 168 3 2 18:c0:a8:37:c0:a8:03:02: In pfsense Admin UI, at DHCP Server / LAN section Additional BOOTP/DHCP Options, add a line Option entry with field values 121 (Number) String (Type) 18:c0:a8:7c:c0:a8:08:7c (Value - no quotes) then Save I recommend packet capturing a response from the DHCP Server then review in Wireshark. Find the response packet with Protocol value DHCP. The Wireshark protocol parser will identify errors for you (with detailed error messages). Thanks both for posting this info. You saved me much time. Thought I add a few suggestions in case it helps anyone.

@bmeeks @johnpoz Yes, I know that DNSSEC is not for encrypting queries. Thank you for the link. I'll read it anyway. I disabled it, and I also unchecked Prefetch DNS Key Support and Harden DNSSEC Data in the Advanced Settings; I guess they are not of any use since DNSSEC is disabled now, aren't they? I enabled Unbound because I want to use DoT and pfblocker as well. As I already said above, I started using pfSense again after quite a long time. For the record, I had a bad experience with OPNsense and I switched back to pfSense as my main alternative to my Mikrotik device as a firewall/router Anyway, I remember that I had some issues with pfSense's Unbound long time ago. It just didn't work with one ISP as upstream gateway, while it worked flawlessy if I switched to another ISP (via LTE). It seemed the the first ISP blocked access to the root dns servers..maybe. Never figured it out for sure. Thanks again

@johnpoz said in Different DNS forward based on subnet/VLAN?: While forwarding per view might not be documented in unbound, the subject has come up multiple times and you might be able to put forward in your view, etc. Found it as an Enhancement Issue. They understand the caching implications and have no plans to implement. First raised in 2020; someone asked for an update in Nov 2022 but no reply yet ;)

@thondwe yeah clouldflare does dnssec - no need to enable it in unbound $ dig www.dnssec-failed.org @1.1.1.1 ; <<>> DiG 9.16.34 <<>> www.dnssec-failed.org @1.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25889 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.) ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; Query time: 99 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Sat Jan 07 06:20:31 Central Standard Time 2023 ;; MSG SIZE rcvd: 107 all the major players do dnssec - unless they have a specific IP to use that doesn't - but all of the main IPs of the major players are doing dnssec out of the box - if your going to forward to them, no need to have it checked in unbound.

@bmeeks Got it. I've made the update and it still works. Thanks again for all the help and detailed answers to help me understand how the system works.

@a1aba You're gonna have to show some pics. Are you sure you're plugging into the correct interface? If you assign a static address on the same subnet, does it connect?

The issue turned out to be an invisible leading space in the hostname (copy/paste must have grabbed an extra leading space). Shouldn't the code be smart enough to trim() the input?