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

I ran across https://redmine.pfsense.org/issues/14734 which sounds like a possible cause...the IP is incorrectly removed if an FQDN resolving to it changes IPs. Also per https://forum.netgate.com/topic/199152/unexpected-alias-behaviour-two-ranges/ aliases that contain IPs and an FQDN may fail to populate all the IPs.

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.

@Gertjan Thanks for pointing those out. I also posted on that thread there with some updates.

@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

@dacool I'm running into the same issue just recently with my install. I know it's been a few years but wondered if you ever found a resolution.

That solved it! Thank you!

@badjoodani said in If you PUT a NAME - FQDN instead of an IP address in for NTP servers KEA-DHCP will not start.: option data does not match option definition (space: dhcp4, code: 42): Failed to convert string to address '0.north-america.pool.ntp.org' This means that 'kea' isn't doing 'DNS' for you. It will not converting '0.north-america.pool.ntp.org' into one of these "15.204.87.223 23.143.196.199 158.51.99.19 83.147.242.172". Btw : ISC DHCP did't do that neither. Here : the doc : https://kea.readthedocs.io/en/kea-2.5.0/arm/dhcp4-srv.html and look for "ntp-server" on that page : [image: 1761636887490-f0be0c59-c19d-4840-bb47-9aae7a8b3f05-image.png] That's an IPv4-address, not a host name. Or a pool name. ISC DHCP : was the same. Maybe, in the past, the pfSense GUI converted a host name into an IP ? I can't recall. Same question, a couple of years ago : KEA DHCP NTP server option behavior.