Dynamic DNS with Dynu.com Not Working

fpolli · 26 January 2025 01:37

Hi, I have set up two domain names with dynu.com for dynamic dns. On the Dynamic DNS page in IPFire management, both domain names are red, and when I try to access either domain name from outside the network, the request times out.

the nginx web server is running and successfully serves to both domain names internally on the lan.
The IP address listed on dynu dot com is the same as the IP address on the “home” screen in my IPFire management and also on a whatismyip dot com request.
I ran a forced update all from the terminal that was successful for both names, and the most recent log entries are successful updates for both names.
I have firewall rules for 22/80/443 routing all of those to the web server machine. I tried to post a screenshot but it did not work.

Per another thread I tried “Guess the real public IP with help of an external server” and it made no change.

bonnietwin · 26 January 2025 11:39

Just for clarification, when you say both domain names do you mean the column labelled Service or the column labelled Hostname.

I am also using Dynu and my update is working fine.

As you can see the Hostname is green.

If the DDNS entry is disabled then the Hostname will be Blue.

If the Hostname is red then this is an indication that an update is required.

When you say that you ran a forced update and it was successful for both names, could you show the log information for this. If it was successful then the hostname should be in green. However the code does this by checking the IP address from your DDNS provider and comparing it with the one that IPFire has assigned to its red interface.

There was a previous post with this sort of problem
https://community.ipfire.org/t/dynu-update-stays-red-in-interface/13094
but their public IP address was not the one that their IPFire had. When they changed the setting to the one labelled “Guess the real public IP with help of an external server” then their dynu entry went immediately green but you already tried that and it didn’t work for you.

Only other thing I can think of is if you have any special characters in your password that are not being properly recognised by IPFire.

Beyond that I think we would need to see the DDNS logs to see what is happening.

bonnietwin · 26 January 2025 11:55

I just changed the IP address in my Dynu account and after a few minutes the entry on my DDNS WUI page went red

I then pressed the instant update button. The IP address was updated in my Dynu account and after a few minutes (for caching updates) the hostname went green again.

Checking the Dynamic DNS System Log entry there was now the single line

12:48:23 ddns[8557]: Dynamic DNS update for xxxxxxxx.ddnsgeek.com (Dynu) successful

Maybe you could try out the same thing and see at which step the cycle fails but first thing would be to check the Dynamic DNS System Logs to see if there is already some information about what is causing the problem.

fpolli · 26 January 2025 14:32

Thank you for your detailed feedback. I will try to address all of your questions and provide the information you need:

The Hostname column is red. I did read that other thread and he made the same mistake of lack of specificity. That’s where I knew to try “Guess the real public IP…”
Interestingly, both hostnames were originally green when I set it up, then at some point a little while later, they went red without me changing anything. The initial ddns log entry for these hostnames says: “17:44:18 ddns[24035]: Dynamic DNS update for mydomain1 (Dynu) successful”
Here are log excerpts in chronological order:

06:15:00 | ddns[20279]: | DDNSAuthenticationError: Authentication against the server has failed |

| - | - |
06:15:00 | ddns[20279]: | Last failure message: |
06:15:00 | ddns[20279]: | An update has not been performed because earlier updates failed for mydomain2 |
06:10:00 | ddns[19610]: | Further updates will be withheld until 2025-01-26 02:05:01.028268 |

Then a whole lot of repetitions of the same thing. Then this appears and now gets sprinkled in with the above for a whole lot of repetitions:

07:40:00 | ddns[26028]: | Dynamic DNS update for mydomain1 (Dynu) successful |

| - | - |

Then this happens:

14:35:14 | ddns[9024]: | Dynamic DNS update for mydomain1 (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/si te-packages/ddns/providers.py”, line 162, in call self.update() File " /usr/lib/python3.10/site-packages/ddns/providers.py", line 986, in update se lf.send_request(data) File “/usr/lib/python3.10/site-packages/ddns/providers.p y”, line 378, in send_request response = DDNSProvider.send_request(self, sel f.url, data=data, username=self.username, password=self.password) File “/usr/l ib/python3.10/site-packages/ddns/providers.py”, line 323, in send_request re turn self.core.system.send_request(*args, **kwargs) File “/usr/lib/python3.10/ site-packages/ddns/system.py”, line 167, in send_request resp = urllib.reque st.urlopen(req, timeout=timeout) File “/usr/lib/python3.10/urllib/request.py”, line 216, in urlopen return opener.open(ur |

| - | - |

and five minutes later:

14:40:00 | ddns[9206]: | Dynamic DNS update for mydomain1 (Dynu) successful |

| - | - |

And then the log just repeats this a whole lot of times:

14:45:00	ddns[9379]:	DDNSAuthenticationError: Authentication against the server has failed
14:45:00	ddns[9379]:	Last failure message:
14:45:00	ddns[9379]:	An update has not been performed because earlier updates failed for mydomain2
14:45:00	ddns[9379]:	Dynamic DNS update for mydomain1 (Dynu) successful
14:40:00	ddns[9206]:	Further updates will be withheld until 2025-01-26 02:05:01.028268

Then I logged into the ipfire machine command line and ran:

The output stated that both updates were successful, and the ddns log changes to this for a whole lot of repetitions:

16:53:16	ddns[15024]:	Dynamic DNS update for mydomain2 (Dynu) successful
16:53:16	ddns[15024]:	Dynamic DNS update for mydomain1 (Dynu) successful

The hostnames still appear red in the Hostname column of the Dynamic DNS screen of IPFire management. And I am unable to get any response from the server for either domain name from outside of my lan.

Then this appears in the ddns log:

23:35:16 | ddns[30127]: | Dynamic DNS update for mydomain2 (Dynu) threw an unhandled excep tion: Traceback (most recent call last): File “/usr/lib/python3.10/site-packag es/ddns/init.py”, line 178, in _update entry(force=force) File “/usr/l ib/python3.10/site-packages/ddns/providers.py”, line 162, in call self.u pdate() 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_r equest(self, self.url, data=data, username=self.username, password=self.password ) File “/usr/lib/python3.10/site-packages/ddns/providers.py”, line 323, in sen d_request return self.core.system.send_request(*args, **kwargs) File “/usr /lib/python3.10/site-packages/ddns/system.py”, line 167, in send_request res p = urllib.request.urlopen(req, timeout=timeout) File “/usr/lib/python3.10/url lib/request.py”, line 216, in urlopen retu |

| - | - |

As with the other one, five minutes later I get a successful update on mydomain2 and the log shows unbroken successes to the present. The hostnames are still red and I still cannot access the server from outside my lan.

Now, I will run your test and let’s see what happens…
I changed the ip for mydomain1 in dynu, then came back to IPFire and clicked “Instant Update”. The ip address in dynu went back to the correct ip and the IPFire ddns log says:

06:19:41 | ddns[13983]: | Dynamic DNS update for mydomain2 (Dynu) successful |

| - | - |
06:19:41 | ddns[13983]: | Dynamic DNS update for mydomain1 (Dynu) successful |

Because of the authentication errors and your comment about special characters in the password, I changed my dynu password, which did have an ^ and ! in it (not especially special special characters, but…)

I created an independent “IP Update” password in dynu then changed the IPFire settings for the two domains and ran an Instant Update. No changes. “Update successful” in the log but red hostnames and no response from server.

Incidentally, I tried browsing to my IP address directly and the request timed out, same as the domain names.

In case you are wondering why two domain names, one is for Nextcloud and the other is for a website.

I appreciate your time and effort.

bonnietwin · 26 January 2025 16:00

This is saying that there were some earlier problems with the authentication failing (maybe due to the special characters, maybe not) but due to that update failure a hold off time was applied by IPFire with updates not being attempted until 2025-01-26 02:05:01.028268

When you get those messages it is best to not try and force updates unless whatever is causing the authentication errors has been resolved because otherwise the hold off time is just extended out as you will get another authentication failure.

I will have a read through the whole log later on as I don’t have the time now and come back with any conclusions I reach.

One thing I noticed is that there are also some messages like

This indicates that there was a problem in the operation of the python code in IPFire. This should not happen. I don’t have these messages at all in my logs for my dynu DDNS.

It might again be related to the special characters in the password but that is just a guess. I need to get more time to look through the details of the unhandled exception and see at which stage in the ddns communication that occurred - it looks like it might be the stage at which username and password are dealt with.

I will also need to check the IPFire code to see if the special characters you used might cause a problem, although I would not expect ^ and ! to be a problem, and the code should be able to deal with it anyway.

The biggest issue is usually if a ,comma is used as a lot of the IPFire settings are saved in CSV style text files so the comma is the delimiter.

I will get back later today or tomorrow when I have had the opportunity to look through the logs in more detail.

bonnietwin · 27 January 2025 10:16

Looking through the log the initial messages show that you had an authentication problem with the update for mydomain2 but the update for mydomain1 was being executed successfully.

Then there was the unhandled exception which occurred at the update for mydomain1 which indicates that it tried to do an update and got an error message back from Dynu that is not defined anywhere in the IPFire ddns python code so it dropped to the unhandled exception code.

It was not due to a failure in the update or because of problems with the configuration file as those have defined error responses. There are also responses for a Network error or an Internal web server error.

5 minutes later mydomain1 was successfully updated. So something interrupted the update but none of the usual already existing error routines.

Menawhile the mydomain2 is continuing to not be updated due to the previous authentication failure. Those messages for mydomain2 will continue to be shown until 02:05 on 26th Jan 2025. Interspresed with them are the successful updates for mydomain1

Your latest log entries show both mydomain1 and mydomain2 having successful updates, so this is now after the authentication failure timeout has passed (after 02:05 26th Jan 2025.

Then there is the same unhandled exception as before but this time it is for mydomain 2. Same issue that an unknown error was received when trying to do the update.

So running the Instant Update did correct the IP’s in your Dynu account so the update process is occurring successfully (except for the occasional unknown error causing the exception handling but a later repeat works okay).

The only reason that the hostname would stay red then is that there is a mismatch between the IP provided to the DDNS account and the IP that is shown on your Main IPFire page.

In my case the IP is a private address, because that IPFire system is within my production IPFire network, so its red IP is on my production IPFire green subnet.

On that IPFire system, as it does not have a public IP on the red interface I have to have the Guess the real public IP with help of an external server checkbox checked and then press the Save button to store it. When I do that then the hostname turns green.

Can you confirm that on your IPFire system the IP on the Red Internet section of your main page is the same as the IP that is stored in the Dynu account for your hostnames.

If it is the same then the code should be making the hostname green.

If it is not the same then you have to check the Guess the real public IP with help of an external server checkbox but also then to press the Save button to enable and store the changed setting.

You can confirm that you have the correct setting saved by looking in the /var/ipfire/ddns/settings file in the console or via ssh.

If you have the The classical RED IP used by IPFire during connection checkbox checked then the settings file will contain

BEHINDROUTER=RED_IP

and if the Guess the real public IP with help of an external server checkbox is checked then the settings file will contain

BEHINDROUTER=FETCH_IP

fpolli · 27 January 2025 12:31

I can absolutely confirm that the ip address listed on my main IPFire page is exactly the same as the IP address listed on both domains at dynu. “Guess” is checked and the settings file shows BEHINDROUTER=FETCH_IP. So everything is correct but I have red hostnames and no reponses to external requests.

I don’t know what else to do. I looked into whether my ISP was interfering somehow but saw no indication that it is (and I had ddns working with a netgear router). I looked into the gateway that I use, but it does not interfere (it is a xfinity combo in bridge mode). So I am absolutely befuddled.

I appreciate your help.

bonnietwin · 27 January 2025 12:52

I am struggling a bit here as it should just be working and it is for me with the same provider.

I don’t believe that the special characters would be a problem as I have used a range of very weird characters in the past.

The only one that would create a problem is the comma but then you would not be able to have a successful update of the IP at the Dynu account.

Your xfinity combo being in bridge mode should also not create any problem.

With that in bridge mode then I would presume that the IP you have on the main page for the Internet red connection is a public IP.
So you could actually have the The classical RED IP used by IPFire during connection checkbox selected, although with a public IP both of those checkbox methods will work.

At the moment I have run out of ideas. Hopefully some other users will have some thoughts of things to check.

If something else comes to mind I will come back.

tphz · 27 January 2025 20:35

When you enter a password containing a comma:
A password containing a comma is not memorable.
Does not remember the checked box “Enabled:”

bonnietwin · 27 January 2025 21:13

Yes i already mentioned that a comma should mot be used because the various text files inIPFire are CSV files with the comma as the separater.

tphz · 28 January 2025 18:32

@fpolli
Can you compare the contents of the WUI “Dynamic DNS” page with the contents of the files

/var/ipfire/ddns/config
/var/ipfire/ddns/ddns.conf

fpolli · 29 January 2025 14:19

The WUI page:
The info all agrees. I wanted to do a screenshot but the MacBook screenshot utility had a heart attack over trying to take shot of an external display and refused to work. But trust me, the info all agrees.

config:
dynuDOTcom,domainname,net,username,randomcharacterstring,on
dynu.DOTcom,domain2name,com,username,randomcharacterstring,on

ddns.conf:
[config]
guess_external_ip = false

[domainnameDOTnet]
provider = dynuDOTcom
username = username
password = randomcharacterstring

[domain2nameDOTcom]
provider = dynuDOTcom
username = username
password = randomcharacterstring