[SOLVED] DNS problem: SERVFAIL looking up CAA for mit42.de

[xabbu]

Please fill out the fields below so we can help you better.

My domain is: downloadlink.mit42.de

I ran this command: certbot certonly --webroot -w /usr/local/ispconfig/interface/acme/ -d downloadlink.mit42.de --dry-run -v --text --force-renew --debug

It produced this output:
IMPORTANT NOTES:

• The following errors were reported by the server:

  Domain: downloadlink.mit42.de
  Type: connection
  Detail: DNS problem: SERVFAIL looking up CAA for mit42.de

  To fix these errors, please make sure that your domain name was
  entered correctly and the DNS A record(s) for that domain
  contain(s) the right IP address. Additionally, please check that
  your computer has a publicly routable IP address and that no
  firewalls are preventing the server from communicating with the
  client. If you’re using the webroot plugin, you should also verify
  that you are serving files from the webroot path you provided.

My operating system is (include version): CentOS Linux release 7.2.1511 (Core)

My web server is (include version): nginx/1.10.1

My hosting provider, if applicable, is: myself

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

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

In my Loggile of nginx I see:
66.133.109.36 - - [11/Oct/2016:20:37:00 +0200] “GET /.well-known/acme-challenge/uREhKtxst4SYwdeALJoczsr4HINUqPJx8MqZoKTuVXw HTTP/1.1” 200 87 “-” “Mozilla/5.0 (compatible; Let’s Encrypt validation server; +https://www.letsencrypt.org)” “-”

So the File was found. But I’ve no idea why the certificate could not be generated.

Thanks for help
xabbu

[mnordhoff]

Detail: DNS problem: SERVFAIL looking up CAA for mit42.de

Well, that’s the error. Let’s Encrypt’s DNS resolver fails while looking up a CAA record for mit42.de. (The record is optional and uncommon, but the lookup needs to succeed, either resulting in “here’s the record” or “there is no such record”, not an error.)

I’m not sure why, but you definitely have DNS issues. I also get SERVFAIL for dig mit42.de caa and some other queries, from multiple resolvers. (E.g. dig mit42.de aaaa. Again, you don’t need an AAAA record, but the lookup should not fail. To be clear, Let’s Encrypt probably doesn’t care about that one.)

$ dig mit42.de caa

; <<>> DiG 9.10.3-P4-Ubuntu <<>> mit42.de caa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52188
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mit42.de.                      IN      CAA

;; Query time: 1570 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Oct 11 19:42:09 UTC 2016
;; MSG SIZE  rcvd: 37

DNSViz agrees that some things fail: http://dnsviz.net/d/mit42.de/dnssec/

I notice that the .de nameservers delegate to both ns1.mit42.de and ns2.mit42.de, but only the former appears to exist. (The mit42.de zone’s own NS records only mention ns1.mit42.de.) Queries for ns2.mit42.de's AAAA or A records again seem to fail, which may be a symptom of whatever is wrong, and may also make other queries sporadically fail when resolvers try to use it.

Anyway, i’m not sure how, but y’all need to fix whatever is up with your nameservers. Let’s Encrypt needs to know what the CAA record is, or that it does not exist. A failure could be an MITM blocking queries for the record and trying to get a certificate issued even though there actually is a CAA record specifying that only other CAs should be used, so this should be fatal to the issuance process.

[jsha]

@mnordhoff has it exactly right. Let’s Encrypt looks up CAA for all domains it issues for. Currently in prod it will treat SERVFAIL the same as NOERROR, but per Upcoming API changes we are planning to start treating SERVFAIL as a failure, and refuse issuance (except for a whitelist of already-issued hostnames). The staging server is demonstrating that behavior today.

Can you tell use more about your DNS server? What software is it running, and with what configuration? Are there DNS-aware firewalls between your server and the Internet that might interfere with newer DNS record types like CAA?

Thanks,
Jacob

[xabbu]

Thanks a lot for your fast replys!
@mnordhoff was right, my secondary DNS Server was unavailable.
I’ve correct the records in the whois database and add it back to my namserver.
Now it is working! Thanks.

@jsha why my DNS Server (Bind 9.97) answered with SERVFAIL when one of my second Nameserver is missing is not really clear but now it is working. Both Nameservers are available.
I’ve not set a CAA Record.

Thanks a lot!
xabbu

[jsha]

Excellent!

@jsha why my DNS Server (Bind 9.97) answered with SERVFAIL when one of my second Nameserver is missing is not really clear but now it is working. Both Nameservers are available.

The SERVFAIL response code may have come from Let’s Encrypt’s Unbound recursive resolver. Recursive resolvers will return SERVFAIL if an authoritative resolver is unresponsive, OR if an authoritative resolver returns SERVFAIL (or a few other reasons). In theory Unbound has a number of retries and I thought it would have hit your working resolver on a retry, but doesn’t seem to have happened in this case.

Glad you’ve got things working!

[xabbu]

The SERVFAIL response code may have come from Let’s Encrypt’s Unbound recursive resolver. Recursive resolvers will return SERVFAIL if an authoritative resolver is unresponsive, OR if an authoritative resolver returns SERVFAIL (or a few other reasons). In theory Unbound has a number of retries and I thought it would have hit your working resolver on a retry, but doesn’t seem to have happened in this case.

Thanks for explain it to me!

Excellent Support!!!