Since last month renewal failures

My domain is:
rakis.nl

I ran this command:
/usr/bin/letsencrypt renew

It produced this output:
Processing /etc/letsencrypt/renewal/blog.rakis.nl.conf
Processing /etc/letsencrypt/renewal/fs.rakis.nl.conf
Processing /etc/letsencrypt/renewal/rakis.nl.conf

The following certs are not due for renewal yet:
/etc/letsencrypt/live/blog.rakis.nl/fullchain.pem (skipped)
/etc/letsencrypt/live/rakis.nl/fullchain.pem (skipped)
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/fs.rakis.nl/fullchain.pem (failure)
IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: fs.rakis.nl
    Type: dns
    Detail: DNS problem: SERVFAIL looking up A for fs.rakis.nl

My web server is (include version):
nginx/xenial-updates,xenial-updates,xenial-security,xenial-security,now 1.10.3-0ubuntu0.16.04.2 all [installed]
nginx-common/xenial-updates,xenial-updates,xenial-security,xenial-security,now 1.10.3-0ubuntu0.16.04.2 all [installed,automatic]
nginx-core/xenial-updates,xenial-security,now 1.10.3-0ubuntu0.16.04.2 amd64 [installed,automatic]

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

My hosting provider, if applicable, is:
DNS through Novoserve, IP by xs4all.nl

I can login to a root shell on my machine (yes or no, or I don’t know):
Yep, local box under my desk

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

This worked fine for a few years, started getting errors since a few weeks ago. Automated renewal using a cronjob. I’m rusty in this. What happened? A record for *.rakis.nl vs certificate on fs.rakis.nl? Or something else?

Bert

It appears that only the production Let’s Encrypt server produces the SERVFAIL - staging works fine. Such divergences shouldn’t exist, in theory :thinking: .

Might be a networking problem between the production DNS resolvers and your nameservers. You may have to wait for cpu/jsha to check the logs - I don’t see anything obviously wrong.

Edit: I do think it’s related to the specific nameservers rather than the domain itself. Another domain hosted on the same nameservers (iota.nl, pulled randomly out of a hat) exhibits the exact same behavior.

1 Like

There's an issue with novoserve.com that breaks resolvers with QNAME minimisation on. (And Let's Encrypt seems to have recently turned it on, perhaps inadvertently -- Unbound 1.7.2 toggled it on by default.)

rakis.nl uses these nameservers (which I had to use a different resolver to learn):

rakis.nl.               86400   IN      NS      ns1.iaf.novoserve.com.
rakis.nl.               86400   IN      NS      ns2.iaf.novoserve.com.

novoserve.com uses these nameservers:

novoserve.com.          86105   IN      NS      ns0.transip.nl.
novoserve.com.          86105   IN      NS      ns1.transip.net.
novoserve.com.          86105   IN      NS      ns2.transip.eu.

If you ask them about one of the nameservers without QNAME minimisation, you get an authoritative answer:

$ dig +norecurse @ns0.transip.nl ns2.iaf.novoserve.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +norecurse @ns0.transip.nl ns2.iaf.novoserve.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29969
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns2.iaf.novoserve.com.         IN      A

;; ANSWER SECTION:
ns2.iaf.novoserve.com.  60      IN      A       80.89.225.18

;; Query time: 103 msec
;; SERVER: 2a01:7c8:a::53#53(2a01:7c8:a::53)
;; WHEN: Tue Jul 31 01:21:08 UTC 2018
;; MSG SIZE  rcvd: 87

If you do use QNAME minimisation, you get a broken delegation:

$ dig +norecurse @ns2.transip.eu iaf.novoserve.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +norecurse @ns2.transip.eu iaf.novoserve.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18138
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;iaf.novoserve.com.             IN      A

;; AUTHORITY SECTION:
iaf.novoserve.com.      60      IN      NS      ns1.iaf.novoserve.com.
iaf.novoserve.com.      60      IN      NS      ns2.iaf.novoserve.com.

;; Query time: 96 msec
;; SERVER: 2a01:7c8:c::53#53(2a01:7c8:c::53)
;; WHEN: Tue Jul 31 01:21:39 UTC 2018
;; MSG SIZE  rcvd: 150

The operators of novoserve.com should fix their DNS, either by removing the half-done delegation, or adding glue.

2 Likes

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