@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

@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.

@johnpoz It's working fine now, which makes me think it's some kind of caching issue. I find it weird that Chrome could connect to palantir-02 yesterday, immediately, and the command line tools could not. I use iTerm2, which is a 3rd party terminal program that, so far, as exceeded the functionality of Apple's Term program, but I can't help but thinking that there might be some DNS caching being done somewhere that impacts the term programs and that Chrome doesn't deal with. I have several learning disabilities and it's an attention span thing. It takes me longer to dig into something than it does for most people. There's a line and when I cross it, and dive deep into something, I can get a clear understanding of everything in it, but six months later, if I haven't kept working with that material, I can forget it all - unless I do another deep dive. So I've dealt with this kind of stuff before, but long enough ago, that I've forgotten all that's involved. I probably should have looked up the command to clear the Mac's networking cache, but didn't think of it yesterday, when it would have helped. I did consider just rebooting, but didn't have the time while I was at the computer. (I figured that'd clear any DNS caching it may have done.) I have been able to resolve anything with ping in the past - never an issue. I'm in a rural setting, so there are times I lose internet. I have a simple alias: alias icheck='ping -c 5 8.8.8.8;echo;ping -c 5 www.google.com;echo;echo' or something close to that, you get the idea. When I seem to be having connectivity issues, I always run that to see if our internet is down. I did run it just as a quick check (yesterday, when the issue was happening) and it did work.

@IanMcLeish said in Host overrides in DNS Resolver: Perhaps they are now not required No need to be unsure. Fact check. Question : what are the host names the my pfSense can resolve for me (knows about) ? : Answer : [image: 1761200903195-8fd4565d-732f-4eab-b7d8-79863fd657e9-image.png] and hit Execute.

Any thoughts on this?

So it lasted longer without issue but out of the blue it stopped responding again. Unluckily I couldn’t debug when happened so I don’t have further info to share. I will try again to make it happen and see what I get from the logs

@martinez said in DNS resolver failed to resolve some addresses: server that is authoritative for the org tld It is indeed one of the ORG authoritative servers: dig -x 199.19.57.1 ... ;; QUESTION SECTION: ;1.57.19.199.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.57.19.199.in-addr.arpa. 3274 IN PTR d0.org.afilias-nst.org. ... $ dig +trace wikipedia.org @1.1.1.1 ... ;; Received 525 bytes from 1.1.1.1#53(1.1.1.1) in 5 ms org. 172800 IN NS a0.org.afilias-nst.info. org. 172800 IN NS a2.org.afilias-nst.info. org. 172800 IN NS b0.org.afilias-nst.org. org. 172800 IN NS b2.org.afilias-nst.org. org. 172800 IN NS c0.org.afilias-nst.info. org. 172800 IN NS d0.org.afilias-nst.org. org. 86400 IN DS 26974 8 2 ... ;; Received 779 bytes from 2001:500:a8::e#53(e.root-servers.net) in 4 ms wikipedia.org. 3600 IN NS ns1.wikimedia.org. wikipedia.org. 3600 IN NS ns2.wikimedia.org. wikipedia.org. 3600 IN NS ns0.wikimedia.org. ... ;; Received 655 bytes from 199.19.53.1#53(c0.org.afilias-nst.info) in 21 ms wikipedia.org. 180 IN A 185.15.58.224 ;; Received 58 bytes from 198.35.27.27#53(ns2.wikimedia.org) in 15 ms

@cmcdonald FWIW as of pfsense 2.8.1 this still seems to be happening. I had everything running fine for years with ISC and today opted to get rid of the KEA nag and it all just fell apart. Most of my Ring devices just get this: Oct 17 22:58:17 kea-dhcp4 20227 WARN [kea-dhcp4.alloc-engine.0x3ec6f4a16600] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1 90:48:6c:2d:4d:44], cid=[no info], tid=0x25b805e: Failed to allocate an IPv4 address for client with classes: ALL, pool_lan_0, UNKNOWN Oct 17 22:58:17 kea-dhcp4 20227 WARN [kea-dhcp4.alloc-engine.0x3ec6f4a16600] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 90:48:6c:2d:4d:44], cid=[no info], tid=0x25b805e: failed to allocate an IPv4 address after 41 attempt(s) Oct 17 22:58:17 kea-dhcp4 20227 WARN [kea-dhcp4.alloc-engine.0x3ec6f4a16600] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1 90:48:6c:2d:4d:44], cid=[no info], tid=0x25b805e: failed to allocate an IPv4 lease in the subnet 10.3.2.0/24, subnet-id 1, shared network (none) Going to switch back to ISC for a bit and see if anything changes. Config looks legit to me and I can't imagine a subset of Ring cameras (all the same make/model) would have a bug - it's a pretty common vendor really.

@xana I am having the same exact issue. It will just suddenly stop working, the service is running but failing to respond. I have disabled DNSSEC and do not have ntop installed. The only way to restore service is to restart the unbound service. I am using encrypted DNS but that is the only difference from standard setup, I followed the pfsense docs closely when setting it up. Was not a problem until this version, but there are things in this version I need elsewhere so I cannot go back.