As there are typically two protocols whose addresses need to be maintained (IPv4 and IPv6), and which are independent from each other, it would be convenient to be able to burst up to 2 requests to the DynDNS update API instead of just a single one.
Possibly the rate could be raised to 2 requests per minute, or, if this rate is too high, 2 requests within a 2 minutes window.
Detailed reasoning and user story
I am using a dedyn.io subdomain with an IPv4+IPv6 true dual stack consumer VDSL connection with a forced reconnect every 24h, and have a daemon that maintains the DNS IPv4/A and IPv6/AAAA records.
As IPv4 and IPv6 are separate protocols the daemon handles them separately.
It sequentially checks and if required updates both the A and AAAA records, then goes to sleep for 2 minutes.
Every time the daemon wakes up from sleep, it determines the current public IPv4 address, and resolves the IPv4 address of the dedyn.io subdomain. If the subdomain’s DNS A record differs from the public IPv4 address, an IPv4/A record update request is dispatched to update.dedyn.io. Since the IPv6/AAAA record should remain as-is the update request contains &ipv6=preserve.
Directly after that it does the same thing for the IPv6 address / AAAA record, with &ip=preserve in the update request.
Then it goes to sleep again.
While IPv4 and IPv6 are separate on a technical level they nonetheless usually change at roughly the same time, which is when the reconnect happens.
This causes the daemon to dispatch two update requests in quick succession, one for IPv4 and one for IPv6, and due to having a rate limit of 1 request per minute and domain the 2nd request errors out.
The problem fixes itself after 2 minutes of course, however it kind of looks ugly in the log, and there is an additional 2 minutes downtime for IPv6 connectivity.
I’m not fully clear why your use case would require a modification to deSEC’s services, as opposed to modifying your daemon such that only one request is sent to deal with both updates. (This is how thousands of domains get updated.)
The main problem with allowing two separate update requests in quick succession is that people will almost inevitably run into some sort of race condition. (Of course, that doesn’t apply to your case, but experience shows that misconfigured clients will send 2 requests for IPv4 only, for example. In fact, this is the case today, and the second request is rejected for rate limiting – with your proposal, we’d have to deal with the implications of this concurrency.)
In any case, feel free to open a feature request issue on GitHub for this, so that we can track it there. If other people show thumbs up etc., we might consider doing this change.
Having the daemon structured like this makes for cleaner and more straightforward code with fewer conditionals and such, and allows it to quite easily support other DynDNS services that have separate update URLs for IPv4 and IPv6, such as the FreeDNS update protocol version 2.
Then there is the matter of having an IPv4 connection with Network Address Translation, and IPv6 connectivity without NAT, which is a common setup at least in Germany.
A user may be inclined to have the WAN router itself handle the IPv4 update request since it is the router’s IPv4 address that must be set, while having the server behind the router make the IPv6 update request because the server’s IPv6 address needs to be set and the router may not know which IPv6 that is.
Such a fundamentally sensible setup will likely run into the rate limiting with some regularity.
Basically I argue that updating the IPv4 and IPv6 records in one request is an optimization for an – admittedly very common – special case, and doing separate updates is the general/universal case, and this general case should be accommodated for.