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

@phil80 I opened a redmine issue as it is clearly a pfsense package bug https://redmine.pfsense.org/issues/16345 pkg install bind920 in pfsense works

@chrcoluk Thank you very much for detailed response. The way I have it setup right now is: #1 Active directory interfaces have a firewall rule that allows dns on the subnet to windows domain controller (I found this worked the best for active directory connectivity) #2 Domain controller DNS manager is set to forward to pfsense for DNS queries it cannot handle (anything that's not local AD DNS) #3 Pfsense then filters DNS queries via pfblockerng DNSBL lists #4 Lastly, DNS over TLS is used by pfsense to Quad9 (Using dns resolver outgoing network interface as two of my wireguard gateway tunnels) Unfortunately, I think if I hand out VPN DNS via DHCP like you said (which I think I used to do) - some or all of above cannot be used. Pfblockerng has DoH blocklist enabled already. I also have Skip rules when gateway is down checked but didn't have a reject rule afterwards. I've added that now. Just to clarify, i'm not having any DNS leaks the way my stuff is setup currently. But my issue was: in DNS resolver settings, when I set outgoing network interface to WAN it's the only way i can get domain names instead of IPs to work in the wireguard peer endpoint fields. But then this causes some DNS leaks but could be acceptable to some users. If I don't set DNS resolver outgoing network interface to WAN (and instead use my wireguard gateway tunnel), I can't set my VPN's domain name as the wireguard peer endpoint (I think it only doesn't work for the interfaces I select for the DNS resolver's outgoing network interfaces - or at least one of them). Only IP address will work. But as Bob said, maybe it just doesn't work and I can either just use IP address for WG's endpoint or live with a DNS leak by selecting WAN as outgoing network interface in DNS resolver settings. Or if it was a bug I could try reporting it. Sorry if I have your info confused, i'm not super technical.

@70tas so to confirm, your gateway is not reporting offline?

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

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