help needed with troubleshooting os-ddclient with dyndns (DynDNS Pro)

[BISI Sysadmin]

Well, push has finally come to shove.  I have 15 clients hosted at dyn.com (formerly and a.k.a. dyndns) for which I have repeatedly failed to get os-ddclient to work.  I no longer have the luxury of relying on the os-dyndns plugin. I am faced with a hardware replacement scenario, and I might as well bite the bullet.  I have a new protectli-hosted OPNsense 23.7.3-amd64; FreeBSD 13.2-Release-p2; OpenSSL 1.1.1v 1 Aug 2023.

Everything restored perfectly from backup, excluding of course the os-dyndns plugin. So I've added os-ddclient, and it has reliably failed out of the gate.  After several unproductive troubleshooting attempts, including a file generated by dyn.com's "upate client configurator" https://account.dyn.com/tools/clientconfig.html, I have, per some successful ddclient troubleshooting on the FreeBSD forums, reached an error message that I can't get past, and a large amount of internet searching has not provided any clues.  The basic idea that worked with native FreeBSD does not work here.  I always end up with this message:

Code Select Expand

FAILED:   updating N0T: notfqdn: A Fully-Qualified Domain Name was not provided

So I've reproduced the logs and the troubleshooting in the hope that someone here can elucidate, or suggest something to try, or at least a clue where the problem originates.

The starting conditions:
The OPNSense host is named bogus1.dyndns-at-home.com
There is a DNS record at dyndns.com of the same name, with the IP address of the machine before the hardware failure, from a different ISP

I have os-ddclient set with these parameters:

Code Select Expand

Edit Account
Enabled               < X >
Description           https://account.dyn.com/
Service               DynDNS.com
Username              <redacted>
Password              <redacted>
Wildcard              <  >
Hostname(s)           bogus1.dyndns-at-home.com
Check ip method       Interface
Interface to monitor  WAN
Check ip timeout      10
Force SSL             < X >

Which creates this config file ( /usr/local/etc/ddclient.conf ):

Code Select Expand

syslog=yes                  # log update msgs to syslog
pid=/var/run/ddclient.pid   # record PID in file.
ssl=yes

usev4=ifv4, ifv4=igb0, \
protocol=dyndns2, \
login=<redacted>, \
password=<redacted> \
bogus1.dyndns-at-home.com

Now, get shell access as root via SSH
stop the daemonized ddclient

Code Select Expand

kill -TERM `cat /var/run/ddclient.pid`
verify the .pid file is gone

Code Select Expand

cat /var/run/ddclient.pid
  cat: /var/run/ddclient.pid: No such file or directory
purge the ddclient cache

Code Select Expand

rm /var/tmp/ddclient.cache
run ddclient in debug mode, in the foreground (per FreeBSD troubleshooting)

Code Select Expand

ddclient -daemon=0 -debug -verbose -noquiet

This also fails to update the ip address at dyn.com, ending with the usual.

Code Select Expand

FAILED:   updating N0T: notfqdn: A Fully-Qualified Domain Name was not provided

I have attached two files:
ddclient_debug_output - the output from the debug screen
ddclient_syslog.log - the "all levels" output recorded by syslog during the exercise.

Any help greatly appreciated!
d.

[9axqe]

Just out of curiosity, why didn't you configure using the GUI?

[BISI Sysadmin]

Just out of curiosity, why didn't you configure using the GUI?

I did configure os-ddclient using the GUI. I have done that at every major upgrade and several minor upgrades of OPNSense for a number of years now, never with any success. The syslog detail was insufficient to do much troubleshooting.  So, what I have posted is the verbose debug output derived from using the GUI-configured ddclient.conf file (which looks *very* unlike the one proposed by the dyndns client configurator).  The debug output is obtained by shutting down the daemonized ddclient, and running the noted command in the shell.  The extra detail didn't mean anything to me, hence the posting.

[9axqe]

do you have maybe a special character in your password that may break parsing and hence prevent reading the last line of ddclient.conf where the FQDN is located?

[BISI Sysadmin]

do you have maybe a special character in your password that may break parsing and hence prevent reading the last line of ddclient.conf where the FQDN is located?

BINGO!  Thank you for that suggestion.  I have been using that (extremely strong) password for this purpose for so long that I never even considered it as a potential issue.  I'm guessing it was either the spaces or the @ symbol.  Not going to experiment to find out, either, ' cause now I have 15 other OPNSense routers that have a broken os-dyndns plugin.  At least I can get os-ddclient installed and working before I upgrade those.

Cheers!
d.