I have upgraded from 24.11 to 25.07 and the DDNS with cloudflare also stopped working for me.

@smsigroupit If you have pfSense DNS set to forward ensure DNSSEC is unchecked. Otherwise, is Unbound running? What do the logs show?

@Gertjan @KB8DOA FWIW, I see similar behaviour on 2.8.0. I have not tried rebooting yet (my family will kill me) but my client does not get the reserved IP address I have set for it in Kea. It gets everything else. The entry in "/usr/local/etc/kea/kea-dhcp4.conf" (correctly) shows: { "hw-address": "be:a7:d5:41:83:0b", "ip-address": "192.168.99.96", "hostname": "newclient", "option-data": [ { "name": "domain-name", "data": "localdomain" }, { "name": "domain-search", "data": "localdomain" }, { "name": "domain-name-servers", "data": "1.0.0.1, 9.9.9.9" } ] }, I packet-captured the DHCP, and it appears to be doing all the right things except handing out the wrong IP: 21:21:26.759427 be:a7:d5:41:83:0b > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from be:a7:d5:41:83:0b, length 548, xid 0x4854577, Flags [none] (0x0000) Client-Ethernet-Address be:a7:d5:41:83:0b <---- This IS the correct MAC for the client. Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Request Requested-IP (50), length 4: 192.168.99.100 <----WRONG IP - this is the first IP in the DHCP range. MSZ (57), length 2: 576 Parameter-Request (55), length 8: Subnet-Mask (1), Default-Gateway (3), MTU (26), Unknown (252) NTP (42), Domain-Name (15), Domain-Name-Server (6), Hostname (12) Client-ID (61), length 7: ether be:a7:d5:41:83:0b <---- Again, the correct MAC for the client. Hostname (12), length 3: "newclient" <---- Correct DNS name for the client, as defined in the DHCP server entry. 21:21:26.767520 00:0e:c4:d2:06:1f > be:a7:d5:41:83:0b, ethertype IPv4 (0x0800), length 338: (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 324) 192.168.99.1.67 > 192.168.99.100.68: [udp sum ok] BOOTP/DHCP, Reply, length 296, xid 0x4854577, Flags [none] (0x0000) Your-IP 192.168.99.100 <---- WRONG IP Client-Ethernet-Address be:a7:d5:41:83:0b Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: ACK Subnet-Mask (1), length 4: 255.255.255.0 Default-Gateway (3), length 4: 192.168.99.1 Domain-Name-Server (6), length 8: 1.0.0.1,9.9.9.9 <--- This IS correct, and SPECIFIC for this client, so I know 'part' of Kea is working/responding correctly Hostname (12), length 3: "newclient" <--- This IS correct, and SPECIFIC for this client Domain-Name (15), length 11: "localdomain" <--- This IS correct, and SPECIFIC for this client Lease-Time (51), length 4: 86400 Server-ID (54), length 4: 192.168.99.1 The "dhcp.log" also shows the wrong IP: Aug 8 21:42:32 fw kea2unbound[940]: Record installed: "100.99.168.192.in-addr.arpa. 28800 IN PTR newclient.localdomain." Aug 8 21:42:32 fw kea2unbound[940]: Record installed: "newclient.localdomain. 28800 IN A 192.168.99.100" Aug 8 21:42:32 fw kea2unbound[940]: Include updated: /var/unbound/leases/leases4.conf (3575f494a69dc0df) Aug 8 21:42:32 fw kea2unbound[940]: Syncronization completed: 113.7891ms Ignore that the times in the 2 logs are slightly different - I tried multiple times - the logs were the same. ¯\_(ツ)_/¯ The same client used to work fine with ISC every time, for years. edit Reverted back to ISC, rebooted the client. BAM. Correct IP. Kea is definitely buggy.

@Gertjan Thanks very much, I edited the DNS resolver settings accordingly and enabled the Python mode.

@slu said in Filterdns has stopped resolving hostnames in firewall aliases: aybe its relevant how ACME is configured. Nice catch ! This : [image: 1754480078430-7f044d98-4fe3-4b61-9697-d44d3c9bd573-image.png] implies that when you set DNS Sleep to '0', it's the script itself that starts polling every 'x' seconds the domain name servers. If its using one of the Doh etc, (which you've blocked with pfBlockerng) then yeah, that fails ... Set DNS Sleep to "200" or so and solved ^^

@johnpoz Thanks John, looking forward to your findings.

@tinfoilmatt Unbound works properly with DOT in n forwaring mode Bind9 pfsense implementation no Bind9 with pkg install works What unbound is missing is forwarders by zone. Actually it is only global. When you override dns in dhcp, you cannot forward 53 to dot in unbound. You have to block it in fw rules and enforce a dot rule to the given server. But you could loose tls auth too as dhcp overrides do not provide domain name. It'll need to be set in client Basically, bind has the advantage of forwarding by zone and much more

@chrcoluk SWEEEEEEEEEEEEEEEEET. Thank you so much for your help!!!! I guess I dont need to do the bind method then! Thank goodness!!

@lohphat Not sure what you’re looking for…? Here’s a thread discussing the announcement, two years ago. Can’t find a blog post in a quick search but I recall the email. https://forum.netgate.com/topic/183472/3100-will-reach-end-of-life-in-5-days @JimNH Ensure you have DHCP lease registration off, or unbound will restart at each renewal. Or maybe grant long leases.

@scotrod said in Dynamic DHCP lease not visible outside of ARP table: That's how we started. At this point I have no way of showing dynamic leases anywhere but the ARP table and I expect to see that under DHCP leases. Also, assigning a static lease on a particular MAC address won't work (I've tried that several times) until i check the Create an ARP Table Static Entry for this MAC & IP Address pair. checkbox. I don't know if that's by design, but if it is, it's just a dumb design. Not needed because not related - and sure enough not by design. I never look at the ARP page ... Also : look at my ARP table : [image: 1753864634193-ee416d17-5007-48b3-9b60-a2bd51ba2818-image.png] ARP requests are cached (on pfSense) and stay valid for (default) 1200 seconds = 20 minutes. The ARP relation IP <=> MAC has nothing to do with the fact that the IP was obtained originally by a static IP assignment, or or DHCP request (static MAC or dynamic). See here for a nice example. Not a solution, but this would help you : Nearly all my LAN devices have a static MAC DHCP setup, so my NAS, printers, airco, all the networked LAN PCs and other stuff I need to access to control have a 'fixed' but DHCP assigned IP = static MAC DHCP. You could do the same for your setup if the network isn't very big. As you don't change all your equipment very often, this is a one time job. I don't care, for my network, if I I don't see the IPv4 of a device that is merely visiting for a while, and then vanished, like the phone IP of a friend that uses my network. I'm not going to connect to his IP anyway, neither sharing info with it etc. According to this blog post, kea DHCP worked since Plus 23.09. This means that classic dynamic leases woild be served, and shwon on the leases page. Back then, as shown in the "restrictions" list, static MAC leases weren't even supported yet. That changed with 24.11 - and yiou' shwon that that part works. So : imho, your issue isn't "kea" (as we both use it - and it works for me). There must be some setting somewhere that explains this all ....

@phil80 oh I see nvm then

@Lars_ said in How to update No-IP IPv6 (dynupdate.no-ip.com does not have an AAAA record): @SteveITS Determined testing pays off. It works now Same for dynupdate.no-ip.com/nic/update?hostname=thisismydomain.ddns.net&myip=%IP% with option "HTTP API DNS Options = Force IPv4 DNS Resolution" enabled. I was actually quite close. The solution is to update the AAAA record using IPv4: Service Type: Custom (v6) HTTP API DNS Options = Force IPv4 DNS Resolution Update URL: dynupdate.no-ip.com/nic/update?hostname=thisismydomain.ddns.net&myipv6=%IP% Note: It has to be &myipv6=, not &myip= Is this something that makes sense to be implemented in No-IP (v6) and No-IP (free-v6)? It would not work if IPv4 DNS resolution isn't available, but I guess that is not very common in the wild. Haven't found a way to tag this thread as SOLVED. This solution worked for me!

@tman222 said in Upgrading Unbound version for latest pfSense Plus release?: (I didn't see it listed in the 25.07 release notes when I looked earlier). A couple of days (weeks ?) one of the latest pfSense Plus Beta or RC already included 1.23. That's the version I use right now. Since February 2025, 1.22.x was used, that's according my own release notes (I always log the upgrade process, executed form console, option 13, to a file. I don't use the GUI upgrader as that one tend to hide the obfuscate the interesting stuff.) If the newest unbound version, 1.23.1, concerns the 'pfSense' version of unbound, then 1.23.1 will probably be included soon. edit : @w0w => We can actually check : [25.07-RC][root@pfSense.bhf.tld]/root: unbound -V Version 1.23.0 Configure line: --with-libexpat=/usr/local --with-libnghttp2 --with-ssl=/usr --enable-dnscrypt --disable-dnstap --with-dynlibmodule --enable-ecdsa --enable-event-api --enable-gost --with-libevent --with-pythonmodule=yes --with-pyunbound=yes ac_cv_path_SWIG=/usr/local/bin/swig LDFLAGS=-L/usr/local/lib --disable-subnet --disable-tfo-client --disable-tfo-server --with-pthreads --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/share/man --infodir=/usr/local/share/info/ --build=amd64-portbld-freebsd15.0 Linked libs: libevent 2.1.12-stable (it uses kqueue), OpenSSL 3.0.16 11 Feb 2025 Linked modules: dns64 python dynlib respip validator iterator DNSCrypt feature available BSD licensed, see LICENSE in source package for details. Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues so the CVE deosn't apply.

@tinfoilmatt said in Netgate Documentation on DNS over TLS and NOT using DNSSEC: I've never encountered any problems And what have you gained by asking for something that has already been done.. You mention you leave 0x20 off for performance - but want to do a bunch of queries for dnssec that make no matter?

@MacUsers said in Kea DHCP stops working: all of pfSense are v24.11-RELEASE (amd64); as far as I can see now, KEA actually never worked for me since I migrated from ISC, regardless of the pfSense version. There is a 99,99 % solution avaible now. Right now, this one : [image: 1752841729712-05190dbc-0f5c-445e-ba66-8104c93aae78-image.png] is available. An RC version is identical to the final Release. It stays RC so very minor issues let GUI text can get corrected. Major changes, like 'kea not working' won't be corrected anymore. I'm pretty sure (tens of thousands) use "25.07"(RC) right now, and they 'all' use kea. No issues afaik. So .... even if 25.07 won't solve your issue, you'll be sure for 99,99 % that the issue is ... on your side. Or, you are using pfSense (hea DHCP) in a very special way, and no one else is using it that way so we can't know what your issue is ? Do you have any details about why your 'pfSense' (DHCP kea settings) are so different that it 'break's ? Do use an edge case scenario where things were possible with ISC DHCP, but not anymore with kea ? Btw : we all have iMac, IPads iPhone and other iStuff in our networks, they all behave fine with kea, using classic DHCP leases, or static MAC leases.