os-ddclient

[dirtyfreebooter]

i know os-ddclient is intended to replace os-dyndns but currently os-ddclient support for servers is terrible. does not even support cloudflare, especially with tokens.

is this a known issue? and something that is planned to be resolved before removing os-dyndns? since using os-dyndns currently warns you in the UI about its pending removal

[marjohn56]

Nor does it support GoDaddy.

[The_Dave]

Yes, a few infos about the development plans of ddclient would be very welcome, I also rely on cloudflare implementation and in the current client the wildcart box seems not to be doing anything

[onedr0p]

Not a solution but maybe it's worth getting ddclient working on another system, spare Pi, desktop computer, or whatever until the team has the kinks worked out.

[marjohn56]

Hopefully Mimugmail will host dyndns on his repo as an alternative until ddclient supports at least what dyndns supports now.

[mimugmail]

I will ask Franco next week, if there are no concerns we can move it :)

[chemlud]

https://sourceforge.net/p/ddclient/wiki/protocols/#your-favorite-provider-here

Is this some kind of cheek?  :o

OK, the dyndns code is old and unmaintained, but kicking out 90% of people with dynamic IP and tunnels etc. is a little over the top imho...  ???

[dirtyfreebooter]

i would also note, even tho OPNsense seems to not display all the services supported by ddclient 3.9.1, like CloudFlare, ddclient 3.9.1 is itself almost 2 years old and doesn't support things like CloudFlare API tokens.. but that code has been committed to github, there just has not been a 3.9.2 or 3.10.0 released yet..

very unclear from ddclient side what their plan is, if any...

[almodovaris]

What about inadyn?

[lignicolos]

i would also note, even tho OPNsense seems to not display all the services supported by ddclient 3.9.1, like CloudFlare, ddclient 3.9.1 is itself almost 2 years old and doesn't support things like CloudFlare API tokens.. but that code has been committed to github, there just has not been a 3.9.2 or 3.10.0 released yet..

very unclear from ddclient side what their plan is, if any...

Based on the issue below on the ddclient GitHub, the project appears to be dying/dead due to a lack of time for the developers.

https://github.com/ddclient/ddclient/issues/380

[AdSchellevis]

I was doubting a bit about responding to the dyndns topic, but after years telling people in issues and pull-requests that
dyndns on our end is really unmaintained and dying of poor code quality, we where hoping a bit someone eventually would start an alternative plugin.

To ease the process we made a decision at the end of last year to start phasing out the legacy plugin.
We invested quite some time to make sure there is an easy to maintain starting point which uses ddclient and isn't
hard to extend within the boundaries of what ddclient has to offer (https://github.com/opnsense/plugins/tree/master/dns/ddclient).

Is ddclient perfect? probably not, are there better alternatives available we could consider? maybe.
I guess time will tell, for now we just choose the option most others seem to use, partially knowning these suffer
from the same type of issues as dyndns on our end (maintanance is problematic if people only care about adding features).

From a technical point of view requesting an address and calling an endpoint if it changed isn't very difficult, but
as it stands there isn't much drive for companies to invest time and money in this direction I guess.

When it turns out another service generally available would be a better fit, it likely is quite easy to replace ddclient in our plugin for something else, as the input is more or less fixed. It just has to be an isolated daemon which doesn't try to entangle with interface code in anyway.

Testing inadyn as suggested for example would be quite easy for anyone to try,  there is a port package available (https://github.com/opnsense/ports/tree/master/dns/inadyn).
When ddclient has development code which does offer support for requested features, it might also help to test their
new code and provide feedback.

In my humble opinion it won't help to move the unmaintained code somewhere else, in order to really improve the
situation there's probably more needed. For the next 6 months the legacy plugin will still be shipped, so there's still time.

Best regards,

Ad

[chemlud]

I was doubting a bit about responding to the dyndns topic, but after years telling people in issues and pull-requests that
dyndns on our end is really unmaintained and dying of poor code quality, we where hoping a bit someone eventually would start an alternative plugin.

To ease the process we made a decision at the end of last year to start phasing out the legacy plugin.
We invested quite some time to make sure there is an easy to maintain starting point which uses ddclient and isn't
hard to extend within the boundaries of what ddclient has to offer (https://github.com/opnsense/plugins/tree/master/dns/ddclient).

Is ddclient perfect? probably not, are there better alternatives available we could consider? maybe.
I guess time will tell, for now we just choose the option most others seem to use, partially knowning these suffer
from the same type of issues as dyndns on our end (maintanance is problematic if people only care about adding features).

From a technical point of view requesting an address and calling an endpoint if it changed isn't very difficult, but
as it stands there isn't much drive for companies to invest time and money in this direction I guess.

When it turns out another service generally available would be a better fit, it likely is quite easy to replace ddclient in our plugin for something else, as the input is more or less fixed. It just has to be an isolated daemon which doesn't try to entangle with interface code in anyway.

Testing inadyn as suggested for example would be quite easy for anyone to try,  there is a port package available (https://github.com/opnsense/ports/tree/master/dns/inadyn).
When ddclient has development code which does offer support for requested features, it might also help to test their
new code and provide feedback.

In my humble opinion it won't help to move the unmaintained code somewhere else, in order to really improve the
situation there's probably more needed. For the next 6 months the legacy plugin will still be shipped, so there's still time.

Best regards,

Ad

Hi and  many, many thanks for clarification.

I just want to add that I (as a dumb user, no coding experience, no nothing) find myself somewhere between a rock and a hard place. I need the feature (working with my dyndns services, as does the current plugin reliably) to make my tunnels work and if the new plugin does not offer a full replacement, my only option would be to stop updating opnsense completely, which is not a good option, obviously.

So I (and several other users with dynamic IPs but no capabilities to maintain software) are somewhere "falling off the plate", without good option to support a smooth transfer (except for finding new dyndns services that work with the new plugin, with all the pain in this project).

Overall, highly appreciated that another 6 months of time will be granted for the transition, looking forward to a stable, sustainable solution for the future of dyndns, but doubting that there is a lot that can be done by "normal" users. Open source lives from contribution, anyway, keep in mind not everybody can contribute...

;-)

[almodovaris]

If you want a cheap solution, but a really cheap router (e.g. a Linksys E3000 or Asus RT-N16). Install FreshTomato or DD-WRT, and attach it behind your firewall. And, bingo, inadyn is working out of the box with many standard services and a custom option, checking the external IP by itself. You don't have to use its WiFi. This is supposing you have IPv4.

Otherwise a NAS (Synology or QNAP) will do for both IPv4 and IPv6.

[marjohn56]

From what little research I have done, looking at the code and history of ddclient, I do not see much in the way of any active developemt going on there either, so it's a case if frying pan / fire where that is concerned. Inadyn appears to have more activity but again limited options compared to the current plugin.
I for one was unaware of the myriad issues with dyndns, probably because for most of the time I have been running Opnsense I have had static IP's'; now I have an ISP with dynamic IPs again I've having to use dynamic dns. Yes, there was a bug in it as far as Godaddy was concerned but that's now fixed and all is very good. Don't throw the baby out with the bathwater. dyndns doesn't look that hard to maintain when I was looking for the Godaddy bug. I was going to look at a way of integrating static leases from dhcpd with dyndns, meaning you would could update the DNS server for IPV6 clients, v4 clients are normally port forwarded but IPv6 clients are not. Some IPv6 clients do not lend themselves to adding a dynamic dns update client, hence my thought of adding it to dyndns... we'll see.

[Samwise]

The lack of support for some (major) dd servers is inconvenient to say the least.
But the lack of selectable listening interfaces is not workable.
The os-ddclient is sending the ip address of one of my VPN clients to my dd service. Rendering my dd completely useless. In the previous plugin I was able to select my WAN interface.

Hope I missed something, if so, can someone point me in the right direction?

Greetings,
Sam