DynDNS Manage DNS API support?

[magicdude4eva]

Hi there,

are you aware if DynDNS is supported out of the box (i.e. https://help.dyn.com/dns-api-knowledge-base/) or should I just write a challenge provider?

[Neilpang]

you are welcomed to send your code.

[abelbeck]

@magicdude4eva Have you had any progress creating a dns_dyn.sh "dnsapi" script ?

[magicdude4eva]

Yes we did. It works perfectly fine for Synology. @Neilpang how should I share this - can I provide a Gist for you to review and then add?

[abelbeck]

@magicdude4eva I suspect a Pull Request would be the best method, but can you share via Gist in the near term for additional testing ?

[magicdude4eva]

Here is the Gist - we built the script running against our DynDNS enterprise account. Perhaps if @abelbeck could verify that this works.

On our dynect account we did the following:

• Lock down API IP ACLs (to our NATed outbound IP) - just to lock down who can access the API
• Create an API user with a password
• Assign zone-permissions for the domains you want to manage to the API user
• Assign "UserLogin" in Accounts & Permission
• Under "Zones & Records" we assigned: RecordAddAdd, RecordUpdate, RecordDelete, RecordGet, RecordBulkAdd, RecordBulkUpdate, ZoneAddNode, ZoneRemoveNode, ZonePublish

Note of caution: Scripting knowledge is super-limited so I am sure someone can improve aspects of this.

[abelbeck]

Thanks much for sharing. Looks good with a quick overview.

One issue, take a look at https://github.com/Neilpang/acme.sh/blob/master/dnsapi/dns_cf.sh as an example, and see how the credentials are _readaccountconf_mutable and _saveaccountconf_mutable when first export'ed by the user.

Also I think the script name of dns_dyn.sh might be better.

Thanks again !

[abelbeck]

@magicdude4eva I'm working on a "cleanup" of your script. Another issue is the non-portable -P option to grep.

[abelbeck]

@magicdude4eva Quick question, given ...

fulldomain="_acme-challenge.www.domain.com"

Will ZONE always be domain.com ? If so, we can calculate that from fulldomain instead of a configuration variable.

[Neilpang]

@abelbeck you should check from the api what the root domain is.

[magicdude4eva]

Thank you so much @abelbeck & @Neilpang for cleaning up the crude script I provided. The API documentation is here: https://help.dyn.com/dns-api-knowledge-base/

The ZONE will always be domain.com and you could derive the value in fulldomain from the ZONE.

[abelbeck]

@magicdude4eva and @Neilpang here is a completed dnsapi/dns_dyn.sh script for Dyn's Managed DNS API.

dns_dyn.sh.txt

I have tested it, issued a couple certificates, monitored the debug output, and it looks good to my eye. Check the script comments for usage details.

The script does require a recent version of acme.sh, I used v2.7.2.

Gerd, one thing I added was closing the session after use, I think that is important per the docs.

[magicdude4eva]

Awesome @abelbeck - this looks great. I am truly a sloppy hacker when it comes to scripts.

[Neilpang]

@abelbeck How to create a dyn account to test ?

[abelbeck]

@Neilpang The process to create a Dyn Managed DNS account to test is not as easy as it should be, this is what I did yesterday by trial and error ...

First, create a standard account, but don't add any zones there. https://account.dyn.com/entrance/

Then add the Managed DNS "Free 7-day trial" Products -> DNS -> Purchase & Pricing -> Developer "Free 7-day trial" http://dyn.com/dns/pricing/

You must give them a Credit Card in order to start the "Free 7-day trial".

It is confusing since it appears you can add Managed DNS from the standard account screen, but that did not work for me.

Finally, through all the emails you need to create a DynID to access the Managed DNS https://portal.dynect.net/login/ This requires a confirmation email to confirm.

Finally, once in the Managed DNS, add a zone to test and create a apiuser and password with the permissions in the dns_dyn script's comments.

It seems the Dyn Managed DNS is a powerful platform, but non-trivial to initially setup.

[abelbeck]

Pull Request #935 added.

After some white-space cleanup, the Linux travis test is still failing, but does not appear related to the PR.