If you run into the error “During secondary validation: Incorrect TXT record” for your DNS-01 validations, here’s some information that may help. The short version is: Your ACME client might need to wait longer between when it configures your DNS records and when it tells Let’s Encrypt to validate the result.
We recently launched multiple viewpoint validation to improve security. This may cause some DNS-01 configurations that previously failed a small portion of the time to fail a larger portion of the time.
When you add a TXT record at your DNS provider, it takes some time before your DNS provider has copied that record to all of their servers. Sometimes this can take a minute, sometimes 10 minutes, occasionally longer, depending on the provider. If your ACME client submits a validation request before the TXT record for the DNS-01 challenge is ready at all your DNS provider’s servers, Let’s Encrypt may get an NXDOMAIN response, which will cause validation to fail. It depends on whether Let’s Encrypt happens to hit one of the servers that already has the TXT record or not.
Now that we do multiple lookups, from multiple vantage points, it’s more likely that we’ll hit one of your DNS provider’s servers that hasn’t updated yet.
Unfortunately, most DNS providers don’t provide an API that lets you check whether all servers are updated (Route53 is a notable exception). Your ACME client just needs to sleep a fairly generous amount of time between adding the TXT record and requesting validation.
Some integrators query their DNS providers’ authoritative name servers to see when the TXT record is fully propagated. This may work in some cases, but it’s not reliable in the general case because of anycast. If your authoritative name server is, say,
198.51.100.12, and you query that IP address, your query might get routed to a different physical server depending on whether you are on the West Coast of the US, or northern Europe, or Asia. So getting a good response from your local
198.51.100.12 doesn’t mean that everyone in the world will see the same thing from their local
How long should your ACME client wait? It depends on your DNS provider. Certbot has some examples for various providers, with many defaulting to 30 seconds, and some going as high as 1200. If you’re using Certbot, you can adjust the wait time with
--dns-<plugin>-propagation-seconds (see the
--help all output for details).
One last note, on TTLs: TTLs are a different concept than the propagation time I describe above. Adjusting the TTL on your records affects how long recursive resolvers (like the ones Let’s Encrypt runs) can cache a result from your DNS. Our recursive resolvers are configured with a maximum TTL of 60 seconds, so it’s pretty rare to see issues that you could fix by adjusting your TTL. Also, the TTL for records that don’t yet exist is not a property of those records (they don’t exist yet), but is a property of the SOA record for your domain. Short version: adjusting TTL probably won’t help, but adjusting your client’s sleep time probably will.
PS: If you want to spend some extra time and effort, you may find that acme-dns fixes the above problem, and possibly other problems you may have with DNS validation.