@HopelessErrors said in Dynamic DNS Failing on Start:

This Netgate is powered on at the same time as the WAN device, but the WAN comes up before the Netgate is fully initialized

That's the best scenario.
During boot, ... this happens : read /etc/rc.boot
Lots of stuff is done, and wto of them are :
Interfaces are set up ...
and the DynDNS is send a signal with 'service reload dyndsall'. At that moment, the actual interfaces (normally A WAN) is copared with the last known good IP (it's cached / stored in a file).
If the cached IP and actual WAN IP are the same, nothing happens.
If they are different, an DynDNS update should take place.

I had to reboot my pfSense last week as a part of the monthy UPS / Network / whatever tests.
It rebooted at 10h15 AM.
During the boot process I saw several

<13>1 2025-01-23T10:15:53.916036+01:00 pfSense.bhf.tld check_reload_status 730 - - updating dyndns WAN_DHCP

which will trigger a dyndns sync.

These are the line that tell me dydnns was trying to :

<27>1 2025-01-23T10:15:56.615087+01:00 pfSense.bhf.tld php-fpm 629 - - /rc.dyndns.update: phpDynDNS: Not updating home.bhf.tld A record because the public IP address cannot be determined.

and 1 second later :

<27>1 2025-01-23T10:15:57.628645+01:00 pfSense.bhf.tld php-fpm 57727 - - /rc.dyndns.update: phpDynDNS: Not updating home.bhf.tld A record because the public IP address cannot be determined.

so that was a fail twice ... WAN wasn't ready yet I guess ?

But then still in the middle of the boot process (7 seconds later ):

<27>1 2025-01-23T10:16:11.802487+01:00 pfSense.bhf.tld php-fpm 629 - - /rc.dyndns.update: phpDynDNS: Not updating home.bhf.tld A record because the IP address has not changed.

Bingo !
The test was done, the IP WAN didn't changed - so there was nothing to do.
The test, it was checking with this URL :

2e256f8c-7d90-41db-b5b5-33fda8550106-image.png

Test for yourself :

http://checkip.dyndns.org
Click and see ^^

and it compared the IP from the URL with the srored, cached IP.
The dyndns cache file is here /cf/conf/ and starts with dyndns_.....
It contains your public WAN IP.
Check the file last modified date time stamp to see when the IP was modified for the last time.

I'm telling you all this, so you can do some checks on your side.

@Asmodeus666 hi, did you ever resolve this issue? I'm having the same problem and don't know how to fix this! Any help appreciated

@lohphat Probably worth you being aware of this post which is about an 11 dump of KEA on a 3100 which I've been having...

@bmeeks

👍

Another option that was needed in the past, as ISP had to (wanted to) capture all DNS traffic, aka forwarding to 'them'.
Not needed anymore these day.

@ppkwebsites-subscribe
Glad to here, it's working finally.
Yes, I had the same issue in the past, when setting up my pfSense on KVM. I had also to disable hardware checksum offloading.

Im glad that worked for you.

Are you aware that you dont need to add any DNS servers to PFS? It will do what is called resolving and ask the root servers for you. Bypassing the commercial servers you go directally to the source.

My DNS settings: Screenshot from 2025-01-21 08-21-15.png

Screenshot from 2025-01-21 08-22-09.png

@Gertjan Unfortunately, there is a problem with this set-up. If it is set up as shown in the pictures so it's work fine.
Pics.png

A solution was found 😊.Pics

@pika
It's in the DNS Resolver settings.
But as mentioned, maybe it's not there and hence not supported, since you've enabled KEA.

@bmeeks I did try that previously but I found the latency to from nextdns to be better, thank you for all your inputs, I will look into this further for some other alternatives

Can confirm iorx's "workaround" works. It seems the tld needs to be added as a domain override pointing to itself when a subdomain of that tld is used for local resolution and another subdomain is used for remote resolution via domain override.

In my case my local network uses main.lan and the remote site uses remote.lan
Only adding remote.lan as domain override to the remote site's DNS server made it work for less than a minute after flushing unbound's cache. Adding "lan" as domain override pointing to 127.0.0.1 made DNS resolution to remote.lan stable.

configured Domain Overrides
Screenshot 2025-01-19 at 20.55.04.png

pfsense version: 2.7.2

Thank you for the reply. Yes I can provide.

Should I message you it to you?

685ef897-9dfa-4656-81a3-8cb04f4c40f8-image.png

I am aware of the resolver interval, is there a way to bypass one url

example imap.gmail.com always forward to 8.8.8.8 do not save in firewall dns namesever for reuse

thus every time it gets the new ip address google has for the mail server, they change so fast the firewall can't keep up so the mail app at times says error after 5 mins it will resolve but that is unacceptable for modern use.

@Seeking-Sense said in Trouble importing DHCP Mappings from 2.6 to 2.7.2:

But existing and enabled are or should be two different things.

When an interface is not connected (you ripped out the network, or powered down the device or switch on the other side), the DHCP server serving that interface will detect the "DOWN" system / hardware event, and shut down.
pfSense won't even show you your DHCP server instance anymore.
But, no panic, the settings will still be there. And when you connect (power up) the connection, it will auto-start, with the previously known settings.

@Seeking-Sense said in Trouble importing DHCP Mappings from 2.6 to 2.7.2:

One other issues I have come across is that KEA DHCP causes issues throwing PHP errors / crash reports in conjunction with pfblockerng dev.

kea initially, when using 23.09 ? I can't recall, work fine but the implemention'27.2' (and 23.09, 24.03, before 24.11 came out) was, for my needs, to minimalist.
You can use Kea, if you validated your requirement first.

Here they are : Netgate Adds Kea DHCP to pfSense Plus Software Version 23.09

As you can see, the details are here - published November 2023 :

15493662-314e-4f6b-a7b1-21d126113858-image.png

So, you need "static MAC DHCP leases" ?
Ok, fine. Stick with ISC for the moment.

Right now, 24.11 adds static DHCP leases, DNS registration, but is still limited about adding your own DHCP options.
The upcoming 2.8.0 will have the same Kea support.

Btw : kea by itself was and is rock solid for me. It had to stick with ISC because I wanted to keep my DHCP mac leases, my DHCP special options etc, but since 24.11 became available, I switched to kea. Options were still missing but with some copy and paste instructions from the source' (redmine) I could add what I needed.

Btw : kea has no relations with pfBlockerng.

@jg3

I am seeing the same behavior with random physical clients on my network. Turning off the new DNS registration checkbox seems to make it stop.

@aGeekhere said in ISC DHCP Server Custom DHCP Options 252 for WPAD prevents DHCP Static Mappings custom DNS:

if i use ISC DHCP with Custom DHCP Options

Check if it actually works. Go to packet capturing, enter/set this :

5b09c119-78ee-4da9-8c90-1cfb48875fb5-image.png

and click start.

You will see the DHCP client requests, and the pfSense DHCP server answer. The "Option 252" was send to the client ?

@johnpoz

Thanks for the information.
So it's not as critical as expected.

Thank you.

Best,

@wc2l what would be slick is if they integrate that right into pfsense. I think it might play nice with their new multisystem management stuff they are working on.. But yeah I would someone if not currently will put a docker for it ;)