@NETLOGIC Pick any - read - apply - done

@Gertjan I think you misunderstood, the lease works fine, the machine gets the proper IP, it just that it doesn't register the IPv6 to the DNS Resolver.

@kingrazor said in DNS config tips with pfsense behind ISP router: We're using Comcast as our ISP and I have for many years had issues with their DNS servers, so I never use them if I can help it. So the only sure thing is that I don't want anything on the network using Comcast's DNS servers. One more reason why the pfSense default DNS setup would be perfect for you. No ISP (Comcast) DNS is used by default. That said, I do presume that Comcast allows you to use the internet, and thus the Internet's 'default' DNS traffic. If they start blocking ordinary DNS traffic then an ISP change would be the your best solution. That said, if they really would do that, they won't stay in business long time ...

@webdawg said in KEA DHCP missing "Register DHCP leases in DNS Resolver...": Is 2.8.0 community working with KEA and DNS Resolver? Yes, I am on 2.8.0, and KEA now works well with DNS resolver. The DNS server now resolves client.mydomain.xx for leases received via KEA DHCP server.

@marcg Thanks I have switched to ISC, will remain there till they figure out the issues with KEA

I figured this out. Our tailscale config included a floating firewall rule that blocked tcp/443 on the sync interface. I removed the rule and everything syncs now.

@Gertjan thank you!

it seems same issue of: https://forum.netgate.com/topic/197667/update-2-7-2-to-2-8-0-dynamic-dns-not-working-with-cloudflare/17 which I found later on

@viragomann Thanks. I knew it was a default IP address -- that's the first time I've ever seen a name put to it though. I'll double-check when I get home tonight. But I thought I did have it in the trunk.

@0x44 Router interfaces don't typically 'change' (i.e., unplug/replug, link up/down) that regularly. In order to have Wi-Fi even, you'd need to somehow get an AP on at least the same management broadcast domain as the LAN interface without directly connecting it... because how else would you expect to be able to connect to and manage it? Directly connecting a network host like a PC or a server to a router interface is a somewhat unsual setup. @SteveITS's advice to connect a switch to the LAN interface—and then properly test connectivity of any/all devices that will connect to the switch, plus assess overall network stability with that topology—is the right advice.

watching

Hi, after some testing, it seams that is now working with the "TFTP Server" Option under "Other DHCP Options". But just with the new Release 25.07 with Release 24.11 its not working. You just need the enter the 3CX Provisionen URL in the Field, without any special Character like ' or ''

@SteveITS Thanks; I believe I found the root cause... the mmc in my 4200 was dying and is now dead, replaced by a nvme..

@Gertjan o/ Hey, sorry for the lack of replies, I was on a vacation. Upgrading to 25.07 seems to have fixed the issue. After upgrade, I can see the dynamically assigned DHCP leases under the "Leases" menu: [image: 1755260165183-590d93cd-a189-42d8-be3c-953b70eb0395-image.png] I guess this is solved now.

@Gertjan I suspect that can be a change in the MV configurarion on proxmox. It's weird, I mean, i change a parameter on mv configuration (Static ram vs balloning) but changes in proxmox needs shutdown and start again, are not applied until shutdown. For now i'm testing and checking every 2-3 hours and now it's everything ok.

@tgvoelker Sounds similar to my thread: https://forum.netgate.com/topic/196927/filterdns-has-stopped-resolving-hostnames-in-firewall-aliases

@patient0 Got it. Thanks for the help

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