DNS problem: SERVFAIL looking up CAA

Help
1

Both say everything is:
https://dnssec-analyzer.verisignlabs.com/hnusnik.cz
https://dnsviz.net/d/hnusnik.cz/dnssec/

My domain is: hnusnik.cz

I ran this command: letsencrypt certonly --webroot -w -d hnusnik.cz -d www.hnusnik.cz

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for hnusnik.cz
http-01 challenge for www.hnusnik.cz
Using the webroot path /srv/vhosts/hnusnik.cz/public_html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.hnusnik.cz (http-01): urn:acme:error:dns :: DNS problem: SERVFAIL looking up CAA for www.hnusnik.cz - the domain's nameservers may be malfunctioning

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: www.hnusnik.cz
   Type:   None
   Detail: DNS problem: SERVFAIL looking up CAA for www.hnusnik.cz -
   the domain's nameservers may be malfunctioning

My web server is (include version): nginx/1.6.2

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

Distributor ID: Debian
Description: Debian GNU/Linux 8.11 (jessie)
Release: 8.11
Codename: jessie

My hosting provider, if applicable, is: self-hosted

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 0.10.2

2

That really should be updated.
[maybe nothing to do with your problem - but just saying]

3

Hi @exander77

checking your domain you have a curious name server answer - https://check-your-website.server-daten.de/?q=hnusnik.cz

RRSIG Type 47, expiration 2020-05-01 21:18:46 validates the NSEC RR that proves the not-existence of the CAA RR. Owner hnusnik.cz, NextOwner: \000.hnusnik.cz. Bitmap: A, NS, SOA, MX, TXT, AAAA, RRSIG, NSEC, DNSKEY

Older topic with the same NextOwner NSEC \000.maindomain - no real solution.

Curious: Unboundtest is happy:

https://unboundtest.com/m/CAA/www.hnusnik.cz/4GK3X7FU

Looks like there is sometimes a "hidden problem" with CNAME definitions.

Perhaps replace the CNAME with the same two A- and AAAA-records of your main domain.

Host T IP-Address is auth. ∑ Queries ∑ Timeout
hnusnik.cz A 89.185.235.201 Brno/South Moravian/Czechia (CZ) - Master Internet s.r.o. Hostname: kybl.shy.cz yes 2 0
AAAA 2a01:430:27::201 Brno/South Moravian/Czechia (CZ) - Master Internet s.r.o. yes
www.hnusnik.cz C hnusnik.cz yes 1 0
A 89.185.235.201 Brno/South Moravian/Czechia (CZ) - Master Internet s.r.o. Hostname: kybl.shy.cz yes
AAAA 2a01:430:27::201 Brno/South Moravian/Czechia (CZ) - Master Internet s.r.o. yes

Then try it again.

If that doesn't help, try to create a CAA entry with your www domain name and letsencrypt.org as value.

PS:

That's

expected. Both checks don't check CAA entries.

4

Hm, it was the latest version from the official Jessie repository.
But, I updated based on this: https://certbot.eff.org/lets-encrypt/debianjessie-apache
Now I have to wait for a while, too many attempts.

5

I have no CAA entries and never had on this domain.

Can you explain what is curious about that?

There is no CNAME on the specific records relevant this, I have just:

hnusnik.cz.           14400 A 89.185.235.201
hnusnik.cz.           14400 AAAA  2a01:430:27::201

Do you mean for www? This would seem strange if it was the problem and sincerely should be fixed elsewhere. I have it set up like that on all of my domains.

6

Read some RFCs about NSEC. There is no 000 Next domain, so it's ok, but it's a Black Lie.

But to understand that blog post, a lot of details of NSEC are required.

I don't know what's the problem. But sometimes removing CNAME helps. So you can try it - or not.

There are sometimes some not working name servers with such NSEC answers. But the reason is unclear.

7

Oh, I understand. These are not Black lies (never heard the term before). My zone supports synthesized DNS responses which are signed online. You cannot walk my zone, because it just does not exists, it is dynamically created, but behavior is similar to what they call Black lies, but no lying is actually involved. The records are not there but may be created if somebody asks for them.

https://tools.ietf.org/html/rfc4471

8

Changing the www variant to A/AAAA record actually works. So thanks for the tip! But I am extremely sure it is a bug in on the side of Let’s encrypt and possible explanation why it is not working on some domains.

9

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