@patient0 I tried disabling IPv6 and also the Prefer option and it doesn't change anything with dns resolving. IPv6 and IPv4 works with if_pppoe enabled. Unbound gives SERV_FAIL or Time out. Internal dns resolution in pfsense doesn't work either. When I disable if_pppoe everything works as usual.

@Gertjan Thank you for your assistance. I will continue to monitor the system status.

@JonH said in KEA in 25.07 NTP server?: But make a change (anywhere) in settings of KEA and it fails to save solely because of the FQDN in the NTP section. So isc allowed FQDN in ntp section KEA does not. That was a know ISC issue - actually a pfSense GUI ISC issue : like DNS server info, NTP info can't be a host or pool name. The GUI help text told : "enter an IP or host name". That host name part is false. NTP info can be IP only, not a host name (or worse, a pool name). This issue has been discussed here several times already. @johnpoz said in KEA in 25.07 NTP server?: Your windows is prefect example.. It doesn't ask, even if you send it - it makes no sense that the client would use something it didn't even ask for I know. Was presuming that would be common knowledge by now ^^ @johnpoz said in KEA in 25.07 NTP server?: handing it out is one thing - your client using it is another.. What client? Just sniff your dhcp is it even asked for - is it offered.

@tgl said in Hostname "@" breaks DDNS: @johnpoz said in Hostname "@" breaks DDNS: @ used use to denote the root or origin of the domain, ie you have example.com domain, and you want example.com to resolve to an IP without a host name. Exactly: in DNS entries it's a magic special symbol, not a valid literal host name. I think the OP misused it as a result of misreading whatever instructions he was looking at, but we don't have enough detail to be sure. As @johnpoz highlighted in his first reply to my post, the instructions for the hostname field in the Dynamic DNS Client edit page specifically instruct use of @ for Azure and a few other providers to indicate an empty hostname which means the domain root: "Enter the complete fully qualified domain name. Example: myhost.dyndns.org Azure, Cloudflare, Linode, LuaDNS, Porkbun: Name.com: Enter @ as the hostname to indicate an empty field." Also, as far as Azure is concerned, it's totally valid to specify @ in the Name field of an A record in a record set defined within a zone. If I can configure an A record with the name @ for a zone using the Azure portal, what's stopping me from using any other authorized Azure API to configure that record? The user interface for this first-class feature of pfSense has specific instructions for this exact situation for updating these records hosted in Azure.

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

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