The dns-01 challenge is in staging and is ready for your client tests. The dns-01 challenge is an implementation of a DNS-only domain validation from the ACME spec. If you’ve ever added some bits to a domain’s DNS records for another CA’s domain validation, it works similarly. We had a previously busted version in staging for a bit, but this is the first version where we (the boulder development team for Let’s Encrypt) are pretty confident is correct. There will, of course, be another thread when production support occurs. We don’t have a date for that right now, but community testing of the DNS challenge will help speed it up. I’m pretty excited about this one and so is the rest of the team! DNS challenge has been a big request from a lot of folks here, some larger organizations that wanted to use Let’s Encrypt, and myself. We’re happy to be getting it out there. (Oh, and, as a reminder, the staging API is at https://acme-staging.api.letsencrypt.org and can be pointed to by the letsencrypt client with the --staging flag. Test your stuff there!)

The DNS challenge test is working for ACMESharp client lib as well now. The verification was happening a little too quick after the challenge submission, so I needed to introduce a slight artificial delay during the testing routines as well, but otherwise, works great. Thanks!

Actually one peculiar thing I’ve found – ACMESharp currently supports handling dns-01 and http-01 challenge types. If I test Identifier validation with either DNS or HTTP challenge, the test is fine, but if I test with both challenge types against the same Identifier – whichever one I try to submit second fails with a 400 error from the server: {"type":"urn:acme:error:malformed","detail":"Unable to update challenge :: Challenge data was corrupted","status":400} Can anyone else confirm this, and is this expected behavior? I understand that the overall status of the Identifier changes to valid, but the individual challenge is still pending so I would think it would allow to submit and verify that challenge, no?

just a question: what will be put in the DNS? some random stuff or the account key? also does it affect subdomains? it would be great if I could just post my acc key to the root and tell them that this account is allowed to do LE certs for this domain and subs.

@mjphaynes, since this is not in the official client yet…what client are you using to test, and how are you specifying that its a DNS challenge to the staging server?

Hello @ezeeetm, I don’t know what client is using @mjphaynes but seems that letsencrypt.sh client implements dns challenge, just in case you would like to test it. Cheers, sahsanu

Using letsencrypt.sh and a small hook script I was able to use dns-01 without issue. One question I have is what DNS sever is let’s encrypt hitting to get the TXT record? I’d like to verify the record shows up on that server before proceeding with the challenge. In testing I had to update the TXT record a few times and I initially used a TTL of 300, so there was a lot of old cached results floating around.

Let’s Encrypt does authoritative lookups (i.e. starting from root servers). You can simulate that with dig example.com +trace. Maximum TTL is limited to a few minutes on their end.

@jmhodges and others in this thread who have working dns-01 tools: For those of us who want to write a simple dns-01 client (or modify an existing acme client) to use dns-01 challenges, where can we see documentation about what the boulder API specifically for dns-01 challenges? Based on how the official client works for http, I assume we’d just create a TXT record whose name is the same as the.well-known/acme-challenge/ file name, and whose TXT value is the same as the contents of that file. Before working on a client it would be great to understand how the boulder API works under the hood. I looked in the Boulder repo, and all I could find is a high-level workflow design, and the api itself isn’t really self-documenting. Just curious if anybody has seen any good documentation or other resources that provide details about how the boulder API works: what it consumes, what it returns, and what to do with the response(s)? I would reverse engineer one of the projects in this thread that claims to have dns-01 support, but I’m a sysadmin not a software developer…so Go and .net are out of my reach. I want to do it in .py. I am looking at @sahsanu 's .sh client to see if that helps, but really any official/unofficial API docs for boulder would be most helpful. Thanks all. This is a fantastic feature of a fantastic project. I think most tools will end up using dns-01 and an API based DNS provider like route53 as opposed to filesystem/http-01 based auth.

Boulder is a server implementation of the ACME spec, which should describe what you’re looking for.

DNS challenge is in staging

Feature Requests

shred January 11, 2016, 10:37am 18

Tested and works with acme4j.

Topic		Replies	Views
DNS challenge failing: NXDOMAIN looking up TXT Issuance Tech	25	43162	August 15, 2016
Shouldn't verification via DNS record be a priority? Issuance Tech	61	41469	February 16, 2016
Letsencrypt doesn't verify dns-01 and leaves challenge in status: pending state Issuance Tech	16	6463	May 16, 2019
Error when requesting LE to validate DNS challenge Client dev	33	2210	November 2, 2020
[Suggestion] Let's Encrypt operated, TXT-only DNS Hosting for DNS challenges Feature Requests	18	9030	January 15, 2018

DNS challenge is in staging

Related topics