@johnpoz said in Why not a CNAME?: But I am not aware of anyway to dynamically change what fqdn a cname record points to other than via a API into the dns.. Or maybe you could script something with unbound-control. Agreed.

@WN1X I'm on community. 2.8.0-RELEASE It was released in May.

Hello, Has anyone else encountered similar problems?

@Gertjan That works perfectly thank you so much! Enabling DNS Query Forwarding seems to be the correct setting for us. I think what was throwing us off was the wording "or those obtained by dynamic interfaces such as DHCP". Obviously we can't have that. However the qualification "if DNS server override is enabled there", which it is not, so that just didn't apply. [image: 1758142364307-045a144c-7f19-4446-bea3-d346a86e5919-image.png] Now if I have a DNS address specified it works, and if that server is unreachable for any reason it doesn't. That is what I want. Again thank you so much. I can now move on to step 2 +++ ;) We will take further steps to deal with DoT and DoH as you and others have mentioned.

@Luca-De-Andreis said in After restart, Unbound DNS Resolver don't work: @Unoptanio Yes, its true. Setting ALL:ALL the DNS works correctly from system restart without manually restart daemon (after reboot) ! I've just tried now. Wow, just tried this too and after years of dealing with it - it's fixed. Thank you!

Hopefully this isn't an ongoing bug because it's pretty crippling.

@Gertjan said in Crash report: @pf_ltu said in Crash report: kea2unbound If you are using pfBlockerng, then here is the solution. SOLVED thank you @Gertjan

@Gertjan Thank you, I look through the last 500 entries in the log and there was nothing but repeat entries, nothing about starting and stopping the dhcp server, only the one you see where I started it again. Thank you for pointing out thisight be an old bug, I will update as soon as I can.

@justme2 Get your SFTP browser, open /usr/local/www/services_dhcp_relay.php Or use the console or SSH, and edit /usr/local/www/services_dhcp_relay.php Locate : if ($dhcpd_enabled) { print_info_box(gettext('DHCP Relay cannot be enabled while DHCP Server is enabled on any interface.'), 'danger', false); } Chance for : if ($dhcpd_enabled) { print_info_box(gettext('DHCP Relay cannot be enabled while DHCP Server is enabled on any interface. !! OVERRIDDEN !!'), 'danger', false); $dhcpd_enabled = false; } Note : the "!! OVERRIDEN !!" is my personal choice, and not needed. Save. Now, for example : I disabled the DHCP server (kea) for this interface : [image: 1757669144546-1208eea8-273b-4632-aa28-447a19ca7d92-image.png] Save and Apply. Back to DHCP relay, select IDRAC - add a DHCP Relay server : [image: 1757669183530-4a1df8ab-bc3b-41ce-9da3-edd2d04bfacc-image.png] and Save. Check : [25.07.1-RELEASE][root@pfSense.bhf.tld]/root: ps aux | grep 'dhc' root 26880 10.2 0.6 43768 23968 - S 11:18 0:00.10 /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf root 27281 9.9 0.6 43728 23532 - S 11:18 0:00.09 /usr/local/sbin/kea-dhcp6 -c /usr/local/etc/kea/kea-dhcp6.conf root 24435 0.0 0.1 14404 2980 - Is 20Aug25 0:00.02 dhclient: system.syslog (dhclient) root 41257 0.0 0.1 14404 3100 - Is 20Aug25 0:00.05 dhclient: ix3 [priv] (dhclient) root 51257 0.0 0.1 14308 3460 - SCs 20Aug25 0:39.41 /usr/sbin/syslogd -O rfc5424 -s -c -c -l /var/dhcpd/var/run/log -P /var/run/syslog.pid -f /etc/syslog.conf -b 192.168.1.1 _dhcp 51487 0.0 0.1 14408 3268 - SCs 20Aug25 0:05.22 dhclient: ix3 (dhclient) root 52757 0.0 0.1 14128 2900 - Is 20Aug25 0:06.00 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c.conf -p /var/run/dhcp6c.pid ix3 root 56422 0.0 0.1 16812 4776 - Is 11:10 0:00.00 /usr/local/sbin/dhcrelay -id igc2 -iu ix3 192.168.10.1 The kea DHCPv4 is still running. If all goes well, it doesn't touch/use the igc2 - my "IDRAC" - interface. As you can see, dhcrelay is running also - using 'igc2' - my IDRAC interface. You'll notice that on the DHCPv4 (kea, as that's what I'm using) there are also red messages showing. [image: 1757668428078-c8d71175-a0b8-4fd6-b081-18138c5027b5-image.png] Also for the LAN, and other interfaces. I guess you know now how to make these GUI pages more "smart", and don't show messages if they are not needed. On the DHCP Relay GUI page you could even modify the list with shown network, by excluding the networks that have the DHCPv4 active on them. In my case : this list should only shown "IDRAC" instead of : [image: 1757669589057-fe81bc41-f103-4a54-be83-890688b52a39-image.png] Btw : I did not test this dhcrelay service. I don't have a network where this is needed / don't know how to use it. Also : I presume you cant' save DHCOPv4 ((kea) settings and network pages anymore, as on this pages the test 'is dhcp relay' running also exist (Generaol settings page : just the test, on the interface(s) page - the same PHP file is used for all interfaces the test also exist, and name some love). I'll leave it up to you a make something nice, safe and fool proof out of it. Like : If you select an interface, like my IDRAC, that has a dhcp relay activated on it, show the red message and don't allow the user to Enable it with an active DHCP server. This is now already the case. Make the code a bit smarter by testing the (this) interface is used by dhcp relay, and only allow the DHCP server (kea) to be activated on that interface if it is not used by dhcp relay. See /usr/local/www/services_dhcp.php- here : [image: 1757669965048-4812bf5d-0bca-4afb-a4f0-8e0173cd984f-image.png] how to make these decisions.

@Gertjan I did/do what you've described - and I only use IPv4 so don't even have to worry about DUIDs - and it doesn't work. It's rock solid at being buggy/broken, yes. If it were only me....sure, that could be my issue, but I'm not alone here with seeing the same problem. See my linked post - I showed you that the Kea DHCP process is doing the wrong thing via packet capture. There's no discernable reason why it's doing the wrong thing, it just does. Switch back to ISC and instantly all problems resolved. If you can tell me how I can figure out how/why it's broken, I'm listening.

@Luca-De-Andreis Hello, i have the same problem look here: https://forum.netgate.com/topic/198723/after-restart-unbound-dns-resolver-don-t-work/3?_=1757403706907

@patient0 Still the same issue with if_pppoe.

@terryzb said in Printer losing its DHCP lease in 25.07.1: printer because with DHCP it would fail back to link-local after 6 hours or so So around 3 hours from the initial printer power up == initial 'BOOT' DHCP request, start some time before, like 30 minutes or so, like at initial lease+150 minutes, you should be able to packet capture with the printer MAC to see if pfSense actually receives a DHCP request from the printer.

@Jeremy11one said in Confused about DNS forwarding and local domains: Here's a 2018 Microsoft page I found with contrary advice: link. I'm interested in your opinion to see if there's something that article hasn't taken into consideration. While generally @johnpoz does have a point on the issues with leaky DNS when using public domains internally, it should be noted it only happens if mistakes are made in internal DNS setup (like fx. Transparent vs. Static, and searchdomains and such). There are a lot of arguments for using a public internal domain when it comes to user transparency/understanding and just generally making lives easier because of “easy use” of short hostnames instead of FQDN. Also, I highly disagree with the argument that a private domain internally makes things easier - it does not in the majority of management cases with large userbases. It will create a lot of double maintenance in DNS, proxies and firewall setups (reflection) if your userbase generally are using webbased tools in their interaction with company ressources that are a mix of internally and externally hosted servers. Much easier to maintain with a public internal domain, and no need for NAT reflection which is a PITA. So both solutions works and each have their advantages. It’s safe to assume MS made that recommendation from years of support and understanding what problems was caused by each model. Yes, a private domain is the “correct” technical solution, but ease of use and maintenance has a tendency to win ;-) It should be noted as we increasingly move towards SAAS in cloudservices, the public internal domain advantage in maintenance does “diminish” as those require you to make double maintenance in DNS if they are named in the public domain.

Ooo, missed this. You are just adding that section to the custom Kea json config? Edit: Yup

@Gertjan off track, but i am trying to integrate home connect into home assistant which is a vm inside of truenas. linking the cloud account doesn't like. i was using the wan access only to check that i got duckdns and letscrypt sorted. now i am trying to figure out how i get haos working. i guess i can revert back to my pfsense certifcate once haos is running

@Woodsomeister said in Use and persist dhclient rapid commit option: Adding the option is not what I need You are again right, you would need dhclient to respond appropriated according to the RFC4039. Checking the source code, dhcpcd 10.2.0 can handle it (no configuration needed) and it's compiled in in pfSense. Would be interesting to see if you get an IP when manually running it. Not very practical though. Even less sure if you could script it by setting WAN IPv4 to None or Static as a placeholder and run whatever necessary yourself. Or set it to DHCP and use a dhclient hook to run dhcpcd. Maybe Sir @stephenw10 has done something similar in the past? Maybe a feature request to Netgate would help: to be able to choose which DHCP client app to use, dhclient or dhcpcd. For IPv6 dhcpcd is already used. Btw: ISC DHCP and ISC KEA don't support rapid-commit but dnsmasq does. Gave a it go and dhcpcd would work, running manually dhcpcd -4B <WAN interface> --option=rapid_commit on the pfSense (client) and tcpdump on the dnsmasq server shows DHCPDISOVER & DHCPACK. Running the standard dhcpcd -4B <WAN interface> --nooption=rapid_commit shows the standard 4 packages sequence.

@SteveITS This has been an issue for me for YEARS. But it only crops up every so often (like today). It's long enough apart that I forget about the filterdns issue and waste several hours looking at the wrong things. Maybe I just need to set up a cron job to kill and restart filterdns every hour? Would that work? Break something else?

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