Automating changes of TXT records in DNS
- Thread starter Alberto Pace
- Start date
mirceadamian
New Member
Just adding as well a "me too" need here.
mirceadamian
New Member
@sandy neal any chance we can ask the developers again when this will be done? It does not look to me a lot of work.
We've added a DYN endpoint for creating TXT records which can be used to validate letsencrypt certificates. The credentials to use are the same as for DYN updates. An example of the parameters that need to be passed:
I have created script for acme.sh that utilize the endpoint described by Brad C. above. It can also be used with the pfsense acme package. For obvoius reason there is no delete txt endpoint. You can find the script plugin here: https://github.com/blueslow/sslcertzoneedit
We've added a DYN endpoint for deleting TXT records. The credentials to use are the same as for DYN updates. An example of the parameters that need to be passed:
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.
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.
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.
The only timeout/ratelimit I see at the moment is a minimum 10s between same-name (wildcard cert) TXT record creation/deletion.
Last edited:
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.
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.