@pftdm007 not quite - if you are not in forwarder mode, unbound resolves what was asks from the roots down.. It doesn't send the query anywhere - it resolves vs forwards. And not so much pfsense passes it to unbound, unbound is listening on 53, and as long as your firewall rules allow it - unbound will get the query directly. When you resolve - you don't need anything in the general setup at all. If pfsense itself needs to resolve something it will ask itself (unbound) via the loopback address 127.0.0.1 the only time something like 8.8.8.8 would be used if you have it in general is if pfsense itself wanted to lookup something and unbound wasn't answering. Or you were in forwarding mode, be that either native (just 53) or in dot mode (853 with encryption of the connection via tls) Now that you know normal dns works - you could go back to forwarding if you want. I personally not fan, but sure if you want to forward forward.. Only thing I would suggest if you forward is uncheck to do dnssec. It can only be problematic if you forward - where you forward either does dnssec already or it doesn't, if it doesn't telling unbound to do dnssec is just going to cause extra queries, and could cause problems. Also forwarding to different services can be problematic as well - especially if they do filtering, and the filtering could be different. Since you don't really know which one will be forwarded to when you have more than 1 service.. You are not sure which filtering you would get.. Its best if you forward to pick 1.

@TonyB972-0 said in WAN seems to be getting next hop IP address, not public IP address: 192.83.xxx.1 address that was not. 192.83 is public IP. Your maybe thinking of 192.168 which is rfc1918 btw - not sure where your using some 208.93.xxx.xxx, because your not talking to pfsense with that IP, nor does your history ever show you connecting with an IP that starts with those 2 octets.

@ayansaari Check your ACL configuration to see what IP Ranges are allowed to use the resolver service [image: 1762934081170-8c991ce8-5581-4d2f-9fa3-a9b88e14c490-image.png]

@mcfly9 said in ipv6 compatible checkip service?: I traced the code further, then I found the problem: dyndnsCheckIP returns false if the gateway is marked as down. My gateways don't respond to pings, hence pfsense marked them as down. As soon as I disabled gateway monitoring, it all started working. @Gertjan, @WN1X, thanks for the help! Change your gateway monitoring to something further upstream that pfSense can ping. Problem solved!

@helviojr said in Can pfSense's DHCP server update Microsoft DNS?: I miss the custom DHCP options that would be very helpful. I could do it hard-coded in the config generation script, but I'm sure it will be available in GUI soon enough. Which DHCP option ? Read again the page where ISC announced they stopped the famous 'dhcp' project, and restarted form scratch, rebuilding the DHCP server again. On the non-official page you'll find the reason : over the years, options were added. thousands of them. Some were written, debugged, and stable since. Some were changing all the time. Hardware vendors didn't stop adding and modifying them .... It had became a software-maintenance hell. ( a bit like the openvpn project, or have a look at the absolute champion : postfix - or the black angel, freeradius : that one is just frighting). So, they created a framework and a manual, and left it up to 'us' the user (a very special user : it's us, the admin users, so we need to admin stuff ones in a while, and this includes type in stuff) to know what option data is needed, and place it in a nice JSON format (yet another text file format with a very precis syntax, probably more strict as XML), test it ... and forget it. Believe me : it isn't that hard .... A (pfSense) GUI facility for every option would be best, of course, but I don't think Netgate will fall in this rabbit hole. Writing a GUI (pfSense or not) that handles all the DHCP option ? (and does all the verification and checking of consistency etc ..) ... you might be waiting a long time. Right now, imho, the kea v4 and v6 pfSense implementation is rock solid. Some support for DNS registration, static leases and even HA is possible. The option I needed were - surprise - asked in pfSense redmine, and examples were proposed. From there on, as I sa working examples, I made some of my own. Anyway, I know, I'm rambling a bit. Just saying : you can do it ^^

Agree That bug really does make alias much less useful. Two example I currently use aliases for which will fail with this bug White list for remote access to work server from periheral sites. The laptops will roam between sites Peripheral site DDNS FQDN Peripheral site relatively static IPv4 addresses Laptop 1 DDNS FQDN Laptop 1 DDNS FQDN White list from a VoIP supplier with redundant servers in multiple cities. During fault conditions the supplier redirects traffic to better functioning servers in another city city1.Voipsuppler.com city2.Voipsuppler.com city3.Voipsuppler.com city4.Voipsuppler.com city5.Voipsuppler.com city6.Voipsuppler.com city7.Voipsuppler.com city8.Voipsuppler.com Imo The variable FQDN component of an alias should be completely recalculated from scratch then combined with the constant (explicitly specified) IPs each time. After which only changes from the current IP addressees written to filterdns to update the firewall filtering.

Wow... ok figured it out. The links provided in @Gertjan post put me on the right path. It seemed strange that only Ubuntu Server hosts were affected so I started digging on that. Turns out that by default in Ubuntu Server systemd-resolved is not configured to use the domains passed by DHCP (either v4 or v6) not by RDNSS. So all I had to do was to edit /etc/systemd/networks/networkd.conf to have UseDomain=true and just like that, by magic the hostname is properly registered in Unbound...

.... or zap the legacy 127.0.0.1 and embrase the future : ::1 ** ** some restrictions may apply.

Hi again, @Gertjan Quick update, looks like the following config will do what I want: 'loggers' => [ [ 'name' => 'kea-dhcp4', 'output_options' => [[ 'output' => 'syslog' ]], 'severity' => config_get_path('kea/loglevel', 'INFO') ], [ 'name' => 'kea-dhcp4.leases', 'output_options' => [[ 'output' => '/var/log/kea-dhcp4.log', 'maxsize' => 512000, 'maxver' => 7 ]], 'severity' => config_get_path('kea/loglevel', 'INFO') ] ], Thanks again for your help! :)

Looks like this works now with KEA in 25.07.1 .

@McMurphy No - I am still using it, not a fan of current logging in kea.. And isc still works, there are not any security issues that would warrant switching. They have just stopped development of it is all. I have no need for the dhcp registration, etc. So just no point to me to switch at this time and more than likely cause my self grief when isc currently works exactly how I like it, etc.

@Gertjan I finally decided to make a dedicated VM on Proxmox for it. Cleanest and best way for me.

@johnpoz Oh dear. My Outgoing Network Interfaces on the resolver did not include my WireGuard tunnel. Problem solved. So sorry to have wasted your time, I'm incredibly grateful for your help. It got me there in the end quite honestly, thank you. Oh and on this, "Dude if your going to use nslookup, set debug so you can see exactly what is happening", agreed, my bad!

Thank you @Gertjan for the reply. I will next try to solve the "Unbound python mode" for the next school break. Thank you @SteveITS for the reply. I was not sure about dns flushing and browser cache issues so what I did was to restart the client PC each time I tested a DoH setting change in the operating system, and pressing shift + [refresh] multiple times on the browser when I typed a URL. The client computer is using pfSense for DNS, DHCP, and internet connection. In case I misunderstood the question this is the services status on the pfSense dashboard: [image: 1762226646789-80c37773-52df-44ee-a0c9-b32a4dc8f59e-image.png] Thank you @Uglybrian for the suggestion. I have replaced my manual list with your auto-populated list.

@chpalmer said in BIND9 CVE and Pfsense BSD port: @WhizzWr said in BIND9 CVE and Pfsense BSD port: @chpalmer thanks I may try it. Can I switch back to stable channel once it it 25.11 is released? Yes I upgraded to the latest Beta, unfortunately it still uses bind9 9.02.13, so still vulnerable to the CVEs.

@mpossari Thanks for summarizing your finding. I risk necro-ing thread to help other people coming from Google search. The manual edit won't survive package update or reinstallation. I made a patch that can be applied to System -> Patches --- usr/local/pkg/bind.inc.original 2025-11-01 16:14:35.000000000 +0100 +++ usr/local/pkg/bind.inc 2025-11-01 16:14:35.000000000 +0100 @@ -465,7 +465,7 @@ $bind_conf .= "\n\t\t# look for dnssec keys here:\n"; $bind_conf .= "\t\tkey-directory \"/etc/namedb/keys\";\n\n"; $bind_conf .= "\t\t# publish and activate dnssec keys:\n"; - $bind_conf .= "\t\tauto-dnssec maintain;\n\n"; + $bind_conf .= "\t\tdnssec-policy default;\n\n"; $bind_conf .= "\t\t# use inline signing:\n"; $bind_conf .= "\t\tinline-signing yes;\n\n"; } Make sure you set Patch Strip Count to 0