SERVFAIL for CAA RR when generating cert

I have an old bind nameserver that does NOT support CAA records, but it returns NOERROR when being queried for type CAA as expected:

dig @NS1.R4L.COM -tCAA

; <<>> DiG 9.16.1-Ubuntu <<>> @NS1.R4L.COM -tCAA
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51487
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

; EDNS: version: 0, flags:; udp: 4096

. 3600 IN SOA 2019120301 3600 1800 1814400 3600

;; Query time: 0 msec
;; WHEN: Wed Dec 06 16:08:33 EST 2023
;; MSG SIZE rcvd: 114

What's odd is if I try to generate a cert with, I get the following error from Letsencrypt: error:DNS problem: SERVFAIL looking up CAA for - the domain's nameservers may be malfunctioning

What am I missing ?

Note: this was working fine until a few weeks ago.

There are some issues reported by DNSViz (you can ignore the unknown RRSIG warnings; I think that's something weird about DNSViz's setup, but there are some actual issues too):

  • (NODATA): An SOA RR with owner name (.) not matching the zone name ( was returned with the NODATA response. (,, 2600:3c03::f03c:91ff:fe93:e369, 2607:5300:60:34bf::1, UDP_-_EDNS0_4096_D_KN)
  • org to The following NS name(s) were found in the authoritative NS RRset, but not in the delegation NS RRset (i.e., in the org zone):,
  • org to The following NS name(s) were found in the delegation NS RRset (i.e., in the org zone), but not in the authoritative NS RRset:,

So, make sure that the delegation to your nameserver is set up correctly.

I'm not sure if it's related, but Let's Encrypt did upgrade the version of Unbound they use within the last few weeks, and I think it may be pickier about ensuring that DNS delegations are set up correctly.

Unboundtest seems to be getting NOERROR, but I think it's still on the previous version of Unbound.


Very helpful, Peter.

Thanks for the amazing feedback on this!


Adding to what @petercooperjr has shown; other tools have similar error too.

1 Like

Yes, this nameserver uses an old hack I made some twenty years ago to resolve any request sent to it with a default zonefile.

That's why the CAA lookup is now failing, so I need to create a real zone to fix the issue. (this does resolve the issue)


You might also want to update to newer DNS-serving software. (Or use one of the many hosted options out there, though of course there are good reasons to want to host things oneself as well.)

Hey @jsha, when you get a chance, if you could update Unboundtest to the 1.18 version that LE production is using now, I think it might be helpful. It seems… pickier than prior versions about NS delegations matching and AA flags and SOA responses being standard and so forth. (Honestly having the option to try testing with both the old as well as the current version might be neat too, just so we can confirm that people aren't crazy and in fact the DNS server did use to "work" at least as far as Let's Encrypt validation was concerned.)


Good call. I've updated it (temporarily) to have a radio button for 1.16 or 1.18.

It's pretty hacky but you can search for "start of service" in the logs to see which version got run.

Once 1.18 has been in prod a while I'll remove the radio button again.


I think this is first thread where the 1.16 and 1.18 test was very helpful. Just saying thanks ! :slight_smile:


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