Plugins: dns/dyndns custom service types: include current AAAA or A record in update URL

[maurice-w]

[X] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md

[X] I have searched the existing issues and I'm convinced that mine is new.

[X] When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe.
Some dyndns services with IPv6 and IPv4 support require that both addresses are always included in the update URL. If only the IPv6 address is provided, the A record will be deleted. If only the IPv4 address is provided, the AAAA record will be deleted. The OPNsense dyndns plugin currently does not allow using these services in a dual-stack scenario.

Describe the solution you'd like
When triggered, the dyndns plugin should first perform an nslookup for the configured _Hostname_ to learn its current AAAA and A records. This information could then be included in the update URL. I would like to be able to use parameters like %AAAA% / %A% for this.

For the service type "Custom", an update URL could look like this:
https://update.example.com/?myipv4=%IP%&myipv6=%AAAA%
And for "Custom (v6)":
https://update.example.com/?myipv4=%A%&myipv6=%IP%

Describe alternatives you've considered
The only alternative that comes to mind is using a dyndns service that allows updating the AAAA record without touching the A record (and vice versa). Unfortunately this is not universally supported.

[iNilsDE]

+1

[iNilsDE]

I would like to suggest an other alternative: Put the ipv4 and the ipv6 ip of the wan Interface to the update URL.
Like: https://update.example.com/?myipv4=%IP%&myipv6=%IPv6% .
Maybe in a new Service „Custom (v4/v6)“.

[Technikte]

Same problem over here, I need to update the v4 nad v6 ip at the same time or the missing record one will get deleted. A entry like @iNilsDE mentioned would be ok for me, no need for a preset like the other DDns services.

I use https://www.inwx.de/ with all my domains and an dyndns account.
The info is taken from the offical site.

DynDNS2-Protokoll
https://dyndns.inwx.com/nic/update?myip=<ipaddr>&myipv6=<ip6addr>

Thread at forums for reference.. https://forum.opnsense.org/index.php?topic=16948.0

[robberer]

Same situation with ddnss.de . Would be great if both address types (v4/v6) were available as a variable.

[Technikte]

Also found an other thread on opnsense forum with the same problem.
https://forum.opnsense.org/index.php?topic=15266.0

[Technikte]

Did anyone got a workaround for now ?
I have had a look at the code but I dont't think I can really help, sad :( . I think it needs to be changed to do curl parallel for ipv4 and ipv6 adresses and then a new entry like "Custom (v4+v6)" could be created in the code and so on..

@maurice-w I noticed, maybe the title should be "..include current AAAA and A record in update URL"

[AdSchellevis]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.

[Starkstromkonsument]

I observed that for "custom" entries the update server is contacted via IPv4 and for "custom (v6)" via IPv6. Is this the intended behaviour? The switch "Force IPv4 resolving" does not change this.

This is a Problem because some services (e.g. INWX) don't provide an update server with IPv6 connectivity. See https://forum.opnsense.org/index.php?topic=16948.msg82344#msg82344

[Starkstromkonsument]

@AdSchellevis I'm working on this. PR is already submitted. Can you reopen this issue and assign it to an owner please?

[Starkstromkonsument]

I just noticed there are 10 other open PRs related to dns/dyndns. Is there a chance of working on these in a bundle? There will probably be many merge conflicts.

[AdSchellevis]

@Starkstromkonsument the dyndns plugin is very old and practically unmaintained, it would need a rewrite, which isn't very high on our list of things todo (I'm not convinced it needs the current level of entanglement into the system either). Adding more glue often doesn't improve the situation and decreases the chances of a rewrite, but that's just my opinion.

If you want to cleanup the existing plugin, best keep it in the same PR in this case to avoid merge conflicts. Since I personally don't want to spend a lot of time on this, it would be good to gather some people who offer to test, maybe ask around on the forum to collect some.

When a couple of users can test the new code and vouch for it, I don't mind pulling in a larger batch to solve different issues, as long as you (or anyone else) promises to look at possible new issues that emerge after releasing it to the general public.

I can open this issue and assign it to you if you like, I don't think anyone else is interested in "owning" the issue currently.

[iNilsDE]

I‘m also interested in the PR of @Starkstromkonsument because I have the same problem with INWX. I could test the code and give you a feedback to push the release if you like.

[Starkstromkonsument]

@AdSchellevis thank you for your feedback. I would offer to start rewriting it, but I regret my skills and time are to limited for this at the moment.

I'll try to find some other users for helping and testing. If I find enough supporters, I'll be happy to take care of this issue and new bugs resulting out of the changes.