DDNS Won't Update Dynu

DDNS in GUI always shows red. Running command manually outputs the following:

#ddns -d update-all --force
Dynamic DNS update for [host-redacted].ddnsgeek.com (Dynu) threw an unhandled exception:
Traceback (most recent call last):
File “/usr/lib/python3.10/site-packages/ddns/init.py”, line 178, in _update
entry(force=force)
File “/usr/lib/python3.10/site-packages/ddns/providers.py”, line 162, in call
self.update()
File “/usr/lib/python3.10/site-packages/ddns/providers.py”, line 986, in update
self.send_request(data)
File “/usr/lib/python3.10/site-packages/ddns/providers.py”, line 378, in send_request
response = DDNSProvider.send_request(self, self.url, data=data, username=self.username, password=self.password)
File “/usr/lib/python3.10/site-packages/ddns/providers.py”, line 323, in send_request
return self.core.system.send_request(*args, **kwargs)
File “/usr/lib/python3.10/site-packages/ddns/system.py”, line 129, in send_request
query_args = self._format_query_args(data)
File “/usr/lib/python3.10/site-packages/ddns/system.py”, line 257, in _format_query_args
arg = “%s=%s” % (k, urllib.parse.quote(v))
File “/usr/lib/python3.10/urllib/parse.py”, line 870, in quote
return quote_from_bytes(string, safe)
File “/usr/lib/python3.10/urllib/parse.py”, line 895, in quote_from_bytes
raise TypeError(“quote_from_bytes() expected bytes”)
TypeError: quote_from_bytes() expected bytes

Hallo @suroot09

Welcome to the IPFire community.

I am also using dynu and the same domain name and also have a few unhandled exceptions in my log but different to yours.

IPFire diagnostics
Section: ddns
Date: August 13, 2024

07:05:11 ddns[21154]: Dynamic DNS update for xxxxxx.ddnsgeek.com (Dynu) threw an unhandled exception: Traceback (most recent call last): File “/usr/lib/python3.10/site-packages/ddns/system.py”, line 276, in get_address return self.__addresses[proto] KeyError: ‘ipv4’ During handling of the above exception, another exception occurred: Traceback (most recent call last): File “/usr/lib/python3.10/urllib/request.py”, line 1348, in do_open h.request(req.get_method(), req.selector, req.data, headers, File “/usr/lib/python3.10/http/client.py”, line 1282, in request self._send_request(method, url, body, headers, encode_chunked) File “/usr/lib/python3.10/http/client.py”, line 1328, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File “/usr/lib/python3.10/http/client.py”, line 1277, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File “/usr/lib/python3.10/http/client.py”, line 1037, in _send_output self.send(msg) File "/usr/lib/pytho

However my DDNS is successfully updating and is showing green.

I just checked and it was last successfully updated yesterday.

I just tried the same command as you did and that also worked fine for me with no unhandled exception.

ddns -d update-all --force
Debugging mode enabled
Registered new provider: All-inkl.com (all-inkl.com)
Registered new provider: ChangeIP.com (changeip.com)
Registered new provider: DDNSS (ddnss.de)
Registered new provider: desec.io (desec.io)
Registered new provider: DHS International (dhs.org)
Registered new provider: Lightning Wire Labs DNS Service (dns.lightningwirelabs.com)
Registered new provider: DNSmadeEasy.com (dnsmadeeasy.com)
Registered new provider: DNS Park (dnspark.com)
Registered new provider: Domain-Offensive (do.de)
Registered new provider: Google Domains (domains.google.com)
Registered new provider: domopoli.de (domopoli.de)
Registered new provider: DtDNS (dtdns.com)
Registered new provider: Duck DNS (duckdns.org)
Registered new provider: dy.fi (dy.fi)
Registered new provider: Dyn (dyndns.org)
Registered new provider: DyNS (dyns.net)
Registered new provider: Dynu (dynu.com)
Registered new provider: DynUp.DE (dynup.de)
Registered new provider: EasyDNS (easydns.com)
Registered new provider: eNom Inc. (enom.com)
Registered new provider: EntryDNS (entrydns.net)
Registered new provider: freedns.afraid.org (freedns.afraid.org)
Registered new provider: he.net (he.net)
Registered new provider: INWX (inwx.com)
Registered new provider: it’s DNS (itsdns.de)
Registered new provider: Joker.com Dynamic DNS (joker.com)
Registered new provider: dynamicdns.key-systems.net (key-systems.net)
Registered new provider: Loopia AB (loopia.se)
Registered new provider: myonlineportal.net (myonlineportal.net)
Registered new provider: Namecheap (namecheap.com)
Registered new provider: NoIP (no-ip.com)
Registered new provider: NOW-DNS (now-dns.com)
Registered new provider: BIND nsupdate utility (nsupdate)
Registered new provider: nsupdate.info (nsupdate.info)
Registered new provider: OpenDNS (opendns.com)
Registered new provider: OVH (ovh.com)
Registered new provider: Regfish GmbH (regfish.com)
Registered new provider: Schokokeks (schokokeks.org)
Registered new provider: Selfhost.de (selfhost.de)
Registered new provider: servercow.de (servercow.de)
Registered new provider: SPDYN (spdns.org)
Registered new provider: Strato AG (strato.com)
Registered new provider: TwoDNS (twodns.de)
Registered new provider: Udmedia GmbH (udmedia.de)
Registered new provider: Variomedia (variomedia.de)
Registered new provider: XLhost (xlhost.de)
Registered new provider: Zoneedit (zoneedit.com)
Registered new provider: zzzz (zzzz.io)
Running on distribution: ipfire-2
Loading configuration file /var/ipfire/ddns/ddns.conf
Updating xxxxxx.ddnsgeek.com forced
Sending request (GET): https://checkip4.dns.lightningwirelabs.com
Request header:
User-agent: IPFireDDNSUpdater/014
Pragma: no-cache
Response header (Status Code 200):
date: Tue, 20 Aug 2024 14:28:10 GMT
upgrade: h2,h2c
connection: Upgrade
x-content-type-options: nosniff
x-frame-options: deny
referrer-policy: strict-origin
x-xss-protection: 1; mode=block
content-length: 34
content-type: text/plain
strict-transport-security: max-age=31536000; includeSubDomains; preload
Sending request (GET): https://api.dynu.com/nic/update?hostname=xxxxxx.ddnsgeek.com&myip=xxx.xxx.xxx.xxx
Request header:
Authorization: Basic xxxxxxxxxxxxxxxxx
User-agent: IPFireDDNSUpdater/014
Pragma: no-cache
Response header (Status Code 200):
Date: Tue, 20 Aug 2024 14:28:11 GMT
Server: Dynu Web Server
X-Powered-By: Dynu Dynamic DNS Service
Content-Length: 5
Content-Type: text/html; charset=UTF-8
Dynamic DNS update for xxxxxx.ddnsgeek.com (Dynu) successful
Logging successful update for xxxxxx.ddnsgeek.com
Opening database /var/lib/ddns.db

Did your logs not have the “Debugging mode enabled” message. If not then your update crashed very early on.

Which Core Update version of IPFire are you running?

Did you have tour Dynu DDNS update working and it has then stopped or has it never worked?

If it used to work, when did it stop working, when you did a Core Update or what? If it was at a core update then which Core Update were you upgrading from and which Core Update upgrading to?

Good morning Adolf. I’m currently running Core-Update 187. I noticed it back in build 184 after an update, but thought it was something specific to Dynu, specifically an authentication thing. I spun up a test instance on changeip.com, and that one does claim to be successful according to the logs, but I’m not sure if it is only successful since it was added or it that is the fixed. It has not automatically attempted since it was added.

The logs did not have the "Debugging mode enabled” message. The output is specifically from terminal since the stack gets cut off from GUI logs.

It use to work consistently fine up until build 184 or around that time. I only noticed it due to Dynu’s portal not having the update after a change.

Weirdly, the test instance on ChangeIP.com also shows red in the DDNS menu, but logs suggest that everything is working fine.

Blockquote

Dynamic DNS update for [host-redacted].dns04.com (ChangeIP.com) successful

Then the DDNS code had a problem extremely early on.

My last output was also from the terminal using exactly the same command that you used.

ddns -d update-all --force

The -d is telling it to enable debugging and hence the first message in my output was “Debugging mode enabled”

The fact that you don’t see that means that the ddns code failed before it even got to trying to enable the debug mode and that is the first part of the ddns command line parsing code.

That is making me wonder if some problem occurred during your Core Update 184 update causing some code corruption, although there was no update to the ddns code for around 1.5 to 2 years.

As the issue also occurs directly with running ddns on the command line then it can’t be due to any issue with the WUI ddns.cgi code.

Could you check the hash for the ddns python3 code by running the command
sha256sum /usr/bin/ddns

The value I got from doing it on my CU187 system was

882bd4411de3d60f9d08f47768a71c61c26ce6e28a19ad01f7e7ce9aac3d590a

1 Like

I received the same checksum.
882bd4411de3d60f9d08f47768a71c61c26ce6e28a19ad01f7e7ce9aac3d590a /usr/bin/ddns

Weirdly, if I remove Dynu and only include ChangeIP, then it appears to work fine and I can see the Debugging Mode.

ddns -d update-all --force
Debugging mode enabled
Registered new provider: All-inkl.com (all-inkl.com)
Registered new provider: ChangeIP.com (changeip.com)
Registered new provider: DDNSS (ddnss.de)
Registered new provider: desec.io (desec.io)
Registered new provider: DHS International (dhs.org)
Registered new provider: Lightning Wire Labs DNS Service (dns.lightningwirelabs.com)
Registered new provider: DNSmadeEasy.com (dnsmadeeasy.com)
Registered new provider: DNS Park (dnspark.com)
Registered new provider: Domain-Offensive (do.de)
Registered new provider: Google Domains (domains.google.com)
Registered new provider: domopoli.de (domopoli.de)
Registered new provider: DtDNS (dtdns.com)
Registered new provider: Duck DNS (duckdns.org)
Registered new provider: dy.fi (dy.fi)
Registered new provider: Dyn (dyndns.org)
Registered new provider: DyNS (dyns.net)
Registered new provider: Dynu (dynu.com)
Registered new provider: DynUp.DE (dynup.de)
Registered new provider: EasyDNS (easydns.com)
Registered new provider: eNom Inc. (enom.com)
Registered new provider: EntryDNS (entrydns.net)
Registered new provider: freedns.afraid.org (freedns.afraid.org)
Registered new provider: he.net (he.net)
Registered new provider: INWX (inwx.com)
Registered new provider: it's DNS (itsdns.de)
Registered new provider: Joker.com Dynamic DNS (joker.com)
Registered new provider: dynamicdns.key-systems.net (key-systems.net)
Registered new provider: Loopia AB (loopia.se)
Registered new provider: myonlineportal.net (myonlineportal.net)
Registered new provider: Namecheap (namecheap.com)
Registered new provider: NoIP (no-ip.com)
Registered new provider: NOW-DNS (now-dns.com)
Registered new provider: BIND nsupdate utility (nsupdate)
Registered new provider: nsupdate.info (nsupdate.info)
Registered new provider: OpenDNS (opendns.com)
Registered new provider: OVH (ovh.com)
Registered new provider: Regfish GmbH (regfish.com)
Registered new provider: Schokokeks (schokokeks.org)
Registered new provider: Selfhost.de (selfhost.de)
Registered new provider: servercow.de (servercow.de)
Registered new provider: SPDYN (spdns.org)
Registered new provider: Strato AG (strato.com)
Registered new provider: TwoDNS (twodns.de)
Registered new provider: Udmedia GmbH (udmedia.de)
Registered new provider: Variomedia (variomedia.de)
Registered new provider: XLhost (xlhost.de)
Registered new provider: Zoneedit (zoneedit.com)
Registered new provider: zzzz (zzzz.io)
Running on distribution: ipfire-2
Loading configuration file /var/ipfire/ddns/ddns.conf
Updating [host-redacted].dns04.com forced
Sending request (GET): https://checkip4.dns.lightningwirelabs.com
Request header:
  User-agent: IPFireDDNSUpdater/014
  Pragma: no-cache
Dynamic DNS update for [host-redacted].dns04.com (ChangeIP.com) successful
Logging successful update for [host-redacted].dns04.com
Opening database /var/lib/ddns.db

So that code is fine.

Then I have no idea why your access attempt to Dynu fails so very early and mine to the same provider has no problems at all.

I am not familiar at all with python code so cannot easily understand the problem you are seeing.

Just to confirm, you have checked the hostname, username and passowrd in the DDNS WUI page to make sure they are correct.

You can also check the password is correct by looking at the

/var/ipfire/ddns/config

file, which contains the provider, the hostname, the username, the password and the enabled status.

You don’t have any really weird characters in your password do you? I only have lower case and upper case letters and number digits.

Maybe that is a factor. Info and password looks correct, but the password does contain special characters. Maybe it’s a parse error. I’ll update the password without special characters and retest.

Having another look at your initial fail messages when running DDNS on the command line you have

Most recent call last means that the original first call that failed is the one from init.py at line 178.

https://git.ipfire.org/?p=ddns.git;a=blob;f=src/ddns/init.py;h=ca232bf9ec4c571db60689b1b0cf74e00cf2f405;hb=refs/heads/master

176 def update(self, entry, force=False):
177 try:
178 entry(force=force)
179
180 except DDNSError as e:
181 logger.error(
(“Dynamic DNS update for %(hostname)s (%(provider)s) failed:”) %
182 {“hostname”: entry.hostname, “provider”: entry.name})
183 logger.error(" %s: %s" % (e.class.name, e.reason))
184 if e.message:
185 logger.error(" %s" % e.message)
186
187 except Exception:
188 logger.error(_(“Dynamic DNS update for %(hostname)s (%(provider)s) threw an unhandled exception:”) %
189 {“hostname”: entry.hostname, “provider”: entry.name}, exc_info=True)

This is indicating that it tried the force command but that had a problem and the result was not an expected one and so the logging of
Dynamic DNS update for %(hostname)s (%(provider)s) threw an unhandled exception:
where %(hostname)s was
[host-redacted].ddnsgeek.com
and (%(provider)s) was
(Dynu)

So the problem occurred in init.py and the problem looks to have been with the use of the --force option for some reason.

You could also try to run the command
ddns -d update-all
so that the --force option is missed out and see what response occurs. The --force command is to update the connection even if it is already updated but if your update is failing to occur then the ddns command should run without the --force command being used.