Support for Dynu v2 API

[cross]

I think dynu.com no longer supports a simple access method. Their REST API is documented at https://www.dynu.com/Support/API. I am planing to copy cloudflare/porkbun plugins into a new dynu plugin.

Starting this discussion thread so I can write questions and get opinions from core maintainers. Thanks.

[cross]

First question is, dynu has a "give me all of my domains" API, and a "get me the domain that hostname FOO is in". Using the latter with the specified hostname would be the easiest way to get the domain ID, needed for most calls. This would fail if the hostname didn't already exist. So, it seems less "correct". More correct to get all of the domains and match for the given domain name (given as with cloud flare zone in the username field), but that's a bunch more code (and doesn't match existing code, so more work)

Opinions welcome, and any pointers to code that I haven't noticed yet that will search JSON responses for matching objects, rather than a single matching string.

[cross]

Alright. I think I've talked myself down from the "I must parse through the domains array." It occurred to me that the actual domain name itself is almost certainly (maybe even guaranteed?) to be a "host" record inside of the domain. So I will query for that to get the domain id. Leaving this here just for posterity and possible comment.

[acolomb]

Are you sure that we actually need to do anything more complicated than what the plugin does now? I'd need to check if all is still working, but at least in my setups, I haven't noticed any changes / failures lately. The "old" API still works perfectly, which is much simpler and basically modeled after the original DynDNS API: https://www.dynu.com/en-US/DynamicDNS/IP-Update-Protocol

Where did you get the impression that it no longer works?

[cross]

Yeah, I've been thinking about that too. It no longer worked for me. It's been a few years, and I see a bunch of text on their site that suggests something was now unsupported. But, I have been talking to their support folks about the "old" API, which is still documented, and they have finally gotten me enough info to make it work. At least by hand with curl. I was going to go back to seeing if the dyndns plugin would work.
One thing I've found talking to their support is that creating new hosts is not possible with the old API. And whether or not updating IPv6 addresses works is unclear, it sounds from what they say that it [probably?] works but doesn't report that it works.

Anyway. Thanks aclomob for the feedback, do let me know if you find it is still working. And are you using "hostname" or "alias" parameters? (The old API only accepts "alias" parameters for hostnames, it's weird, but I think I know the details of it). I am setting half a dozen hostnames anytime I update my address, so figuring out which syntax to use is something I haven't figured out in inadyn yet. I just yesterday got so I could make the updates with curl by hand and see any success.

[cross]

I don't see how it could be done without a new config option. Of course, we could just make a new provider plugin "dynu.com-alias" that simply splits each given hostname at the first dot, then puts the two parts into the alias and hostname URL fields, respectively. [...]

At this point, we're back to talking about a new plugin, which is where I started. :-) I would argue against duplicating the Dyn protocol plugin into something else specific for the Dynu variant that has an "alias" parameter. Unless there is more than one provider that does this with their equivalent to /nic/update. If a new plugin is warranted, and dynu.com only, I think using the REST API they suggest is the better plan. But not a question to answer now. For now let's stay focused on "does the existing dyndns plugin work for dynu.com, and in which use cases?"

[acolomb]

It works. Even the generic (custom provider) plugin works. To make use of their alias feature, the custom provider and some tricks regarding the settings are needed.

I don't see how implementing a whole new API should be better than just some string splitting and putting that into a new request URL template. And that's not just judging the time to get a working implementation, but rather the effort needed to maintain it in the future, besides the API that's used by probably > 90 % of the available providers in Inadyn. If adding to the dyndns plugin is the most effective way, then let's do that and have all other providers simply not use the extra feature.

[cross]

I'm still not sure you can say that the dyndns plugin works for dynu.com. There are at least use cases where it cannot work. I was just saying that using the REST API would be preferable to making a whole separate copy of the dyndns plugin just for Dynu. I agree with you that if we can make the dyndns plugin support dynu more fully, that is a better option.

[acolomb]

Do you realize that it's not really about a "whole separate copy of the dyndns plugin", but most of the functionality can be reused? Have a look at https://github.com/troglobit/inadyn/blob/master/plugins/all-inkl.c for example, it basically just adapts to some different parameter names in the URL string template. Everything else is still handled by the common code from the dyndns plugin.

[cross]

Following up on this, I have learned more about the use cases and API parameters from qdm12/ddns-updater#385. So, as it is, a custom config is needed when you're updating dynu for anything inside of the given domain they're providing. It is not possible, with the existing dyndns implementation for dynu, to set underlying host address records. I still mostly feel that this means the dynu support in dyndns is not working. It fails for a common use case. It works for another common use case, but not mine.
I still think that using a more complete recommended API is the better solution, but accept that you do not, and sortof understand your reasons. (reasons notwithstanding, I agree your decisions are the more important ones. :-) )
I will see if I can make a simplistic implementation around dyndns/generic. I do not understand from a quick look at all-inkl host to do that, but I will ponder it more.

[cross]

So for @troglobit (and anyone else who makes such decisions), it seems to me that the existing dyndns doesn't work well enough for dynu. Even if adding records isn't needed, I presume wanting to set more than one hostname, and hostnames inside the domain level, is something you/we want to support.
If I removed the dynu lines from dyndns code, and added a new REST API plugin, would that be a PR you'd accept?
I'd also refactor the common code out that is shared between cloudflare and porkbun, which three plugins would now use.

[acolomb]

Please don't remove the dyndns based support for Dynu. It has the big advantage that the API is so widespread that it doesn't really evolve anymore. Just some proprietary extensions here and there, like the alias function.

Any REST API is in my experience more complex and often a moving target, where new versions come and old ones are deprecated at some point. I'd be happy to see native support for it in inadyn, but will you also be there to keep it updated for the foreseeable future?

I actually am using Dynu successfully with inadyn, even with aliases. But I put a custom provider config section in the file instead of specifying dynu.com as provider. That works fine with the alias extension, you just need to put the alias and zone in the URL directly, while keeping the hostname field with both concatenated (so the DNS lookup works properly).

[troglobit]

Please don't remove the dyndns based support for Dynu. It has the big advantage that the API is so widespread that it doesn't really evolve anymore. Just some proprietary extensions here and there, like the alias function.

Any REST API is in my experience more complex and often a moving target, where new versions come and old ones are deprecated at some point. I'd be happy to see native support for it in inadyn, but will you also be there to keep it updated for the foreseeable future?

+1 on all of the above! Thank you @acolomb 🙏

[cross]

Following up here, I'm trying to make a config that works for my with dynu.com. While doing this, I notice that I get successful response to the /nic/update URI regardless of whether it's really successful. Is this just me?
For example:

cross@router: curl -X GET --basic -u bob@goo.com  "https://api.dynu.com/nic/update?hostname=foo.com&alias=bobcat&myip=192.118.45.123"
Enter host password for user 'bob@goo.com':
good 192.118.45.123%
cross@router: 

No valid account, no valid password, reports success. I've no idea why this is true, since I know I was getting "badauth" responses with this sort of manual request weeks ago. But, this makes it hard for me to test whether a config works, since everything reports success.

[troglobit]

Following up here, I'm trying to make a config that works for my with dynu.com. While doing this, I notice that I get successful response to the /nic/update URI regardless of whether it's really successful. Is this just me?

For example:

cross@router: curl -X GET --basic -u bob@goo.com  "https://api.dynu.com/nic/update?hostname=foo.com&alias=bobcat&myip=192.118.45.123"

Enter host password for user 'bob@goo.com':

good 192.118.45.123%

cross@router: 

No valid account, no valid password, reports success. I've no idea why this is true, since I know I was getting "badauth" responses with this sort of manual request weeks ago. But, this makes it hard for me to test whether a config works, since everything reports success.

This sounds more like a question for Dynu rather than us, right?

[cross]

Yeah, I've asked them. Sorry. Lots of testing going on, hard to figure out what does and doesn't work.

[cross]

Thank you for your feedback. I'll abandon my REST API code then. Thank you @acolomb for your help in getting the custom config working for my needs.