DNS01 validation timeouts

Hello, I work on DNS-based validation using dynamic DNS on top of the Crypt::LE Perl client (https://metacpan.org/pod/Crypt::LE). It more or less works, but so far I ran into two issues:

  1. after the first validation succeeds (be it with testing CA or live CA), the subsequent requests end up with “Received domain certificate, no validation required at this time.”. For how long the validation result remains valid? I would like to invalidate it in order to be able to test the DDNS records writing. The TTL of the TXT record itself was 300 seconds (further lowered to the 1 second), and the negative TTL in the SOA record of the DDNS zone was 60 seconds. I have been receiving this reply even for a hostname which I validated almost two days ago. The TXT record with the challenge itself has been NXDOMAIN in the authoritative DNS server for at least a day now, but the validation still succeeds.

  2. after writing the TXT record to dynamic DNS zone and trying to get the certificate, it fails immediately (in about two seconds) with “All verifications failed”. However, when I re-run the verification process (after about 30 seconds or so), I immediately get the certificate with “no validation required at this time”. So in fact the previous validation did succeed somehow. I tried to add a 5-second sleep after the TXT record has successfully been written to the DDNS zone, but it did not help. Then I added a 60-second sleep instead, and it helped - the validation succeeded and I got the certificate. Could it be that the LE DNS01 validator tries to lookup the _acme-challenge TXT record first, and caches the resulting NXDOMAIN for a while? I use a single authoritative DNS server for the DDNS zone, there are no secondaries.

FWIW, I don’t set the _acme-challenge TXT records directly, I use a separate DDNS domain _le.example.org, and have the CNAME records mapping the hosts’ _acme-challenge to this subdomain, in the following style:

_acme-challenge.host.example.org. IN CNAME host.example.org._le.example.org.

I then create the host.example.org._le.example.org TXT records with dynamic DNS update requests.

Are the validity periods and timeouts documented somewhere? Thanks,


1 Like

~30 days. Subject to change.

Yep, that’s what you should do.

If you create a new order and see that it has one or more authorizations which are already valid, post {"status":"deactivated"} to each of them, and then re-create the order.

This will get you a fresh order without any previous validation history state.


You may find that, when using the test CA, it is helpful to deactivate all of your authorizations at the end of a test run. This saves you having to re-create your order the next time around - and you already have all the authz URLs handy.

There is a ceiling TTL of 60 seconds on Let’s Encrypt’s recursors. If both your CNAME and TXT record have a 1 second TTL, you shouldn’t be having any trouble.

That said, I’m unsure about caching of NXDOMAIN responses. Does the problem still happen if you make a dummy/empty _acme-challenge TXT record a permanent fixture (so there’s never any negative response for the query)?

1 Like

OK, thanks for clarifying this.

I will have to find out how can I do this inside the Crypt::LE module.

Firstly, the 1 second TTL is only at the TXT record itself (and for negative responses in the DDNS zone in which the TXT record resides, _le.example.org). In the main zone example.org, the CNAME has 300 seconds TTL.

I have added a dummy TXT record for a new FQDN, but sill no change.
I tried to capture the port 53/udp packets at the router in front of my authoritative DNS server for _le.example.org. The positive outcome is that no queries are done for the FQDN I want to make a certificate for before I create the DDNS record (and sleep 60 finishes). After that, I see queries for _acme-challenge.host.example.org TXT (response has the CNAME in additional section), for the nameserver of _le.example.org SOA, and finally for the host.example.org._le.example.org TXT, all with correct responses. The latest one comes from two different servers.

So I don’t think cached NXDOMAIN is the problem here, as I don’t see any NXDOMAIN on the wire.

The negative thing is that it has failed for me even after sleep(60) now.

Thanks for any further hints what to look for.


1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.