ddclient and deSEC

Started by JamesFrisch, July 09, 2024, 10:48:09 AM

Previous topic - Next topic
July 09, 2024, 10:48:09 AM Last Edit: July 09, 2024, 11:21:41 AM by JamesFrisch
Hi guys

I am currently looking into the deSEC implementation for ddclient.

I am unsure if the deSEC API handles stuff in a special way or if that is the norm and was just abstracted by the GUI for no-ip. Anyway, here is what is potentially special for deSEC:

If you update your A record it will delete your AAAA record.
Vice versa, the same is true.
deSEC also does not really want that you update first your IPv4 and then your IPv6,
they want it in one go. Which is possible in one URL.

Now the problem is that with the current implementation, this is not clear to the user and can have pretty drastic side effects. It took my quiet some time to realize that my A records or AAAA records just get deleted.

Since this is just a plugin, I am not really sure where to begin writing a bug report or something like that.
Should I do it here?
Or the github page of opnsense? If yes, under which repository?
On the github page of ddclient?
Or here in the forum?

From a GUI perspective, there are currently two options.
desec-v4 and desec-v6.

I personally don't see the reason why there are two different options.
Instead there should be only one option, just like for no-ip and all the other providers.

Best case, the GUI should offer you to

A: Use IPv4 to update the A record and warn you, that it will delete the AAAA record
B: Use IPv6 to update the AAAA record and warn you, that it will delete the A record
C: Update both




July 09, 2024, 12:59:12 PM #2 Last Edit: July 10, 2024, 10:29:06 AM by JamesFrisch
Reading into some Github comments from Peter@deSEC, the rational behind the deleting records is this: If you for whatever reason downgrade from dual stack to IPv4 only, you may be left with a broken AAAA record without you noticing. I get the idea, although I am not sure how realistic it is.

But even if I agree with him on the premise that his logic is more failsave, is there really a user that has dual stack but does not care if there is only an AAAA records? Because with his current logic, your connection will decide if you go for IPv4 or IPv6. A dual stack will always go with IPv6 and thous delete the A record.
But I would argue that the time is still not ripe for IPv6 only services.


I am not a programmer, here is what I came up with.

The GUI could look like this:


Enabled
Description
Service (deSEC)
Token
Hostname (no hostnames, since it does no allow for multiple updates)
Update mode
Check ip method
Interface to monitor
Check ip timeout
Force SSL (enabled by default)


For the new field Update mode, this should be a dropdown with the following options:


Update IPv4, delete IPv6
Update IPv4, preserve IPv6
Update IPv6, delete IPv4
Update IPv6, preserve IPv4
Update IPv6 and IPv4
automatic (IPv4 OR IPv6)


Here is what could should be issued in the background. Variables from OPNsense in <>


Update IPv4, delete IPv6:


curl --ipv4 "https://update.dedyn.io/?hostname=<hostname>&myipv4=<IPv4>" \
  --header "Authorization: Token <token>"


Update IPv4, preserve IPv6:

curl --ipv4 "https://update.dedyn.io/?hostname=<hostname>&myipv4=<IPv4>&myipv6=preserve" \
  --header "Authorization: Token <token>"




Update IPv6, delete IPv4:

curl "https://update6.dedyn.io/?hostname=<hostname>&myipv6=<IPv6>" \
  --header "Authorization: Token <token>"



Update IPv6, preserve IPv4:


curl "https://update6.dedyn.io/?hostname=<hostname>&myipv6=<IPv6>&myipv4=preserve" \
  --header "Authorization: Token <token>"


Update IPv6 and IPv4 option 1:

curl --user <hostname>:<token> \
  "https://update.dedyn.io/?myipv4=<IPv4>&myipv6=<IPv6>"


Update IPv6 and IPv4 option 2:

curl "https://update6.dedyn.io/?hostname=<hostname>&myipv4=<IPv4>&myipv6=<IPv6>" \
  --header "Authorization: Token <token>"



automatic option 1:

curl --user <hostname>:<token> https://update.dedyn.io/


automatic option 2:

curl https://update.dedyn.io/?hostname=<hostname> \
  --header "Authorization: Token <token>"









Hello,
I just came across exactly the same issue.
Is this something being worked on? Did you open a FR ticket for it?
The only workaround I see right now is to create separate hosts for v4 and v6 in deSEC.
I would really love to have ab option to update both A and AAAA record in one go.
Did someone try to implement this as custom?

thanks, Till
System1: Qotom Q310G4 (died recently)
System1: Supermicro A2SDi-4C-HLN4F,  64GB RAM, ZFS mirrored boot drive
System2: APU2C4

As far as I know it's the same situation as before.

But I would also like to see this one fixed!

The easiest fix would be to add "preserve" to both options, so you can individually update A and AAAA without deleting the other one.
I use the native backend, not sure if ddclient haves different
System1: Qotom Q310G4 (died recently)
System1: Supermicro A2SDi-4C-HLN4F,  64GB RAM, ZFS mirrored boot drive
System2: APU2C4

Hi guys and sorry for not updating this topic.

I first wanted to edit ddclient to make it more suitabel to work for deSEC and OPNsense but then soon came to the conclusion that ddclient is way 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.

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.
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

Quote from: skywalker007 on February 13, 2026, 05:18:32 PMThe easiest fix would be to add "preserve" to both options, so you can individually update A and AAAA without deleting the other one.
I use the native backend, not sure if ddclient haves different
@meyergru
This is the reason I can't use it at the moment. I need this (I'm behind CGNAT connection and use a VPS for the ipv4 connection)
If you only update AAAA at desec.io and use os-ddclient, A Record will be deleted.

There's a API command at desec.io for this (perserve A Record) but it's not implemented in os-ddclient / opnsense.

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.
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

I have just implemented it using the custom method which works well.
Documented here:
https://forum.opnsense.org/index.php?topic=50907.0
System1: Qotom Q310G4 (died recently)
System1: Supermicro A2SDi-4C-HLN4F,  64GB RAM, ZFS mirrored boot drive
System2: APU2C4

Quote from: meyergru on February 13, 2026, 10:56:38 PMAre 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.

Yeah, but not in a great way. See my response here: https://forum.opnsense.org/index.php?topic=50903.new#new

Quote from: skywalker007 on February 14, 2026, 11:15:56 AMI have just implemented it using the custom method which works well.
Documented here:
https://forum.opnsense.org/index.php?topic=50907.0

These workarounds are exactly what I mean and what my script handles better.

QuoteThese workarounds are exactly what I mean and what my script handles better.

Uh - I missed your post. I'll have a look at your script. Thanks!
System1: Qotom Q310G4 (died recently)
System1: Supermicro A2SDi-4C-HLN4F,  64GB RAM, ZFS mirrored boot drive
System2: APU2C4

Haha, this was more directed at @meyergru to explain why there is even a need for a better implementation, but sure, take a look.