@ajperson1927
Are your locations not separated clearly in the public DNS?

Just to start, I'm trying to get firstlocation.example.com working within the first location. I have created a domain override in the DNS resolver.

A domain override means, that DNS request for firstlocation.example.com are forwarded to the stated IP address.
You will need to create host overrides for this.

@Terho said in Kea DHCP4 lease file cleanup failed and crashed pfSense:

Two last system log messages just before network was lost:

These are ordinary 'INFO' messages signaling that it was about to clean its less file.
Nothing special, happens all the time.

@Terho said in Kea DHCP4 lease file cleanup failed and crashed pfSense:

DHCP renewal time was 600 secs

Are you sure about that 600 seconds ? 😲
This means renewal happens after 300 seconds.
Why so low ? 7200 seconds or more, ok. 600 is waaaaay to low.

Btw : have a look at the var/lib/kea/ folder, check (read, look at them, the files) where the leases files are stored.
Nothing special ?

Mine are a couple of Kb in size :

[25.03-BETA][root@pfSense.bhf.tld]/var/lib/kea: ls -al total 31 drwxr-xr-x 2 root wheel 6 May 19 11:29 . drwxr-xr-x 4 root wheel 4 Nov 19 2023 .. -rw-r--r-- 1 root wheel 17078 May 19 12:22 dhcp4.leases -rw-r--r-- 1 root wheel 5422 May 19 11:29 dhcp4.leases.2 -rw-r--r-- 1 root wheel 169244 May 19 12:22 dhcp6.leases -rw-r--r-- 1 root wheel 4635 May 19 11:29 dhcp6.leases.2

@jhg

pfSense CE on ...

What version ?
When the issue happens, was unbound listening on IPv6 LAN interfaces ?

[25.03-BETA][root@pfSense.bhf.tld]/root: sockstat -6 | grep ":53"
unbound unbound 53479 3 udp6 *:53 :
unbound unbound 53479 4 tcp6 *:53 :

means "all exiting interfaces", for TCP and UDP.

When you raise the resolver (unbound) log setting to 'very verbose', can you see the IPv6 request arriving @unbound ?
Don't forget to set the log setting back, as it produces a lot of info.

I had the same issue, several of my device went poof with their static IP and when I see the DHCP logs this what shows me.

WARN [kea-dhcp4.alloc-engine.0x3088dc017b00] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 xx:xx:xx:xx:xx:xx], cid=[ff:3e:43:3a:49:00:02:00:00:ab:11:35:39:77:96:62:6d:b5:73], tid=0x98a5560c: conflicting reservation for address 172.16.0.4 with existing lease Address: 172.16.0.4 Valid life: 7200 Cltt: 1747537583 Hardware addr: xx:xx:xx:xx:xx:xx Client id: ff:3e:43:3a:49:00:02:00:00:ab:11:37:60:a1:7d:6d:07:47:d8 Subnet ID: 1 Pool ID: 0 State: default Relay ID: (none) Remote ID: (none)

Yeah that assigned it a different IP address for a reason that it had conflicting IP address. went back the ISC because of this.

I hope the upcoming 2.8 have a fix for this.

@ericwentz and the dhcp lease time has zero to do with a dns ttl on a record.. The default is 7200 seconds, or 2 hours.

Which per the rfc Gertjan pointed out the registration of that in dns should be like 1/3 of the lease and not shorter than 10 minutes..

My issue is what you showed in the log of kea was it was writing a record with a ttl of 5 minutes - which to be honest on a local network is insanely low.. Make zero sense to me and clearly not following the rfc.

I'd backup the config.xml, edit it in Notepad++, and "Find/Replace All" the old prefix with the new. Save and import it when the time comes. But that's me, just an idiot on the Interwebs who doesn't even use v6.

@SteveITS I did restart but I have been adding a lot reservations so I I noticed it intermittently and just decided to give up and move away from Kea

I was able to find and delete the entry by searching the XML file and it was in virtual IPs.

@Gertjan Unbound's been running since May 1 on this router. Not using DHCP registration, or even DHCP on this router.

unbound 19499 0.0 2.3 124144 92208 - Ss 1May25 14:45.04 /usr/local/sbin/unbound -c /var/unbound/unbound.conf

One of Jim's comments in 8758 was, "The I state indicates it's sleeping for over 20 seconds and per-se is not the problem because filterdns threads sleep for 1 minute so it will stay as S in the first 20 seconds and then move to I." So that may just be a red herring.

I didn't write it above but the missing IP in question this time was my home, and I log in every single day. Also AFAICT the IP didn't change (no notification in pfSense). So the IP just disappeared from the table one day.

@Andy142

Pretty solid proof then that the ISP device, connected to the pfSense WAN port took down the interface.
Afaik : reasons can be : if its a modem type device : they do this to signal down stream a data carrier loss.
Bad power.
Bad NIC.

Most often, these ISP devices have also a GUI. It's time to have a look at, maybe there are details about the loss available.

@Gokulapandi
The DNS resolver doesn't hand out private IPs by default. You have to enable this with a custom option:

server: private-domain: "<your-domain.tld>"

The server line is only needed if you haven't one already, otherwise you can write the private-domain line below of it.

@johnpoz yeah, I guess 10 would be enough for some IoT devices like light bulbs, you garage door, window blinds or sun shades (whatever the right word).
For the DMZ on the other hand it may be a bit slow.

@DjJoakim yeah so stuff using other than your IP will be redirected, and stuff using the pfsense IP will be allowed.

@Gertjan

will do, thank you very much for your help