Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dreamhost DNS API scripts. #867

Open
briantmeyer opened this issue Jan 7, 2025 · 0 comments
Open

Dreamhost DNS API scripts. #867

briantmeyer opened this issue Jan 7, 2025 · 0 comments

Comments

@briantmeyer
Copy link

briantmeyer commented Jan 7, 2025

Just got everything working with GetSSL via the dreamhost API which is really simple as is. Thank you, this project really helps automate things.

These are the bash files I used to get things working with dreamhost, if you want to use them for integrating with Dreamhost, this should follow their complete API, they probably need cleaning up, but should work as is. I wasn't going to share, since their api is so simple, but it actually took a lot of work to get it so it actually works in practice, since its hard to reliably know the DNS is updated.

diverge_dreamhost_api.zip

I did rejigger them a bit so they are stand alone ( so they don't need my other larger libraries ), and did some easy quick adjustments to fit your guidelines.

It worked fine at first, but then I realized the authoritative DNS responses would vary up to an hour after setting the TXT record, even though the TTL is set to 5 minutes.

I was checking 3 times on the 3 servers, If I remember the actual record was set to the shorter string ending with TEXT here, but the issue is which shows up is random, and if its not the right one, it errors out on validation.

dig +noidnout TXT _acme-challenge.divergeisay.com @ns1.dreamhost.com
TESTXXXXXXx4QQXjBHPGR8hJYEJ6BNP1LFe6lIuEiPTnkENDTEST20250106055415
TESTXXXXXXx4QQXjBHPGR8hJYEJ6BNP1LFe6lIuEiPTnkENDTEST20250106055415
TESTXXXXXXx4QQXjBHPGR8hJYEJ6BNP1LFe6lIuEiPTnkENDTEST
with dig TXT _acme-challenge.divergeisay.com @ns1.dreamhost.com
TESTXXXXXXx4QQXjBHPGR8hJYEJ6BNP1LFe6lIuEiPTnkENDTEST20250106055415
TESTXXXXXXx4QQXjBHPGR8hJYEJ6BNP1LFe6lIuEiPTnkENDTEST
TESTXXXXXXx4QQXjBHPGR8hJYEJ6BNP1LFe6lIuEiPTnkENDTEST20250106055415
host -t txt _acme-challenge.divergeisay.com ns1.dreamhost.com
TESTXXXXXXx4QQXjBHPGR8hJYEJ6BNP1LFe6lIuEiPTnkENDTEST20250106055415
TESTXXXXXXx4QQXjBHPGR8hJYEJ6BNP1LFe6lIuEiPTnkENDTEST
TESTXXXXXXx4QQXjBHPGR8hJYEJ6BNP1LFe6lIuEiPTnkENDTEST

Now adding +trace to dig always gave the correct response, but so did the direct API call, and I really wanted to test as closely to the command used by letsencrypt to validate things.

So letsencrypt would do the DNS check and it would reject it, saying it was some value from a few hours ago consistently, it just would not update. After much testing it seems to take from 10 minutes to an hour and a half before it settles down to where it always gives the correct response. And on my SSH session it would drop prior on the server, when I set your timeout to wait extended periods, so I just want to wait until it is fully set on the DNS at dreamhost, no longer, so this ensures that this waits until its sure its the actual value.

In googling the issue I noticed others had the same problem, which mostly seemed to me that they have a lot of servers caching DNS records hidden behind those 3 urls, so it just can take a long time for them to settle if things are busy there.

So the real work was writing code to wait about 10 minutes ( I think double the TTL is important ), then check all 3 of the name servers they use, if I check 10 times in a row and they all match the expected result, then I know it will work. If not it waits 5 minutes to check again. I added loops that echo periods just so I can tell if it freezes as well. The total time when I got my domain working was 37 minutes. It seems like the initial wait of 10 minutes made it work right away at about 11 minutes, checking prior might make it take a LOT longer, but it is really random.

This seems to work, but I've not done extensive testing, and it might need to validate more than 10 times, or less. Also because its keeping the screen busy, it seems to not kick me out of my ssh terminal session.

I was thinking if there is an error, then doing a pause, letting the user enter the values manually, might be an option, so a hybrid manual mode.

I did some adjustments to fit your guidelines, such as double spaced indents and naming functions, but my code is not following all the guidelines, but this is working, and hopefully what I have is easy to read as is. I am not setup to use git at the moment, so can't really do a pull request now, will look at that in the future.

I am not sure on the best way to download for the API calls which are simple get requests. I just picked one that worked with the curl I saw in your code, and went with it, I can see getssl has more robust testing of the users system, but I didn't want to just use that without understanding what you are doing. Also the dig and nslookups don't seem like the tool used matters, but you have extensive code in getssl for figuring out what to use to check things.

Also rawurlencode was just something I found in a discussion online, it probably isn't needed here since the tokens aren't needing encoding I don't think, but I'd rather validate than not, probably needs to use a more robust library via other langauges (PERL and php), or a call to some command in the OS. Thinking this is mostly if I want to use the Dreamhost API for other things, and it did seem to make it easy since the timestamps I used for testing seemed to need encoding.

I wrote this on a newer mac, running Sonoma, which has a very very old version of bash (3.2.57), and also tested on Amazon Linux 2023, but most of the command line environment ( like curl,wget ) I installed myself from source, so my environment isn't really hitting the mac provided commands that much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant