DynDNS client for deSEC.io

[JamesFrisch]

Shameless plug for a little script I wrote.

I first wanted to edit ddclient to make it more suitable for working with deSEC and OPNsense, but soon came to the conclusion that ddclient is too big and bloated.

So I wrote a little script:
https://github.com/jameskimmel/deSEC_DynDNS

Hope you guys like it, give it a try.

[meyergru]

Are you aware that ddclient is on its way out as discussed here and that it has long be superseded by the native backend for os-ddclient?

This native backend already supports deSEC.

[JamesFrisch]

Yes I am aware.

However, there are some quirks and features specifically tuned to deSEC.io.
I don't deny that it is a one trick pony. Because of that it has some advantages.
Disclaimer: I have not taken a deep look at the updater logic of os-ddclient, so some things might also apply for os-ddclient

- deSEC is a none profit with limited resources. In the past the severs were overloaded, because everyone is doing their update at exactly every hour. My script adds a random delay of up to 5min, so not all come at the same time.

- My script uses deSEC DNS server. That might help prevent an unnecessary update request, when the DNS was updated but not yet propagated to something like akami.

- My script only issues an update request, when the IP actually has changed. Probably also to true for os-ddclient.

- My script makes use of the slightly special update logic form deSEC. There are multiple options for deSEC:

A: You don't specify an IP at all in the update request. That is the default and what os-ddclient is using. deSEC server will try to detect your IP. This will also overwrite all manual records done in the deSEC webGUI. Logic behind that is, that if you loose for whatever reason, you should also loose the DNS there. But of course this sometimes confuses users.

B: You specify a preserve option to not touch the corresponding IPv4 or IPv6

C: You detect the IPs yourself and hand them out in the update URL. This is what my script does. 


The current implementation of os-ddclient needs two update requests, one for IPv4 and one for IPv6, both with manually added preserve option to not delete each other. So out of the box, the current implementation is not even dual stack ready. My script does this in a more elegant way. Just one update request and handing out the previously detected IP(s) and depending on what the users goal is, with a preserve option in the update URL. Instead of making the deSEC servers detect it and leave them to decide.

Yes, I know that there is a specific problem - yet I think it would be better working towards a solution in OpnSense than to use external scripts.

I wrote my script because it not only works on OPNsense, but also on macOS / Linux / FreeBSD.
But I agree and a native OPNsense implementation would be even better. However there are some issues with that.

I don't know when I have the time and motivation to do this. I am also just a user and don't really know how to program (don't worry, I still did not use any AI for this).

So I am very happy for someone else to take up the work. Or if someone is willing to help me and nudge me in the right direction from time to time. This is what happened over at deSEC, one employee toke the time and helped and guided me through. But IMHO he would have been faster writing it himself :)

As a total amateur, to me it looks like there would need to be made some changes to the current implementation, to get what my script currently offers:

- adding deSEC as a check IP DNS server
- adding a secondary backup DNS server for check IP in the webGUI. Not sure how this is currently handled when a DNS server does not respond.
- adding a random delay between 1s and 5min (or a user max configurable number). Maybe that is not even needed, if the os-ddclient tool is currently not time based, but interface changes based? Don't know to be honest.
- complete overhaul the current desec-v4 and desec-v6 in the webGUI. This would be the big one *

* instead of differentiating between v4 and v6, we only need one called deSEC. That, and these checkbox options
- enableIPv4
- enableIPv6
- preserveIPv4
- preserveIPv6

the enable and preserve option are the same thing.
They are just there to make it nicer and simpler for the user. One user might think "I don't have IPv6 so no need to enable it" while the other user thinks "I have set a static IPv6 in the webGUI of deSEC, I don't want the updater to touch that so I want the preserve option".

From an update logic standpoint, they behave exactly the same.
But both options are just there to make sure there is no need to check said IP protocol and to not touch the deSEC webGUI records by using the preserve option.