# Renewal problem: SERVFAIL looking up CAA

**URL:** <https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603>\
**Category:** Help\
**Created:** [March 24, 2017, 7:04pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603 "2017-03-24T19:04:22Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![RonaldPK](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ronaldpk/32/12210_2.png) [@RonaldPK](https://community.letsencrypt.org/u/RonaldPK)\
**Post date:** [March 24, 2017, 7:04pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/1 "2017-03-24T19:04:22Z")

</div>

I’ve successfully created and installed certificates by running  
`sudo ./letsencrypt-auto --apache -d 020apps.nl -d static.020apps.nl -d olie.020apps.nl`

I then ran this command:  
`sudo ./letsencrypt-auto renew --dry-run`

It produced this output:

- The following errors were reported by the server:

My operating system is (include version): Debian 8.7

My web server is (include version): Apache 2.4

I can login to a root shell on my machine: yes

I’m using a control panel to manage my site: no

Should I worry? I don’t understand why setting up the certificates went fine but renewing the ones for the subdomains seems to fail.  
FWIW, the domain’s DNS record doesn’t have a CAA entry.

---

<div class="post-metadata">

**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\
**Post date:** [March 24, 2017, 7:55pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/2 "2017-03-24T19:55:01Z")

</div>

Hi @RonaldPK,

It’s fine not to have a CAA entry, but the DNS server needs to say “I don’t have a CAA entry” rather than “I don’t understand the question” or “I can’t answer the question”. The certificate authority views a DNS server failure (SERVFAIL) as invalid and refuses to issue a certificate in this case.

So, your DNS provider (or your own DNS server) needs to be updated to accept and respond to queries for the RR type CAA, even if the answer is that no such records are present.

---

<div class="post-metadata">

**Author:** ![RonaldPK](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ronaldpk/32/12210_2.png) [@RonaldPK](https://community.letsencrypt.org/u/RonaldPK)\
**Post date:** [March 24, 2017, 8:42pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/3 "2017-03-24T20:42:25Z")

</div>

Thank you @schoen . I still don’t understand why creating and installing the certificates worked (for all 3 domains) but renewing them fails (on 2 domains). Is the CAA not tested during cert creation?

---

<div class="post-metadata">

**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\
**Post date:** [March 24, 2017, 8:43pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/4 "2017-03-24T20:43:51Z")

</div>

It’s definitely tested each time; people have been getting failures related to this condition for over a year. Perhaps the DNS server software used somewhere in the chain has changed somehow?

---

<div class="post-metadata">

**Author:** ![RonaldPK](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ronaldpk/32/12210_2.png) [@RonaldPK](https://community.letsencrypt.org/u/RonaldPK)\
**Post date:** [March 24, 2017, 9:28pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/5 "2017-03-24T21:28:10Z")

</div>

Possible but unlikely…

I just tried for a different domain. Same server, same DNS registrar.

`sudo ./letsencrypt-auto --apache -d www.example.nl`  
Certificate was created and got installed just fine, no errors.

`sudo ./letsencrypt-auto renew --dry-run`  
The same SERVFAIL errors were reported for the 020apps.nl-subdomains and for [www.example.nl](http://www.example.nl)

A change in DNS software seems even more unlikely 🙂

---

<div class="post-metadata">

**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\
**Post date:** [March 24, 2017, 10:14pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/6 "2017-03-24T22:14:07Z")

</div>

Right now, the staging server has a stricter setting for CAA that rejects SERVFAILs for CAA, which is not yet rolled out in prod. Since `--dry-run` uses staging, that’s why you only get the error there.

Who’s your registrar? We’d like to work with them to get this fixed.

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [March 24, 2017, 10:25pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/7 "2017-03-24T22:25:25Z")

</div>

If I’m to believe the SOA record, it’s [Interned Services](https://www.internedservices.nl/).

My personal testing with `dig +dnssec olie.020apps.nl CAA` and `dig +trace +dnssec olie.020apps.nl CAA` didn’t find any errors though…

DNSViz also [doesn’t give any error](http://dnsviz.net/d/olie.020apps.nl/dnssec/) but it doesn’t have the option to explicitely ask for CAA records (yet). (Issued two issues on the matter on their Github repo’s.)

---

<div class="post-metadata">

**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\
**Post date:** [March 24, 2017, 10:38pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/8 "2017-03-24T22:38:33Z")

</div>

Your query isn’t quite right. First, you need to find the authoritative nameservers:

```auto
$ dig +short NS olie.020apps.nl
$ dig +short NS 020apps.nl
ns03.is.nl.
ns01.is.nl.
ns02.is.nl.

```

Now you want to query one of the authoritative nameservers for CAA. Note that I use `-t TYPE257` just in case your `dig` doesn’t support CAA yet:

```auto
$ dig -t TYPE257 olie.020apps.net @ns03.is.nl.

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t TYPE257 olie.020apps.net @ns03.is.nl.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 25275
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;olie.020apps.net. IN CAA

;; Query time: 157 msec
;; SERVER: 2001:9a0:2003:1::53:3#53(2001:9a0:2003:1::53:3)
;; WHEN: Fri Mar 24 15:36:51 PDT 2017
;; MSG SIZE rcvd: 45

```

Note the REFUSED there, which is probably the problem.

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [March 24, 2017, 10:45pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/9 "2017-03-24T22:45:12Z")

</div>

Hmm, I see, will dig better next time 🙂

But what I don’t understand is the following: when I executed `dig` with the `+trace` switch, it also queried one of the authorative nameservers (ns0{1,2,3}.is.nl). In the reply, it presented NSEC records, the (superseded by NSEC3 by the way 😛) “proof” of non-existence of the queried hostname/RR.  
Those NSEC records are nowhere to be found when I directly query the nameserver like you did? (`dig +dnssec +norecurse @ns03.is.nl olie.020apps.net CAA`). Am I missing something? 😟 I do get the `REFUSED` tho… 🙂

---

<div class="post-metadata">

**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\
**Post date:** [March 24, 2017, 10:49pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/10 "2017-03-24T22:49:49Z")

</div>

Trace mode essentially asks `dig` to act like a recursive resolver, optionally including DNSSEC record lookups and validation. Similarly, if you set the dnssec bit on a non-trace dig query, you are telling the resolver you want DNSSEC when it recurses. However, in this case you are talking directly to an authoritative resolver and it is not recursing for you:

> ;; WARNING: recursion requested but not available

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [March 24, 2017, 10:58pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/11 "2017-03-24T22:58:40Z")

</div>

@jsha Found out why you get a “REFUSED”: the TLD used by @RonaldPK is `.nl`, not `.net` 🙂

---

<div class="post-metadata">

**Author:** ![RonaldPK](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ronaldpk/32/12210_2.png) [@RonaldPK](https://community.letsencrypt.org/u/RonaldPK)\
**Post date:** [March 24, 2017, 10:58pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/12 "2017-03-24T22:58:54Z")

</div>

> [@jsha](#):
>
> $ dig -t TYPE257 [olie.020apps.net](http://olie.020apps.net) @ns03.is.nl.

It's olie.020apps`.nl`, not `.net`

Registrar is what Osiris said, Interned Services, [https://www.internedservices.nl/](https://www.internedservices.nl/) (or is.nl, but they're moving away that one, for obvious reasons)

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [March 24, 2017, 10:59pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/13 "2017-03-24T22:59:58Z")

</div>

Also `dig +dnssec +norecurse @ns02.is.nl olie.020apps.nl CAA` gives a NOERROR as status… So unfortunately still no clue why Boulder would result in a SERVFAIL.

---

<div class="post-metadata">

**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\
**Post date:** [March 24, 2017, 11:44pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/14 "2017-03-24T23:44:39Z")

</div>

Aha, thanks for spotting my error! The other possibility: Sometimes routing problems cause problems getting CAA from various network perspectives. I’ll try and dig into this, thanks.

---

<div class="post-metadata">

**Author:** ![RonaldPK](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ronaldpk/32/12210_2.png) [@RonaldPK](https://community.letsencrypt.org/u/RonaldPK)\
**Post date:** [March 27, 2017, 9:16am UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/15 "2017-03-27T09:16:27Z")

</div>

FWIW, the registrar just told me they’re working on adding CAA as a resource type to the DNS management interface. No ETA, but good news anyway.

---

<div class="post-metadata">

**Author:** ![ahaw021](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ahaw021/32/14882_2.png) [@ahaw021](https://community.letsencrypt.org/u/ahaw021)\
**Post date:** [March 27, 2017, 11:55am UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/16 "2017-03-27T11:55:40Z")

</div>

@jsha@schoen

is there a possibility of a bug here

> [@DNS problem: SERVFAIL looking up A for chh.lightboxcreative.co.nz](https://community.letsencrypt.org/t/dns-problem-servfail-looking-up-a-for-chh-lightboxcreative-co-nz/30695):
>
> H…

also reporting similar conditions - dry run not working but normal process issuing

should we try to test by inducing the fail conditions?

i am little bit suspicious that there are not DNS record issues at the time of issuing but two days (or even the same day in the case above) there are lots of them

Andrei

---

<div class="post-metadata">

**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\
**Post date:** [March 27, 2017, 6:04pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/17 "2017-03-27T18:04:53Z")

</div>

@ahaw021: Looks like @roland commented on the other thread with a likely cause, so I’m guessing these are unrelated, but I appreciate you connecting the dots!

I’ve got an independent Unbound instance set up outside of prod that gets the same SERVFAIL results for your hostname on first query:

```auto
$ dig -t TYPE257 olie.020apps.nl @127.0.0.1 -p 1053

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t TYPE257 olie.020apps.nl @127.0.0.1 -p 1053
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31799
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;olie.020apps.nl. IN CAA

;; Query time: 1884 msec
;; SERVER: 127.0.0.1#1053(127.0.0.1)
;; WHEN: Mon Mar 27 14:03:00 EDT 2017
;; MSG SIZE rcvd: 44

```

However, subsequent queries get NOERROR. I’m not sure what the problem is; any other thoughts here?

---

<div class="post-metadata">

**Author:** ![ahaw021](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ahaw021/32/14882_2.png) [@ahaw021](https://community.letsencrypt.org/u/ahaw021)\
**Post date:** [March 27, 2017, 11:43pm UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/18 "2017-03-27T23:43:24Z")

</div>

will spin this of as a new topic

will do some sleuthing see if we can replicate the error

Andrei

---

<div class="post-metadata">

**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\
**Post date:** [March 28, 2017, 4:01am UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/19 "2017-03-28T04:01:38Z")

</div>

> [@jsha](#):
>
> However, subsequent queries get NOERROR. I'm not sure what the problem is; any other thoughts here?

Maybe it's just a distance thing? Or some sort of regional connectivity issue? It looks like all 3 nameservers are hosted in 2 locations in 1 ASN in or near Amsterdam. And they use DNSSEC and relatively low TTLs. Maybe there's packet loss, or recursion is just taking too long and timing out?

---

<div class="post-metadata">

**Author:** ![tob](https://avatars.discourse-cdn.com/v4/letter/t/a88e57/32.png) [@tob](https://community.letsencrypt.org/u/tob)\
**Post date:** [April 18, 2017, 7:05am UTC](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603/20 "2017-04-18T07:05:02Z")

</div>

Have the same problem with my DNS-Provider ([inwx.de](http://inwx.de)).

DNSSEC-enabled domains get SERVFAIL error when using validating resolver , domains without DNSSEC CAA works without error (with existing CAA-Record and without).

When will this strict check go into production? I have to disable DNSSEC on my domains where I need le-certs…

[Next page](https://community.letsencrypt.org/t/renewal-problem-servfail-looking-up-caa/30603.md?page=2)