Trouble with Verify error:DNS problem: SERVFAIL looking up CAA

I am trying to generate a certificate to accomodate https our internal artifactory. No visibility outside the company. We are using to automate the dns_01 challenges on our GoDaddy dns provider. It has always work in the past but now I added a new wildcard * for some redundancy and it does not seem to work.
On our internal dns server, is an A record that point to the ip of the server. is a cname pointing to Not sure this is relevant though.
I was able to generate the equivalent with * for out tests on RedHat OpenShift and it worked fine.
I can see the txt record in our dns provider, the script proceeds with validation when I see the propagation using so all seems good. I cannot understand what fails with that validation.

There is this entry in the beginning of the log about pending status for that specific subdomain, not sure if it's normal:

Getting webroot for domain='*'

My domain is:

I ran this command:
/root/ --issue --force --log --dns dns_gd -d -d * -d * -d * -d * -d *

It produced this output:
* error:DNS problem: SERVFAIL looking up CAA for - the domain's nameservers may be malfunctioning

My web server is (include version):
It is an internal artifactory site in my company

The operating system my web server runs on is (include version):
Docker instance of artifactory on Centos VM

My hosting provider, if applicable, is:

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

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
GitHub - acmesh-official/ A pure Unix shell script implementing ACME client protocol v2.8.6

Here is an image of the output just before it fails:


Your DNS server is not responding correctly to a query for the CAA record. The CAA record allows you to specify which Certificate Authorities are allowed to issue for your domain. You don't need to have one, but if you don't then your DNS server needs to correctly say you don't rather than giving an error.

Info on CAA:

A test site showing the same SERVFAIL that Let's Encrypt is getting:

The DNSViz checker has some more details about the failure:

I think that it's simultaneously saying the name does not exist, while not having a DNSSEC signature that says the name doesn't exist, but I'm far from an expert on DNSSEC. Regardless, this is something your DNS server needs to fix. Depending on who hosts your DNS, you might try disabling DNSSEC and re-enabling it, or adding a CAA record (even one allowing for all CAs) might work around their DNS implementation bug. Or maybe your DNS provider needs to upgrade their DNS server.


Ok thanks for the reply. I have this record in my dns:
CAA @ 0 issue 1 Hour

Looking at your reply I'm concerned because all our certificate requests are working. Just for this one I'm having trouble. Two days I have been trying to generate it...

About DNSSEC it is enabled and it has two entries for but did not try to disable and enable.


There's a CAA record for that works fine.

But before checking that, Let's Encrypt first needs to check for a CAA record for the full hostname (since it takes precedence if it exists), and that query is the one that's failing (so Let's Encrypt can't tell if it in fact exists).


Ok but why it does not fail when I ask for There is no CAA for this one or for any other domain I ask for in my requests. They are all for internal sites so none of them actually respond from the letsencrypt perspective. But I understand that only the txt record is suppose to prove you control the domain you ask for.


The CAA query for is correctly returning NXDOMAIN (that the domain doesn't exist). Saying it doesn't exist is fine from Let's Encrypt's perspective (and as you say is common for internal sites), but returning an error isn't.

But I don't know why your DNS server is returning an error for some hostnames and not others. You'd have to ask whomever runs your DNS server.


Ahh ok this is a good lead, I will try to take it with goDaddy to see if they have anything to say about this.


It seems that disable and enable DNSSEC did the trick!

No one at goDaddy could explain why some domains were getting SERVFAIL and some NXDOMAIN. So I went ahead and tried what you asked me first and it seems it fixed it.

Thank you this was not obvious for me!


It's quite something how many DNS providers allow for DNSSEC to be used but then don't seem to have an understanding of how to test, debug, or correct issues with it. Glad to hear that you got it working, though!


A few minutes after my post it stopped working again. I did again the same procedure and it worked after little while. It seems very fleaky to me and I do not know if I should disable DNSSEC or not because I do not know what it does.

I could get my certificate for, so for now it's fine but it will happen again I suppose. The result of the CAA query for these two is no NOERROR even though there is no record matching these domains.
If I try with for which I did not ask for a certificate yet, I still get the NXDOMAIN.

I suppose that as long as I do not get the SERVFAIL I should be good.

Anyways thanks for your insight it helped a lot!


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