What has been irking you??  Not having a clue to how dns works… Yeah that would irk the shit out of me too to the point I would actually learn how it works..

Yeah, there can be multiple server etc. sections, however you need the section terminated first, so… as said above, the custom config shouldn't get stuck in between assuming that the content does belong to server:

Do your firewall rules prevent LAN hosts from querying LAN address for DNS? This just works out-of-the-box. Have to figure out what, specifically, you've done to make it not work.

It may work (I haven't tried it) but keep in mind pfSense will originate the relay requests from the IP address of the tun interface in this case. I know for certain it doesn't work properly with IPsec. If you have a managed switch, check and see if it has an "IP Helper" or DHCP relay function and enable it there rather than on the firewall.

Are things like the below screenshot normal? Just wondering, I've never seen such things before ("tstp never" or "cltt 3" etc).  This is from a 2.1.5 nanobsd system. [image: k8olsPD.png] dhcpd.conf attached dhcpd.conf.txt

WTH is this lsof nonsense over and over again? And ps auxw? This is not how you check things, as already said above. Also, you have 6 instances of DHCPd running, a bit too much if you ask me.

yes many are limiting any queries to tcp.. But those are normally limits in something else like F5 with an irule can block the any query if udp based. My point being is prob going to see it go away more and more..  Like I said can not ever have anything nice because of the damn kids ;)  Use to be able to real easy monitor your ntp servers clients as well, and they took that away ;)  Shoot I use to be able to use mail servers anywhere over port 25 from my home connection.  That is gone and most isp limit you to 25 only to their servers..

johnpoz - i can not go to example2 directly, because address "example1" is  hardcoded in this software, API which were available "long time ago" under "example1" is now under "example2". Simple as that. Yes, i'm sure that I'v had to reboot router, as i'v tested while ago, while adding next subdomain to existing SOA, it will work fine, but after adding SOA, this new domains under that new SOA will not work until router restarted. I'v tried to restart also svscan, no changes.

Now I understand why pfBlockerNG can't work with Forwarder to filter DNS. pfBlockerNG is using Unbound which have function Dnsspoof to do DNS filtering. https://calomel.org/unbound_dns.html

"3- double natting is not there, we natted only on modem and pfsense has no public ip it is directly" Huh??  That is a DOUBLE nat.. You may get better help in your native lang area… "2- yess fqdn with (public ip ) is not resolving and pinging from internal lan" How wold it PING if can not resolve??  I suggest you move to your native language area..

@johnpoz: Why would pfsense be handing your public DNS??  That is bad idea out of the gateway - pfsense does not run an authoritative name server… Did you install BIND on pfsense? If so it has full support for views and can handle split just fine. I do agree, reason why I'm explaining this  ;) I often see here and there, still discussing about pfSense : "yeah, easy, just use split DNS…" For sure split-DNS is sometimes the right answer to some specific question related ton internal vs. external access. However, I'm pretty sure this basic statement doesn't make clear for all that if split-DNS is the technical answer, this is not achieved relying on pfSense only  ;)

Of course.  The hosts with the VPN traffic.  Not the tunnel endpoint itself. I cannot elaborate because every network is different. Don't tell your VPN clients hosts to use pfSense as a DNS server.

You do understand that is if the client doesn't ask for a specific lease.. If they ask for 24 hours, unless you change the max to something below that then dhcpd would give them a 24 hours lease.

Had some time to bounce this a couple more times this morning and take a closer look.  This was not related to unbound at all.  There were a couple issues at play. The first was somehow I ended up without an IPv4 default gateway set. I have Multi-WAN configured so traffic from the LANs was being policy routed out the Tier 1 but traffic from the firewall itself such as unbound queries had no route after a switch reboot. The second issue was a couple VLAN assignments not saved in the switch config. This is where things can get a little dicey when you're mixing inside and outside traffic on the same physical switch. I generally consider it safe - until a mistake is made. An SG300-52 is on the way to replace this failing D-Link.

You have shown that pfsense hands back SOA and NX…  Therefore your client got no IP to try and go to, be it pfsense or elsewhere..  So how could it possible end up anywhere?  Your browser should show you CAN not connect to server, because it never got an IP to go too from pfsense. What I would do is sniff the traffic and see where in the world your browser is doing a query for that it would ever get an IP to try and connect to that could get redirect to your webgui page..

wrong order???  Why would there be an order??  If you want pfsense to be your dns, that is ALL there should be…  You don't use pfsense "and" list say google or 208.180 that doesn't even answer your query anyway...  Google doesn't know SHIT about any of your local devices, so is completely and utterly pointless to have the possibility for clients to ask google directly for anything and defeats the whole Fing reason for running dns on pfsense. If you are running forwarder or resolver your dhcp server should have ZERO anything in there for dns, since it will point to the IP address of pfsense on that interface which is correct..

No, it doesn't sound normal. Though perhaps you could try restarting the DHCP service instead of rebooting. It doesn't fix the issue, but it's less extreme. My only other observation is whether you have looked at any of your system logs. You may find the cause of the problem there.

No, it's NOT any loopback. It works across your LAN. Seriously, it's time to stop ignoring IPv6. These things have been enabled and preferred by default on any decently modern OS for years. (In Windows world, beginning with Vista.)

Thanks! For other peoples reference: https://doc.pfsense.org/index.php/DNS_Forwarder (The DNS Forwarder is not active by default. It has been replaced by Unbound as a DNS Resolver. It may still be used, and is still active on upgraded configurations) https://doc.pfsense.org/index.php/Unbound_DNS_Resolver (Enable Forwarding Mode: Controls whether Unbound will query root servers directly (unchecked, disabled) or if queries will be forwarded to the upstream DNS servers defined under System > General or those obtained by DHCP/PPPoE/etc (checked, enabled).)