Trouble with CNAME-record for _acme-challenge

Help
1

Further details at the bottom.

My domain is: catpictures.app.sky.test.nhn.no

I ran this command:
certbot --logs-dir /var/tmp/certbot --config-dir /var/tmp/certbot --work-dir /var/tmp/certbot certonly --manual --preferred-challenges dns --debug-challenges -d catpictures.app.sky.test.nhn.no --staging -v

It produced this output:

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: catpictures.app.sky.test.nhn.no
Type: unauthorized
Detail: No TXT record found at _acme-challenge.catpictures.app.sky.test.nhn.no

My web server is (include version): N/A

The operating system my web server runs on is (include version): N/A

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 2.5.0

This domain is delegated from my "main" DNS-server to a GSLB-solution, where I have a CNAME-record for
_acme-challenge.catpictures.app.sky.test.nhn.no
back to my "main" DNS-servers at
catpictures.app.sky.test.nhn.no.acme.nhn.no
where I create the TXT-records

I've experienced similar issues using cert-manager in a kubernetes-cluster, where cert-manager seems to follow the CNAME-record just fine and even verify that the TXT-record is created before the challenge is submitted to LetsEncrypt (and fails) - Something is preventing LetsEncrypt from following the CNAME, it just gives up after trying the TXT-record it seems?

2

I'm not sure your CNAME is set up correctly. E.g. see:

https://dnsviz.net/d/_acme-challenge.catpictures.app.sky.test.nhn.no/dnssec/

When requested for a TXT RR, it respons with NXDOMAIN. Only when asked for A/AAAA or CNAME, it actually responds with the CNAME.

Note that a hostname should NOT respond with an NXDOMAIN answer if the requested RR is not found, but another one exists.

3

catpictures.app.sky.test.nhn.no
DNS-servers at
catpictures.app.sky.test.nhn.no.acme.nhn.no

Something doesn't look right.
I see "nhn.no" twice in that last entry.

5

@Osiris you are spot on - For some reason I assumed that CNAME would be requested specifically and TXT requests were in fact configured to respond with a NXDOMAIN in my setup.
After re-configuring the DNS-server to respond with a CNAME response to a DNS request for a TXT record the challenges are properly resolved. Thank you!

@rg305 It is intentional, the CNAME is pointing to .acme.nhn.no and in this case the original FQDN is also under "nhn.no" - I agree it doesn't look pretty, though :slight_smile:

6

As said before, that's not correct according to DNS specs: if a specific RR is requested which does not exist, but the hostname itself does exist (but with a different RR), the DNS server should simply reply without an answer, but with status NOERROR. Not NXDOMAIN.

Although in the case for a CNAME, I think the DNS server should indeed respond with the CNAME answer as you've done now, regardless of which RR was requested. But never an NXDOMAIN (which was my point here).

What kind of DNS server are you running anyway, if this kind of manual tampering is necessary?