Automating changes of TXT records in DNS

end

New Member
Adding another "me too" here. With everything else that ZoneEdit does so well, was somewhat disappointed to discover no simple API to get it working with Let's Encrypt certs.
 

schwie

New Member
Thanks for updating us, Sandy. I too am interested in seeing cerbot renewals work with ZoneEdit's API.
 

dornquast

New Member
Hi,

This project automates cert generation / renewal when zone edit is your provider. Argh, I'm not allowed to post a URL *sigh* .. Google this:

jeansergegagnon/zoneedit_letsencrypt
 

ewagner1

New Member
Thank you Brad. It works great. Is there also an endpoint to delete the txt record? The process is to add then after the process is complete, to delete the txt record.
 

Blueslow

New Member
I'm planning to use the acme.sh. Acme.sh have several dns methods for different sites. is any one of those methods capable to send the information according tho the format examplified by Brad C. above?
 

m.v.

New Member
Great!

There is still a little issue though.
My (wildcard) domain certificate requires two _acme-challenge TXT records to be created in the DNS.
No problem with that, just wait 5 minutes between the "txt-create" requests, because any faster will end in an ERROR 702 "Minimum 300 seconds between requests" issued by Zoneedit.
Then two requests to delete the TXT records will follow, as the records are no longer needed after verification.
Again there must 5 minutes between the last "txt-create" request and the first "txt-delete" request and between the first and second "txt-delete" requests.
And that is where the problem appears.
Meanwhile the certificate client (Crypt-LE version 0.38 for Let's Encrypt) is tired of waiting and issues a "Domain verification results for <domain-name> error. JWS has an invalid anti-replay nonce: <a random code>".

So here is the question: would it be possible to shorten the minimum time between requests, to say 60 or 120 seconds?

Of course I could try to skip and store the "txt-delete" requests and execute these after the certificate is created, but would be a less neat solution.
 

zef

New Member
I've noticed something odd with the delete endpoint. If you issue multiple deletions in quick succession (acme.sh's default behavior), not every one will get deleted despite always getting a return of <SUCCESS CODE="200" TEXT="_acme-challenge.testa.dom.tld TXT with rdata ... deleted" ZONE="dom.tld">. A 1 second wait after each appears to solve the issue. I'll make it 2 seconds to be safe, but of course it would be better if the API returned an error.

The only timeout/ratelimit I see at the moment is a minimum 10s between same-name (wildcard cert) TXT record creation/deletion.
 
Last edited:

zef

New Member
Few other things...

You get a SUCCESS even if the rdata doesn't match or host does not exist.

If these end-points are only meant to be used by ACME, perhaps they should only be able to create/delete TXT records with host names that start with _acme-challenge. There are other important things in there like DMARC/Domainkeys/SPF. In case of a compromised web server running ACME for example. Keeping the ACME client internal and pushing the cert out to servers would help reduce exposure.

<ERROR CODE="700" TEXT="Record of type 'A' already exists for the specified hostname" ZONE="www.dom.tld">

Not sure why these endpoints are even looking at the A records. Holdover from the original use for dynamic IP updates I guess.
 
Top