@SteveITS Checked it several times, no problems thrown. Opened up the file to give it a look over and I don't see any show stoppers. I have switched back to ISC for now which removes the problems with unbound. I will attempt a fresh install on the appliance once I get the ability for some downtime.

Thank you @Gertjan for the reply. My next pending will be setting pfBlockerNG DNSBL to "Unbound python mode", and then change DHCP from ISC to Kea.

I ran into this again...a client lost access and I'm confident it was this scenario with the FQDN update removing the IP from the alias. It seems necessary that the FQDN IP update either doesn't blindly remove the IP, or else some other task runs to add the static IP back in again if it is listed separately in the same alias.

Thank you @SteveITS for the reply.

Here is a summary of noip.com free vs paid DynDNS. I use them as my domain registrar and email hosting. [image: 1767176618684-screenshot-2025-12-31-at-5.21.57%C3%A2-am.png]

@darellcraighead1 said in Dynamic DNS (DDNS) fails to obtain public IP: Turns out Charter Spectrum has also turned off ping response on our default gateways. Your pointer to the Reddit article gave me the clue to turn off monitoring - that was initial fix. Then I changed the monitoring IPs to Cloudflare's DNS and v6 and everything now works as expected. Glad you figured it out! I basically went through those same steps. It's a weird issue as the symptoms and solution seem really unrelated lol.

@pst said in unbound persistent zone file: if unbound does a chroot(/var/unbound) then the configured zone file path should not contain the "/var/unbound" part as that "disappears" as part of the chroot(). The /var/unbound/zones/ directory is accessible as /zones/ to the unbound process. Thx for spend your time to test this, but that's not really the problem. I probably didn't focus on it enough in my first post: Mentioning content in /var directory is not persistent I meant that RAM Disk("Use memory file system for /tmp and /var") setting enabled. That's why I was looking to place zone file outside of /var directory. Since there is no way to "bypass" chroot for zone files, I had to stop using the RAM disk in pfSense to resolve original problem.

@patient0 Hello patient0, I reloaded the backup configuration, re-change the LAN interface IP and now it seems to be working. Many thanks for your help!

@SteveITS thx, with dns resolver it worked directly

@fyshed Sorry for the late reaction, but this solved my problem. Thanks for this answer!

@rsheffield I installed the two patches : [image: 1766560885837-230cd922-0169-4acd-964c-c752da017a4f-image.png] These two from here https://redmine.pfsense.org/issues/16602 b803fd3b25861b8365a2150528fc29b43f625bf2 ff266a35fd4dafba90d60f94dd481aa7eda3301c Create a new patch. Copy past, fro example, b803fd3b25861b8365a2150528fc29b43f625bf2 into the "URL/Commit ID" field. I used the forum URL as the description. Save. Fetch. Apply. And again for the second one. Both applied well.

@Gertjan Sorry delayed response. This is happening with all non-static DHCP leased Windows clients. So for example, if I dump the leases directly from Kea I get: desktop-0mlm8mr. 192.168.1.10 But dumping the unbound leases4.conf gives me: local-data: "desktop-0mlm8mr.example.net. IN A 192.168.1.10" I believe pfBlocker-NG is using the hostname that's output from the Kea leases to test resolution as you noted, however it won't resolve that name due to the trailing '.'. Statically assigned leases show the hostname without the trailing '.' so they resolve properly. I won't muddy this up any longer, I just read @cmcdonald post in the problems installing sub.

@Gertjan Cloudflare's servers under General Setup - basically a copy of what's on the DNS over TLS docs. DNS Resolver has the following enabled: Enable SSL/TLS Service Strict Outgoing Network Interface Binding System Domain Local Zone Type: Transparent Python Module (Pre Validator, pfb_unbound) DNS Query Forwarding (both forwarding mode and SSL/TLS checked) Most of the advanced settings are at default with prefetch enabled, though if you want a config dump or something let me know.

To clear Unbound's cache: unbound-control -c /var/unbound/unbound.conf reload To clear a single domain: unbound-control -c /var/unbound/unbound.conf flush [www.example.com] To 'dump' the cache for inspection: unbound-control -c /var/unbound/unbound.conf dump_cache

3 or so hours later..... turns out that me using my corporate laptop as a test was the issue. I guess I was voulenteered to be in some test group for new NAC features :) Using any other device works fine (apart form missus screaming for disconnecting her mini pc for testing :D )

@richardsago that’s a long time ago… Anyway that is the point of “Deny unknown clients” and yes it does work.

@mtarbox ah, glad to hear that. Thanks for sharing an update!

@nazar-pc Would have to consult DHCP spec. Could be a valid report for upstream, but I'm not sure.

@SteveITS yeah you could prob look up the old threads - this has been discussed multiple times in the past ;) I concur that /24 might be a friendly more common default - but when it comes down too it, the admin of the firewall should know and set this to what they want to use. What it defaults to becomes irrelevant. You could complain that windows when setting IP that starts with 10 - defaults to 255.0.0.0 ;) [image: 1765916226150-windows.jpg]