CAA SERVFAIL on subdomain

We are trying to generate a certificate for
System: Centos 6.9 with Directadmin 1.52.1

The domain owner has added a A and a AAAA record, pointing to our server. When trying to generate a Let’s Encrypt certificate with the Directadmin GUI we run into a ‘DNS problem: SERVFAIL looking up CAA for’

The Unbound DNS Checker sems to indicate that it isn’t a problem on our server:
Result: sec_status_bogus

For the domain name itself there is no problem:
Result: sec_status_secure

We do not know anything about the DNS that is using. The domain is registered at = a reseller of

The Unbound debug log is a little it above our heads as DNSSEC noobs, so maybe someone can give us a clue where it goes wrong and what we could do to solve the problem.

Thank in advance,
Jan Ehrhardt

Please verify the FQDN you are trying to obtain a cert for.
And also the public IP addresses of your server.

DNSSEC seems to be setup correctly:

The FQDN and the public IP-addresses are correct. Over http there is no problem:

Do you have any idea why the Unbounds DNS Checker returns a SERVFAIL?

That is exactly the error we are getting when we are trying to get a LetsEncrypt cert.

No I do not know why.
But I see at least 3 tickets regarding CAA so they all might be related.

I also saw those tickets. Maybe @cpu can take a look at the Unbounds Debug log (when he wakes up).

LOL. I would dare to do that as newbie in this community.

Thanks for the @ tag. Looking into this.

1 Like
debug: NODATA response failed to prove NODATA status with NSEC/NSEC3
info: validate(nodata): sec_status_bogus

I’m not sure what exactly the issue is, but as a general rule, an issue like this is usually either that you need to upgrade PowerDNS to 4.0.4 or newer, or that you need to run “pdnsutil rectify-zone”.

Edit: I forgot to add, the PowerDNS <= 4.0.3 bug is mentioned in Let’s Encrypt’s CAA documentation:

As for rectifying the zone, this is hand-wavy, but sometimes zone changes can get the NSEC3 records out of sorts, and that needs to be done to fix them. :confused:


I was guessing is using PowerDNS, allthough a query did not show that:

monitor@xs9:~$ dig +short ns
monitor@xs9:~$ dig +short version.bind chaos txt

And pdnsutil rectify-zone does not seem to be a thing a normal user can do. Or am I mistaken?

Yeah. The RRSIGs are valid for 3 weeks, midnight Thursday to Thursday, which is PowerDNS's default signing configuration. It was almost definitely used to sign the zone, though other software could be serving it.

It's something one of the DNS provider's sysadmins would have to do, probably. Doubtful they expose it in the control panel.

1 Like

Any idea which version of PowerDNS they are using? If it is > 4.0.0 We could ask the domain owner if he is able to add a CAA record. Like it is suggested here:

I’m not sure, but I checked other domains using the same nameservers, and they respond in a valid manner to CAA queries (and other negative queries)… I think that means it’s at least 4.0.0, or a different implementation. If I remember correctly, earlier versions of PowerDNS couldn’t handle CAA queries at all.

OK, thanks for the help. We will ask the domain owner if his control panel allows him to add a CAA record. I will report back when we have the answer.

The domain owner reported back to me that he had only control over these records: A, AAAA, CNAME, MX, PTR, SRV & TXT. Hence no CAA.

It looks like has tweaked their DNS a little bit. They offer ‘free SSL’ for the main domain, which is possible because does not SERVFAIL. They explicitely do not offer free SSL for subdomains. In stead they are directing their customers to a paid option, with a price of no less than Euro 75 per year for a single non-wildcard subdomain.

A paid certificate is probably our only way to go now, given that SERVFAILs on the CAA record. But we definitely will not pay Euro 75 each year for a single non-wildcard SSL certificate.

Thanks for everybody’s input, especially @mnordhoff This thread ends in a very disappointing ‘solution’: no Let’s Encrypt but a paid certificate.

To be clear, the DNS setup is broken. No matter what CA you use, whether you use SSL or not, it’s wrong and they should fix it.

It’s just a coincidence that the issue is affecting Let’s Encrypt and not – as far as you know – anything else you rely on.

1 Like

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