deSEC adding unstable AAAA records when receiving IPv4 only updates from dual stack clients running dyndns2

The Problem:

I have multiple dual stack machines that are DDNS clients. The DDNS clients are using the dyndns or dyndns2 protocols.

On all of the clients they are sending update requests that only have IPv4 addresses specified but deSEC is also adding a AAAA record for the IPv6 address it received the request from.

This AAAA record contains a temporary IPv6 address which then expires when the client releases it but the record remains. The DDNS client does not detect the IP change on IPv6 because it did not send a IPv6 address in its original update request so it does not submit a new update request.

At this point there is a AAAA record that is not pointing to the client which then causes intermittent DNS issues for any user who is dual stack and no connection for any user who is IPv6 only.

My setup:

Names are changed for privacy reasons.

I recently migrated from google domains to CloudFlare and needed to migrate my DDNS clients over.

I currently have a domain example.com with the following records in my zone file

DNSKEY example.com <content from deSEC>
DS ddns.example.com <content from deSEC>
NS ddns.example.com ns2.desec.org
NS ddns.example.com ns1.desec.io

My DDNS records do resolve correctly to the records managed by deSEC. DNSSEC is also currently working.

I have 4 clients at this time at 3 sites

My sites are named Denmark, England, and Iceland. They are all physically in the US. All 3 sites are dual stack.

My hosts are:

iceland0.ddns.example.com - Ubiquiti UDM (Router) acting as the gateway for Iceland that is running the Ubiquiti DDNS client using the dyndns protocol. This is also running a Unifi Voice for my parents phone system that is hooked up to a SIP trunk. The SIP trunk requires a static IP or a DDNS endpoint for my parents to receive calls.

denmark0.ddns.example.com - Ubiquiti UDM (Router) acting as the gateway for Denmark that is running the Ubiquiti DDNS client using the dyndns protocol. This is used in this setup to test possible config changes for iceland0.

denmark1.ddns.example.com - Windows 10 PC that is used to host game servers and used as my primary computer. This is running DDCLIENT for Windows (See link below using the dyndns2 protocol). This is located in Denmark.

england.ddns.example.com - Windows 10 PC that is used to host game servers and a web server. This is running DDCLIENT for Windows (See link below) using the dyndns2 protocol. This is located in England.

All hosts work correctly except that a AAAA record is created for them that was not requested by the client. Each host has its own key.

When the temporary IPv6 address that the AAAA record is pointing to is released the clients

Having both a A record and a AAAA record is ideal until the IPv6 address expires and the client does not update the AAAA record. This bad AAAA record is what causes my main issue.

My Goal:

I would like to have ALL records in deSEC be kept up to date with my DDNS clients and any records that the DDNS clients are not managing not be present. This would mean my users on IPv4 will connect the same way they did when I was using Google DNS and my users on IPv6 only will use NAT64 to connect to me on IPv6 which is the same as what happened on Google DNS.

Option A - Change DDNS clients

What would be ideal is if I could use a DDNS client that is aware of IPv6 and can monitor both addresses. The problem is the Ubiquiti DDNS client does not look to support IPv6 and the latest DDCLIENT for Windows does not support the IPv6 tags that the newer version of DDCLIENT support.

If I can find a DDNS client that can run on Windows that does support deSEC I can use that for my Windows hosts. I am open to recommendations for a DDNS client for Windows.

I do not think it is possible for me to update the DDNS clients on my Ubiquiti UDMs without doing major modifications to the devices that will break in the next update. Also one of my UDMs is running a critical application (My parrents phones) so I want to make sure what ever is done to that UDM is stable.

Option B - Change deSEC DNS API

Right now the deSEC DNS API (See link below) looks to automatically creating a record for the address of the device that is sending the request. If my client sends a update request via IPv6 that contains a IPv4 address it will create a AAAA record automatically. This AAAA record being automatically created causes issues a few hours later.

All of my clients are preferring IPv6 which is triggering this issue.

My proposed change would be is if the parameters myipv4 or myipv6 are present in the request do not create a record for the device the initiated the request.

This would make it so if a DDNS client that is running on a dual stack host but is not IPv6 aware sends a update request a AAAA record will not be created. Clients that are IPv6 aware will be unaffected if they are also IPv4 aware. Clients that do not send addresses will be unaffected as the endpoint behavior for them is unchanged.

Conclusion:

I am not sure if I am approaching this problem correctly so I am open to any advice. Thank you for reading this wall of text.

Links:

DDCLIENT for Windows: https://www.randomnoun.com/wp/2013/08/19/a-dynamic-dns-client-for-windows/

deSEC API doc: IP Update API — deSEC DNS API documentation

I opened this ticket on GitHub Change Update API to not add record for client_ip if ip(s) are passed as query_params · Issue #915 · desec-io/desec-stack · GitHub

Turns out the API is working correctly and the docs are murky for this case. After looking at the source they make sense to me but I was originally incorrect. This means Option B is off the table.

For Option A I did receive some valuable assistance.

For my Ubiquiti devices I needed to set my server to update.dedyn.io/?myipv4=%i&myipv6= to force it to send a empty myipv6 query parameter. This works to prevent the creation of a AAAA record.

For my Windows devices I am currently searching for solutions and will appreciate any DDNS client recommendations.