DNS challenge text records

The subdomain that @Osiris is using has to be on the Public Suffix List.

3 Likes

Ah, I see that it indeed is. I have not considered that earlier.

But even then it would be possible for OP to add example3.com to CF and use multiple subdomains from there.

2 Likes

So I thought I had it figured out.

First I simplified things by not trying to group my domains.

I have 2 domains and for the purpose of this post I have aliased them example1.com and example2.com

example1.com is the domain I want to get a certificate for,
example2.com is a domain that I setup with a third party DNS provider that has remote access, I used Cloudflare for that.

I had my ISP DNS provider create a text record on example1.com:
type: TXT
name: _acme-challenge.example1.com
content: "CNAME=example2.com"
ttl: 48 hrs. - I didn't specify this, it must be the default or something.

I have verified that the text record exists and the values are correct using tools like nslookup and the online MXtoolbox.
example1.com text = "_acme-challenge.example1.com=CNAME=example2.com"

Our acme client is something we created in house, we have successfully created certificates using http1 challenge.
We are attempting to add the dns1 challenge because not all of out systems are web servers.

From our client we are able to successfully add DNS text records to our third party DNS provide (Cloudflare), the record looks like this.
type: TXT
name: example1
content: [Challenge Token]
ttl: 1 min

I can also verify this record was created by using nslookup, MXToolbox, and the Cloudflare UI.

Unfortunately validation returns as invalid and inspecting the error object I see
"DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example1.com - check that a DNS record exists for this domain"

It seems the error is coming when Let's Encrypt queries my ISP DNS so it never gets the CNAME pointing to my third party DNS.
I thought I confirm this by looking at the analytics from my third party DNS but it doesn't seem to track TXT records.

Could the problem be the 48 hr. ttl on the text record?

That's not how you specify a CNAME resource record. It's a type of it own, not a specific form of TXT RR.

2 Likes

In addition to the problem described by Osiris, the name example1 is not involved at your example2.com in Cloudflare.

If your CNAME looks like:

_acme-challenge.example1.com CNAME example2.com

A DNS query should then see a TXT challenge record at Cloudflare like

example2.com TXT (token)

TTL will not affect Let's Encrypt as it queries the DNS directly. Various tools might be affected. Try using a query tool like https://unboundtest.com

3 Likes

When the TXT record on Cloudflare is created it's created as example1.example2.com but in the UI is shows as example1.com so I just used that in my example, my bad!

So the redirect needs to be a CNAME record and not a TXT record with the content CNAME example2.com?

I don't know where I picked up that it needed to be a TXT record.

Then you need to review how/why you entered that name. Because if your CNAME target is example2.com that is where the TXT record should be.

I realize you never setup a CNAME but it looked like you intended to set one up as I showed.

The examples I gave is how it looks with a tool like dig. The https://unboundtest.com is an excellent tool for this as it mimics LE in that it does not cache (so no TTL issues) and has same output format as I showed.

3 Likes