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

I’m sorry didn’t fully explain - config file exported to exact same dell server with same intel nics and exact same Cisco 3500 switch and unfi ap both instances are identical My only problem that needs a solution is how do force the use of either my vpn dns servers or ones I chose on things connected to my vpn client as the way it runs now is that dns leak testing displays my isp address which is fixed (at least in uk can’t tell if Comcast is fixed) I can use dedicated dns on browsers and also on devices buts not very satisfactory. Unfortunately I’m not anyway a networking expert just having to find my way around stuff - thou when I built it years ago it did exactly what I needed but something changed either with Pfsense or Nordvpn service (been there to find solutions but no help) anyways thanks for the help!

@madbrain said in Purpose of pools: Is it only to allow for non-contiguous IP address ranges for dynamic leases ? Not only no but that could well be one option for a much larger subnet (although that does seem rather haphazard). It's perhaps more commonly used to further segregate a predefined subnet to allow/disallow certain devices to use predetermined portions of the pool.

@Ghost-0 said in UniFi access points successfully adopt under ISC DHCP but won't adopt when KEA DHCP is enabled.: I will read and try it I've edited my post above. A second, JSON text structure is also needed. It has to be 'defined' first : [image: 1751956054068-3bf5cd46-1026-4266-8b1b-78c21fcf8392-image.png] { "option-def": [ { "name": "unifi", "code": 1, "space": "vendor-encapsulated-options-space", "type": "string" } ] } on the main [image: 1751956082840-ea85cce3-d17b-430c-a2b5-e6573550e6dd-image.png] page. Then, as said earlier, on every interface where you need the DHCP option 43, you have to put : { "option-data": [ { "name": "vendor-encapsulated-options" }, { "name": "unifi", "space": "vendor-encapsulated-options-space", "csv-format": false, "data": "C0A80109" } ] } where "C0A80109" is hex for 192 168 1 9 => 192.168.1.9 if your controller uses 192.168.1.9 (an IP on my LAN network). So you probably have to adapt that hex string. The rest can be copied and places as-is. That's in newbie range ^^

@mgaudette Did you made it working? We having same issue with redirect zones.