This is default behaviour for most DDNS update scripts.

If an update has failed for any reason they don't care about previously received error responses. None of them stores such details to align their further actions.

Stupid clients simply sends an update request when they get called. They don't care about if an update is required or not. Better clients (like DDNS is) will perform a check if the hostname points to the currently used IP address and avoid to send the update request.

It's also no good idea to stop update attempts after a handful of failed (badauth) messages. Just imagine the user backend of an DDNS provider is not reachable for some time. All incoming requests cannot be performed and a badauth response will be sent to the update client, which will stop updates for this hostname....


As the DDNS client is just a side project of IPFire we would accept a patch to expand the time between the update attempts in cases when the responses are "badauth". Only condition the client never fully stops to sent update attempts because of the reasons above.

I just showed you the standard, saying that most clients do it that way doesn't make the software compliant to the standard.

Here's another one:

http://www.noip.com/integrate/response (btw, you were somehow right with "success" for nochg, they also classify it that way), they say:

"""
The client should only schedule future updates when it receives a "Success" return code. Any "Error" return codes will require user intervention to correct the problem with their configuration.
"""

"auth server not reachable" and "user sent wrong credentials" should be easy to differentiate for any sane server software.  The first should be "911" (and it is a SERVER error), the second is "badauth" (and it is a CLIENT error) result code.

From the server side, I can tell you what might happen if a client / client software misbehaves (in general) frequently:
* increases client fault counter
* if counter goes beyond some threshold faults/timeunit:
  * the host/user might get flagged as abuser (and get disabled or removed)
  * the software (UA) might get blacklisted

In case of "badauth", there is a slight other problem btw.:

The server can not really know whether the request came from the legitimate owner of some specific host record (as there was no valid auth).

So a carefully designed server software can not flag that specific host as abuser.

So the only way left is to blacklist the useragent and that would be bad also, as it is global for all users of that updater.

(In reply to comment #2)
> I just showed you the standard, saying that most clients do it that way
> doesn't make the software compliant to the standard.
> 
> Here's another one:
> 
> http://www.noip.com/integrate/response (btw, you were somehow right with
> "success" for nochg, they also classify it that way), they say:
> 
> """
> The client should only schedule future updates when it receives a "Success"
> return code. Any "Error" return codes will require user intervention to
> correct the problem with their configuration.
> """

ddns does not repeat the updates if the records already point to the right IP addresses. It won't stop repeating updates when an error message is received.

This may not conform with the regulations of some dynamic DNS providers, but the most common clients don't do this either.

> "auth server not reachable" and "user sent wrong credentials" should be easy
> to differentiate for any sane server software.  The first should be "911"
> (and it is a SERVER error), the second is "badauth" (and it is a CLIENT
> error) result code.
> 
> From the server side, I can tell you what might happen if a client / client
> software misbehaves (in general) frequently:
> * increases client fault counter
> * if counter goes beyond some threshold faults/timeunit:
>   * the host/user might get flagged as abuser (and get disabled or removed)
>   * the software (UA) might get blacklisted

I am well aware of this. I think that Stefan pointed it out very well why we let our client behave like it does. We can think about reducing the number of tries, but we won't make the client stop trying.

> In case of "badauth", there is a slight other problem btw.:
> 
> The server can not really know whether the request came from the legitimate
> owner of some specific host record (as there was no valid auth).

I don't think that leaking legitimate hostnames does help in that case. Just a side note. See #10604 for reference.

> So a carefully designed server software can not flag that specific host as
> abuser.
> 
> So the only way left is to blacklist the useragent and that would be bad
> also, as it is global for all users of that updater.

If you want to block all user agents that behave exactly like ddns, you would probably need to block the vast majority of them.

Closing this now, as there is no response from the reporter.

We may or may not change the behaviour of ddns, but almost certainly not in the way as it is requested here.