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>"