(Feature) Raise DynDNS rate limit to 2 requests per minute or per 2 minutes

[eomanis]

Currently, when a user updates their IPv4 and IPv6 address separately yet roughly at the same time, the second update request fails due to having a rate limit of 1 request per minute and domain.

While in the overwhelming majority of cases the IPv4 and IPv6 addresses change at the same time (think WAN reconnect) and then can both be updated with a single request, this may not always be the case in every situation.

Also, even when they change at the same time, there may be legitimate reasons why a user may run separate DynDNS clients for IPv4 and IPv6, possibly on different machines, which may often cause one of the clients to suffer a rate limit block.
See this forum thread for more in-depth reasoning.

Basically, IPv4 and IPv6 being entirely separate protocols, 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 the universal case should be accommodated for as well.

Edit

On further thought, raising the rate limit would just be a workaround.

The proper way going about this would be to apply rate limiting not per domain, but per domain and protocol, i.e. for the same domain an update request for IPv4 should not affect the rate limit for IPv6.
I don't know how hard implementing this would be though.

Also, handling combined requests needs some thought; for this a solution is needed that does not require communicating two results back to the user so we can still get away with an ordinary success/failure return.

Let's say IPv4 is currently rate limited, and someone sends an update request for both IPv4 and IPv6. What should happen in such a case? Possibilities:

1. API is lenient: Request goes through and is effective for all protocols if at least one protocol in it is not rate limited
2. API is strict: Request is denied because it contains an address for a rate limited protocol; if the user had sent a request with &ip=preserve instead of an actual IPv4 address the request would have gone through
3. API is lawful evil: Request goes through but is only effective for IPv6, leaving the user unaware of the fact that the IPv4 address wasn't set

[girlbossceo]

Just want to echo what was said above with my problem / use-case with this. 1 request per minute is very cumbersome when you have even just a few domains that require you to update each A record every 60 seconds. This is what I currently have to do to workaround this very aggressive API limit (I don't want to use a dynamic DNS client for minimalism):

ExecStart=/usr/bin/curl --tlsv1.3 --user kennel.girlcock.ceo:<redacted> 'https://update.dedyn.io/'
ExecStart=/bin/sleep 60
ExecStart=/usr/bin/curl --tlsv1.3 --user qbt.kennel.girlcock.ceo:<redacted> 'https://update.dedyn.io/'
ExecStart=/bin/sleep 60
ExecStart=/usr/bin/curl --tlsv1.3 --user cockpit.kennel.girlcock.ceo:<redacted> 'https://update.dedyn.io/'
ExecStart=/bin/sleep 60
ExecStart=/usr/bin/curl --tlsv1.3 --user synadm.kennel.girlcock.ceo:<redacted> 'https://update.dedyn.io/'
ExecStart=/bin/sleep 60
ExecStart=/usr/bin/curl --tlsv1.3 --user ytdl.kennel.girlcock.ceo:<redacted> 'https://update.dedyn.io/'
ExecStart=/bin/sleep 60
ExecStart=/usr/bin/curl --tlsv1.3 --user nextcloud.kennel.girlcock.ceo:<redacted> 'https://update.dedyn.io/'
ExecStart=/bin/sleep 60
ExecStart=/usr/bin/curl --tlsv1.3 --user vault.kennel.girlcock.ceo:<redacted> 'https://update.dedyn.io/'

Something like this feels very hacky for when I'm simply changing the IP for all of those domains to the exact same IP and protocol and record type, just with 60 second intervals in between each request.

[peterthomassen]

@girlbossceo, your use case smells like a perfect fit for CNAME records. Set *.kennel.girlcock.com CNAME kennel.girlcock.com, and you will only need to do the first update request. All subdomains will benefit from this single update.

This solution is cleaner, more efficient, less error-prone and wasteful, ... than updating all subdomains separately. It's not clear why we should devote resources in enabling the less clean, less efficient etc. solution.

For the record, I do have sympathy for some of the arguments in #806 (comment), and we will accept pull requests that implement per-domain+protocol rate limiting.

[girlbossceo]

@peterthomassen I'm personally not a fan of wildcard records, especially since my CAA record forbids wildcard issuance. Wildcard certificates require more care and security to prevent abuse in the event of a compromised server.

I could maybe do that just with individual subdomains pointing to the CNAME, but this still feels like it shouldn't be aggressively ratelimiting for the same IP and record type.

Nonetheless, I am at least glad to hear that this kind of feature is open for implementation, even if some use-cases could be optimised.

[peterthomassen]

I could maybe do that just with individual subdomains pointing to the CNAME

Yes, that's a good idea. The wildcard was mainly for illustration of the CNAME concept. Of course, explicit is better.