pfSense

Nope. Just updated to "Sun Oct 10 23:06:39 EDT 2010" and the same test produces the same behavior: DynDNS.org still points to X.Y.136.67 while pppoe1 now has X.Y.124.54.

The syslog clearly shows the "check_reload_status: updating dyndns wan" entry, indicating it's somehow attempted to, but the only way it updates my entry is by manually clicking the 'edit' and 'save' buttons on the UI for that entry.

To clarify:
- Running Dynamic DNS client, type "DynDNS (static)"
- Wildcard enabled, no MX
- Using a long-standing account that's been fine updating until (as noted on the support ML) the July/August timeframe.

And I do the same thing on mine and it works:

Oct 12 11:28:34 blooper check_reload_status: updating dyndns wan
Oct 12 11:28:35 blooper php: : DynDns: Running updatedns()
Oct 12 11:28:35 blooper php: : DynDns: updatedns() starting
Oct 12 11:28:35 blooper php: : DynDns: _detectChange() starting.
Oct 12 11:28:35 blooper php: : DynDns: _checkIP() starting.
Oct 12 11:28:35 blooper php: : DynDns debug information: x.x.217.98 extracted from local system.
Oct 12 11:28:35 blooper php: : DynDns: Current WAN IP: x.x.217.98
Oct 12 11:28:35 blooper php: : DynDns: Cached IP: x.x.86.95
Oct 12 11:28:35 blooper php: : DynDns debug information: DynDns: cacheIP != wan_ip.  Updating. Cached IP: x.x.86.95 WAN IP: x.x.217.98 
Oct 12 11:28:35 blooper php: : DynDns: DynDns _update() starting.
Oct 12 11:28:36 blooper php: : DynDns: DynDns _checkStatus() starting.
Oct 12 11:28:36 blooper php: : DynDns: Current Service: dyndns
Oct 12 11:28:36 blooper php: : DynDns: _checkIP() starting.
Oct 12 11:28:36 blooper php: : DynDns debug information: x.x.217.98 extracted from local system.
Oct 12 11:28:36 blooper php: : phpDynDNS: updating cache file /conf/dyndns_wandyndns.cache: x.x.217.98
Oct 12 11:28:36 blooper php: : phpDynDNS: (Success) IP Address Changed Successfully! (x.x.217.98)

• DynDNS (Dynamic) -- though in the code it looks like Static takes the same code paths so it may not matter
• No Wildcard, no MX

Perhaps the difference is the platform. Mine's running the embedded NanoBSD build and I get no such 'DynDns: xxx' messages unless I edit & save the DynDNS entry.

That is possible, I am on a full install. First, can you try setting for DynDNS (Dynamic) and unchecking Wildcard just to see if that makes any difference?

Any way you can try to switch to a non-embedded install as a test temporarily to help narrow it down?

Switched to DynDNS (Dynamic) and unset the wildcard. Tested with the three combinations (dynamic/wild, static/nowild, dynamic/nowild) to no avail.

Switching to a full install is not an option for me right now.

Will look at opening a forum account and doing so. Already discussed on the support@ ML and Chris suggested opening a ticket.

Yeah that's good but the forum sees more traffic, and the 2.0 board is very active. There are probably quite a few people in a position to help test.

Updated to "FreeBSD 8.1-RELEASE-p1 #0: Sat Oct 23 01:35:35 EDT 2010" and no improvement. System log shows only the "check_reload_status: updating dyndns wan" entry, nothing further.

Are you sure that you have the latest snapshot?
Can you post a system log here?
Can you post your config here?

Ermal -
Yes, I was running the latest snapshot two weeks ago when you asked me to try again, I made sure the snapshot I used was cut well after you made the changes according to the git log. I will update again and show as much again. I've also posted one set of logs, and don't see what benefit will come from the effort of sanitizing my config just to post it is going to do - what else are you looking for? Has anyone else tried using the NanoBSD build to confirm the bug?

Michel -
It's pretty well-established that it works fine on the full installation, but not on the embedded build I'm using.

Your log makes me suggest you reinstall from scratch because you might have some corrupted/modified files.

Will look at doing so, but it may be a day or two. I may just set up a VM with a vanilla NanoBSD installation and test that.

I'm running a clean install of NanoBSD 4GB dated Oct 8, 2010 and I'm not having any issues with this.

I am seeing the same problem on a clean boot of pfSense-2.0-BETA4-20101120-0520.iso - well a clean install followed by a restore of my configuration.

The connection is via Comcast Cable.
When the cablemodem comes online, it initially gives out a 192.168.100.x address.
A short while later, it revokes it and gives out the correct address.

When the 192.x.x.x address is given out, the dyndns script fails with exactly the same error as the real IP later ... so I will only copy the last log:

Nov 21 23:02:10 firewall dhclient⁴²⁰⁹⁶: bound to 24.x.x.x -- renewal in 1800 seconds.
Nov 22 07:02:10 firewall check_reload_status: Rewriting resolv.conf
Nov 21 23:02:10 firewall php: : rc.newwanip: Informational is starting em1.
Nov 21 23:02:10 firewall php: : rc.newwanip: Informational is starting em1.
Nov 21 23:02:10 firewall php: : rc.newwanip: on (IP address: 24.x.x.x) (interface: wan) (real interface: em1).
Nov 21 23:02:10 firewall php: : rc.newwanip: on (IP address: 24.x.x.x) (interface: wan) (real interface: em1).
Nov 21 23:02:10 firewall php: : ROUTING: change default route to 24.x.x.1
Nov 21 23:02:10 firewall php: : ROUTING: change default route to 24.x.x.1
Nov 21 23:02:11 firewall apinger: Starting Alarm Pinger, apinger(21973)
Nov 21 23:02:11 firewall apinger: Starting Alarm Pinger, apinger(21798)
Nov 21 23:02:11 firewall php: : DynDns: Running updatedns()
Nov 21 23:02:11 firewall php: : DynDns: Running updatedns()
Nov 21 23:02:11 firewall php: : DynDns: updatedns() starting
Nov 21 23:02:11 firewall php: : DynDns: updatedns() starting
Nov 21 23:02:11 firewall php: : DynDns: _detectChange() starting.
Nov 21 23:02:11 firewall php: : DynDns: _checkIP() starting.
Nov 21 23:02:11 firewall php: : DynDns: _detectChange() starting.
Nov 21 23:02:11 firewall php: : DynDns: _checkIP() starting.
Nov 21 23:02:11 firewall php: : DynDns debug information: 24.x.x.x extracted from local system.
Nov 21 23:02:11 firewall php: : DynDns: Current WAN IP: 24.x.x.x
Nov 21 23:02:11 firewall php: : DynDns debug information: 24.x.x.x extracted from local system.
Nov 21 23:02:11 firewall php: : DynDns: Current WAN IP: 24.x.x.x
Nov 21 23:02:11 firewall php: : DynDns: Cached IP: 0.0.0.0
Nov 21 23:02:11 firewall php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: 0.0.0.0 WAN IP: 24.x.x.x
Nov 21 23:02:11 firewall php: : DynDns: DynDns _update() starting.
Nov 21 23:02:11 firewall php: : DynDns: Cached IP: 0.0.0.0
Nov 21 23:02:11 firewall php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: 0.0.0.0 WAN IP: 24.x.x.x
Nov 21 23:02:11 firewall php: : DynDns: DynDns _update() starting.
Nov 21 23:02:13 firewall dnsmasq³⁹⁸⁴⁶: reading /etc/resolv.conf
Nov 21 23:02:13 firewall dnsmasq³⁹⁸⁴⁶: using nameserver 68.87.78.134#53
Nov 21 23:02:13 firewall dnsmasq³⁹⁸⁴⁶: using nameserver 68.87.76.182#53
Nov 21 23:02:18 firewall php: : Curl error occurred: Couldn't resolve host 'members.dyndns.org'
Nov 21 23:02:18 firewall php: : Curl error occurred: Couldn't resolve host 'members.dyndns.org'
Nov 21 23:02:18 firewall php: : DynDns: DynDns _checkStatus() starting.
Nov 21 23:02:18 firewall php: : DynDns: Current Service: dyndns
Nov 21 23:02:18 firewall php: : DynDns: DynDns _checkStatus() starting.
Nov 21 23:02:18 firewall php: : DynDns: Current Service: dyndns
Nov 21 23:02:18 firewall php: : phpDynDNS: PAYLOAD:
Nov 21 23:02:18 firewall php: : phpDynDNS: PAYLOAD:
Nov 21 23:02:18 firewall php: : phpDynDNS: (Unknown Response)
Nov 21 23:02:18 firewall php: : phpDynDNS: (Unknown Response)
Nov 21 23:02:24 firewall php: : Resyncing openvpn instances configurations for interface WAN.

I went to edit the dyndns rule, and saved it again.
This triggered the script to run again, and this time it worked.
(Exact same IP and DNS servers, only everything succeeded)

I guess maybe Comcast takes a few seconds after the interface comes up before they can reply to DNS queries.

Would it be possible for the dyndns script to retry after maybe 30 seconds if it failed?

Same problem. Dyndns(dynamic) only updates when saving.
No wildcards
Full new install no config restore.

ADSL is a DSL PPPoE link in bridged (dumb modem) mode
wan is nic card connected to fibre modem
lan and vlan

2.0-BETA4 (amd64)
built on Mon Nov 22 12:02:04 UTC 2010
Pentium(R) Dual-Core CPU E5300 @ 2.60GHz
2GB Ram

Packages:Squid, squidguard, phpSysInfo

Log:
Nov 23 07:42:24 kernel: arp:xxx.xxx.xx.xx moved from 00:0f:1f:2f:36:c7 to 00:0f:1f:3b:0e:61 on em1_vlan2
Nov 23 06:50:36 dnsmasq²²⁷⁹¹: using nameserver xxx.xxx.xxx.xx#53
Nov 23 06:50:36 dnsmasq²²⁷⁹¹: using nameserver xxx.xxx.xxx.xx#53
Nov 23 06:50:36 dnsmasq²²⁷⁹¹: using nameserver xxx.xxx.xxx.xx#53
Nov 23 06:50:36 dnsmasq²²⁷⁹¹: reading /etc/resolv.conf
Nov 23 06:46:28 check_reload_status: reloading filter
Nov 23 06:46:28 check_reload_status: reloading filter
Nov 23 06:46:28 kernel: ovpns1: link state changed to UP
Nov 23 06:46:28 check_reload_status: reloading filter
Nov 23 06:46:28 check_reload_status: reloading filter
Nov 23 06:46:28 kernel: ovpns1: link state changed to DOWN Nov 23 06:46:28 php: :Resyncing openvpn instances configurations for interface ADSL.
Nov 23 06:46:22 php: : phpDynDNS: (Unknown Response)
Nov 23 06:46:22 php: : phpDynDNS: PAYLOAD:
Nov 23 06:46:22 php: : DynDns: Current Service: dyndns
Nov 23 06:46:22 php: : DynDns: DynDns _checkStatus() starting.
Nov 23 06:46:22 php: : Curl error occurred: connect() timed out!
Nov 23 06:45:52 php: : DynDns: DynDns _update() starting.
Nov 23 06:45:52 php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: xxx.xxx.79.44 WAN IP: xxx.xxx.79.4
Nov 23 06:45:52 php: : DynDns: Cached IP: xxx.xxx.79.44
Nov 23 06:45:52 php: : DynDns: Current WAN IP: xxx.xxx.79.4
Nov 23 06:45:52 php: : DynDns debug information: xxx.xxx.79.4 extracted from local system.
Nov 23 06:45:52 php: : DynDns: _checkIP() starting.
Nov 23 06:45:52 php: : DynDns: _detectChange() starting.
Nov 23 06:45:52 apinger: Starting Alarm Pinger, apinger(51255)
Nov 23 06:45:52 php: : DynDns: updatedns() starting
Nov 23 06:45:52 php: : DynDns: Running updatedns()
Nov 23 06:45:52 apinger: Exiting on signal 15.
Nov 23 06:45:52 check_reload_status: Rewriting resolv.conf
Nov 23 06:45:50 check_reload_status: Rewriting resolv.conf
Nov 23 01:01:01 php: : phpDynDNS: (Success) IP Address Changed Successfully! (xxx.xxx.79.44)
Nov 23 01:01:01 php: : phpDynDNS: updating cache file /conf/dyndns_opt2dyndns'my.dnsalias.com'.cache: xxx.xxx.79.44
Nov 23 01:01:01 php: : DynDns debug information: xxx.xxx.79.44 extracted from local system.
Nov 23 01:01:01 php: : DynDns: _checkIP() starting.
Nov 23 01:01:01 php: : DynDns: Current Service: dyndns
Nov 23 01:01:01 php: : DynDns: DynDns _checkStatus() starting.
Nov 23 01:01:00 php: : DynDns: DynDns _update() starting.
Nov 23 01:01:00 php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: xxx.xxx.79.102 WAN IP: xxx.xxx.79.44
Nov 23 01:01:00 php: : DynDns: Cached IP: xxx.xxx.79.102
Nov 23 01:01:00 php: : DynDns: Current WAN IP: xxx.xxx.79.44
Nov 23 01:01:00 php: : DynDns debug information: xxx.xxx.79.44 extracted from local system.
Nov 23 01:01:00 php: : DynDns: _checkIP() starting.
Nov 23 01:01:00 php: : DynDns: _detectChange() starting.
Nov 23 01:01:00 php: : DynDns: updatedns() starting
Nov 23 01:01:00 php: : DynDns: Running updatedns()
Nov 22 20:12:26 check_reload_status: reloading filter
Nov 22 20:12:26 kernel: ovpns1: link state changed to UP Nov 22 20:12:26 last message repeated 2 times
Nov 22 20:12:26 check_reload_status: reloading filter
Nov 22 20:12:26 kernel: ovpns1: link state changed to DOWN
Nov 22 20:12:26 php: : Resyncing openvpn instances configurations for interface ADSL.
Nov 22 20:12:20 php: : phpDynDNS: (Unknown Response)
Nov 22 20:12:20 php: : phpDynDNS: PAYLOAD:
Nov 22 20:12:20 php: : DynDns: Current Service: dyndns
Nov 22 20:12:20 php: : DynDns: DynDns _checkStatus() starting.
Nov 22 20:12:20 php: : Curl error occurred: connect() timed out!
Nov 22 20:11:55 dnsmasq²²⁷⁹¹: using nameserver xxx.xxx.xxx.xx#53
Nov 22 20:11:55 dnsmasq²²⁷⁹¹: using nameserver xxx.xxx.xxx.xx#53
Nov 22 20:11:55 dnsmasq²²⁷⁹¹: using nameserver xxx.xxx.xx.xx#53
Nov 22 20:11:55 dnsmasq²²⁷⁹¹: reading /etc/resolv.conf
Nov 22 20:11:50 php: : DynDns: DynDns _update() starting
Nov 22 20:11:50 php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: xxx.xxx.79.102 WAN IP: xxx.xxx.79.44
Nov 22 20:11:50 php: : DynDns: Cached IP: xxx.xxx.79.102
Nov 22 20:11:50 php: : DynDns: Current WAN IP: xxx.xxx.79.44
Nov 22 20:11:50 php: : DynDns debug information: xxx.xxx.79.44 extracted from local system.
Nov 22 20:11:50 php: : DynDns: _checkIP() starting.
Nov 22 20:11:50 php: : DynDns: _detectChange() starting. Nov 22 20:11:50 php: : DynDns: updatedns() starting
Nov 22 20:11:50 php: : DynDns: Running updatedns()
Nov 22 20:11:50 apinger: Starting Alarm Pinger, apinger(10966)
Nov 22 20:11:50 apinger: Exiting on signal 15.
Nov 22 20:11:50 check_reload_status: Rewriting resolv.conf

@Jeppe Oland
can you try with a new snapshot i committed fix to retry resolving 3 times before bailing.

@Hugo please try with the forums your problem is not related to this ticket.

Can you try with a new snapshot i committed fix to retry resolving 3 times before bailing.

Will do ... but with the holidays I can't verify until sometime next week.

One question about the retry logic ... regarding safety:
What happens in my case, if the connection comes up with the 192.x.x.x address. You try up to three times, but before it completes that, the IP is released and a new is given out.
Will 2 scripts run at the same time?
Can that cause problems?

Sorry, but it doesn't seem to be working.

I tested with a clean install of pfSense-2.0-BETA4-20101201-1616.iso followed by a config restore.
During all this, the cable modem was powered off.

After pfSense was booted successfully with my configuration, I powered on the cable modem.

Failure is the same as before, and I don't see any retries.

Can you show me the new logs please?

Trust me - I tried.
Yesterday, the server kept giving me "Internal error" whenever I updated this bug ... other bugs worked fine though.

To add more detail, here are some log snippets.

First IP assignment (bogus 192.168.x.x address local to the modem):
Dec 1 23:54:11 firewall php: : rc.newwanip: on (IP address: 192.168.100.10) (interface: wan) (real interface: em1).
Dec 1 23:54:11 firewall apinger: Starting Alarm Pinger, apinger(6180)
Dec 1 23:54:11 firewall apinger: No usable targets found, exiting
Dec 1 23:54:11 firewall php: : DynDns: Running updatedns()
Dec 1 23:54:11 firewall php: : DynDns: updatedns() starting
Dec 1 23:54:11 firewall php: : DynDns: _detectChange() starting.
Dec 1 23:54:11 firewall php: : DynDns: _checkIP() starting.
Dec 1 23:54:11 firewall php: : Dyndns debug information: Could not resolve checkip.dyndns.org to ip using interface ip 192.168.100.10.
Dec 1 23:54:11 firewall php: : DynDns: Current WAN IP: 192.168.100.10
Dec 1 23:54:11 firewall php: : DynDns: No Cached IP found.
Dec 1 23:54:11 firewall php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: 0.0.0.0 WAN IP: 192.168.100.10 Inital update.
Dec 1 23:54:11 firewall php: : DynDns: DynDns _update() starting.
Dec 1 23:54:11 firewall php: : Curl error occurred: Couldn't resolve host 'members.dyndns.org'
Dec 1 23:54:11 firewall php: : DynDns: DynDns _checkStatus() starting.
Dec 1 23:54:11 firewall php: : DynDns: Current Service: dyndns
Dec 1 23:54:11 firewall php: : phpDynDNS: PAYLOAD:
Dec 1 23:54:11 firewall php: : phpDynDNS: (Unknown Response)

A few seconds later, the new IP is handed out:
Dec 1 23:55:14 firewall php: : rc.newwanip: on (IP address: 24.x.x.x) (interface: wan) (real interface: em1).
Dec 1 23:55:14 firewall php: : ROUTING: change default route to 24.x.x.1
Dec 1 23:55:14 firewall apinger: Starting Alarm Pinger, apinger(35932)
Dec 1 23:55:14 firewall php: : DynDns: Running updatedns()
Dec 1 23:55:14 firewall php: : DynDns: updatedns() starting
Dec 1 23:55:14 firewall php: : DynDns: _detectChange() starting.
Dec 1 23:55:14 firewall php: : DynDns: _checkIP() starting.
Dec 1 23:55:14 firewall php: : DynDns debug information: 24.x.x.x extracted from local system.
Dec 1 23:55:14 firewall php: : DynDns: Current WAN IP: 24.x.x.x
Dec 1 23:55:14 firewall php: : DynDns: Cached IP: 0.0.0.0
Dec 1 23:55:14 firewall php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: 0.0.0.0 WAN IP: 24.x.x.x
Dec 1 23:55:14 firewall php: : DynDns: DynDns _update() starting.
Dec 1 23:55:17 firewall dnsmasq³⁴⁷⁷⁴: reading /etc/resolv.conf
Dec 1 23:55:17 firewall dnsmasq³⁴⁷⁷⁴: using nameserver 68.87.78.134#53
Dec 1 23:55:17 firewall dnsmasq³⁴⁷⁷⁴: using nameserver 68.87.76.182#53
Dec 1 23:55:21 firewall php: : Curl error occurred: Couldn't resolve host 'members.dyndns.org'
Dec 1 23:55:21 firewall php: : DynDns: DynDns _checkStatus() starting.
Dec 1 23:55:21 firewall php: : DynDns: Current Service: dyndns
Dec 1 23:55:21 firewall php: : phpDynDNS: PAYLOAD:
Dec 1 23:55:21 firewall php: : phpDynDNS: (Unknown Response)

Note that on the first failure, both checkip.dyndns.org and members.dyndns.org fail.
In the second failure there is no mention of checkip failing ... and there is no retry logic on curl.

Manually running the /etc/rc.dyndns.update script after the connection is verified working succeeds.

Any ideas on this one?

It looks strange to me that your dns updates during dyndns running which is highly unlikely to happen!
Are you on dhcp link?

Yes, the connection is Comcast Cable with DHCP.
I agree it seems strange, but it happens every time.
Thankfully, they give me the same IP almost every time, so I survive.

It looks strange to me that your dns updates during dyndns running which is highly unlikely to happen!

What do you mean "dns updates during dyndns running"?
What seems more likely is that DNS simply does not work for a second after the IP is delivered.

I looked at the script code, and the flow is this:
1) Cablemodem delivers a local (192.168.x.x) address since the connection hasn't established yet.
2) Update script runs, and "_checkIP" fails to hit checkip.dyndns.org as mentioned in the log.
3) Cablemode connects, revokes the local address and issues a new routable address.
4) Update script runs. Since the new address (24.x.x.x) is publicly routable, "_checkIP" does nothing
and simply uses the address as-is.
5) Since DNS is not working yet, "_update" fails to access members.dyndns.org

After this, there is no retry logic, and dyndns will not be updated.

Just re-installed a fresh image on a different CF card "Version 2.0-BETA5 (i386) built on Mon Jan 3 04:24:15 EST 2011", platform "nanobsd (4g)".

Exhibits exact same behaviour as outlined in comment 15 above, DynDNS does not update when the bridged DSL connection drops and is re-connected.

Can you try again with new snapshots i added some changes to make dns reloading faster and have more time to reload before dyndns gets called.

Updated to "Version 2.0-BETA5 (i386) built on Thu Jan 20 23:14:10 EST 2011", same behavior:

1.  Unplug working bridged DSL connection with correct DynDNS entry
 2.  Wait until system acknowledges the connection as fully down and is attempting re-connections ("ppp: [wan_link0] LCP: state change Stopped --> Starting" log entries)
 3.  Plug DSL connection back in, wait for pfSense to sense and re-build PPP WAN connection
 4.  Observe logs, no indication updatedns() was run or even attempted; nslookup concurs
 5.  Wait 60 seconds, still no update
 6.  Forcefully reset DDNS by clicking edit/save

Post your system log from the time of the reconnect, especially anything that mentions rc.newwanip and entries around it.

Some other possible fix pushed.

I think this can be closed now...

I've been testing it for about Two weeks and it works fine.

Unfortunately I disagree - still not seeing DDNS update on a clean install of the NanoBSD images as noted in comment 31 above and updated to snapshot dated "Wed Feb 16 03:53:41 EST 2011". Same behavior as before.

Of note also is that BETA5 has been fat-fingered to BEAT5 in recent images.

R B wrote:

Unfortunately I disagree - still not seeing DDNS update on a clean install of the NanoBSD images as noted in comment 31 above and updated to snapshot dated "Wed Feb 16 03:53:41 EST 2011". Same behavior as before.

Of note also is that BETA5 has been fat-fingered to BEAT5 in recent images.

This is gonna sound really stupid but:

Do me a favor and see if you maybe by accidend checked the "disable" checkbox at the top of the dyndns account settings.... (i did this once and it took me three days to notice this...)

The only thing it's less stupid than is finding out that was the problem. I have no idea when or how that got checked - perhaps because I've come to (perhaps incorrectly) expect the checkbox at the top of a group of settings in pfSense to have the opposite meaning, to enable.

Thanks to all for helpfully troubleshooting my failure to read carefully. No idea if Jeppe's issue was addressed, but mine can't really be addressed by the pfSense team.

I am seeing this behaviour on RC1 (and was also on several Beta 5 builds prior to updating to RC1) with a 3G connection. In this case I'm not doing anything to trigger the update, the ISP is doing that for me. The status page is updated with the new IP and in Dynamic DNS the new IP is shown next to "Cached IP" but the IP in the dynamic DNS provider (No-IP in my case) never gets updated.

A reboot of the firewall is often required to fix this situation, or sometimes simply disabling and re-enabling that particular dynamic DNS entry works. I can confirm "Disabled" is not checked. Happy to provide any logs if requested.