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

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

@70tas Thanks! So different issue, same/similar symptom then.

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

@Gertjan oh I missed that - my bad.

@JonathanLee said in DNSSEC Resolver Test site: https://wander.science/projects/dns/dnssec-resolver-test/ The patato checker. Uncheck : [image: 1752650595740-77b420f9-5499-4301-8050-7c1f6a6560d3-image.png] and do the test again. So that page, and this one : http://www.dnssec-or-not.com/ test if you've checked the resolver's DNSSEC capability, or not ^^ That web site is part of my collection of web sites that test several DNS(SEC) related things. I 'admin' several web servers ( = domain names), I also use site use this one https://dnsviz.net/d/test-domaine.fr/dnssec/ to check out a domain name DNSSEC capabilities, as I need to be sure it works = me not messing up things when deploying it. test-domaine.fr is a domain I rent and use to test things before I apply them on the domains that can't afford down time when I mess up (again). Remember : if you set up DNSSEC wrong on your web server, mail server ( actually DNS domain name server ), your domain name will 'vanish' from the Internet. DNSSEC was considered rocket science not so long ago and maybe it still is, as using it really implies that you know what DNS is. The good thing about pfSense : when you install it, and don't change (add, remove) any pfSense DNS settings, it will use DNSSEC out of the box without the user (admin) even being aware of anything. DNSSEC = that's why resolving (yourself, locally) is such a good thing. Forwarding means : you have to trust some one else. Last time I checked, half of Europe's web site are using DNSSEC, and the US was ... not really using it. That changed a lot the last several years : DNSSEC is now somewhat mandatory for all government hosted sites world wide.

@jamesdun @jamesdun said in DNS problem: if the new machine wasn't picking up the correct DNS server Well, launch ipconfig /all and it tells you what DNS server it uses. Normally, a new Windows PC will use DHCP is so it's 'plug and play'. @jamesdun said in DNS problem: Both machines show the correct DNS server when NSLookup is launched, although the old one also gives it a name and the new one fails to do the reverse lookup Looks like the new machine isn't allowed to do DNS requests against pfSense ? @jamesdun said in DNS problem: and the new one fails to do the reverse lookup Humm. The new one's DNS request gets refused ...

@AWeidner its just pfsense trying to proect you against a rebind. When you foward to something that is normal some external public NS - which normally should not be returning rfc1918. You might want to read some of the history of rebind attacks. And why this good protection to have in place.

Hmm, yeah I'd expect it to only be resolving leases that were present before that change. Like if you add a new static dhcp lease on that interface I'd expect that to fail to resolve.

@Gertjan those 3 name server might be just his isp dns.. that first on is fibreop and the others are aliant - which are the same isp - with the fibre one being for their FTTH. Yeah if you want to use those - you should have unbound forward to them - but I see little benefit to forwarding for dns, just let unbound resolve is better option imho.