[Feature Request] DynDNS API can update subdomains

Feature Description:

Using the dynDNS API it is possible to update A and AAAA records of sub-domains, e.g. sub.main.dedyn.io.

One possible way to achieve this would be via the already existing hostname parameter in the API:

curl -u main.dedyn.io:<token> https://update.dedyn.io/?hostname=sub.main.dedyn.io

Context:

• according to this comment the current behavior does_not_ allow to do so
• according to this comment the required changes could be a relatively easy change.
• this feature request stems from the issue #411.

[nils-wisiol]

I’d love to see a way of changing subdomain records via the dyn interface!

Regarding the hostname query parameter, I’m not sure if this is a good way to introduce this: Currently, you can update the apex A/AAAA records of any domain (zone) in your account by setting the domain name as the username you use for authentication. So, if you have a domain example.dedyn.io and a.example.dedyn.io, then you can

curl -u example.dedyn.io:token https://update.dedyn.io/

and

curl -u a.example.dedyn.io:token https://update.dedyn.io/

and the correct domain will get updated.

However, if a.example.dedyn.io is not a separate domain (zone), but just ordinarily contained in example.dedyn.io, the second command would fail.

I think the username parameter should be extended to handle this case - instead of introducing an additional hostname query parameter, otherwise things could get really confusing.

[peterthomassen]

I think the username parameter should be extended to handle this case - instead of introducing an additional hostname query parameter, otherwise things could get really confusing.

I think that approach causes problems for authentication. We currently allow authentication via the username and password query parameters, and via basic auth (same parameters encoded there). We return an authentication failure if the username was given, but is not a domain of the user. (However, it is acceptable to set an empty username.)

If we now allow the username to be a domain prefixed with a subdomain, then authentication will fail (as of now). Two possible workarounds would be to a) ignore the username if it does not fit, b) attempt authentication as if the nearest existing ancestor of the domain given in the username was given instead.

Approach a) is bad, because if you have independent accounts a.dedyn.io and b.dedyn.io (with one domain each), and if you’re mixing up the password parameters (transmitting a.dedyn.io:token-b or b.dedyn.io:token-a), authentication will be entirely based on the token given as the password; the selection of the domain to update will be based on the same. It can thus happen that you think you’re updating a specific domain (and you get a successful return code), but in fact something else happened (and you can’t even tell what).

Approach b) is also somewhat weird, because one would have to traverse the DNS tree already at authentication time. Is that really what we should be doing? It looks very misplaced to me to have authentication.py call stuff from the Domain model.

If we went for the additional hostname parameter, we could require the username to be a domain name (or empty, as before), and do all the subdomain logic after authentication, at the piece of code where we actually process the update request itself.

This is also what the canonical update API specs say, and my guess is that ddclient uses it as well when specifying hosts (because they have separate parameters for login information), so we probably should support that, shouldn’t we? In other words, we wouldn’t really be introducing anything new.

Note interplay with #187 - if we ever implement that, we probably want a hostname parameter as well.