# DNS problem: SERVFAIL looking up CAA **URL:** \ **Category:** Help\ **Created:** [March 21, 2019, 7:36am UTC](https://community.letsencrypt.org/t/dns-problem-servfail-looking-up-caa/89284 "2019-03-21T07:36:45Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Ecwid](https://avatars.discourse-cdn.com/v4/letter/e/258eb7/32.png) [@Ecwid](https://community.letsencrypt.org/u/Ecwid)\ **Post date:** [March 21, 2019, 7:36am UTC](https://community.letsencrypt.org/t/dns-problem-servfail-looking-up-caa/89284/1 "2019-03-21T07:36:45Z")
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. [https://crt.sh/?q=example.com](https://crt.sh/?q=example.com)), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help. My domain is: smoki.fish I ran this command: ./letsencrypt-auto certonly -a webroot --webroot-path=/var/www/html --no-bootstrap --no-self-upgrade --agree-tos --non-interactive --renew-by-default -d smoki.fish -d www.smoki.fish It produced this output: /opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/cryptography/hazmat/primitives/constant\_time.py:26: CryptographyDeprecationWarning: Support for your Python version is deprecated. The next version of cryptography will remove support. Please upgrade to a 2.7.x release that supports hmac.compare\_digest as soon as possible. utils.DeprecatedIn23, Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer None Renewing an existing certificate Performing the following challenges: http-01 challenge for smoki.fish http-01 challenge for www.smoki.fish Using the webroot path /var/www/html for all unmatched domains. Waiting for verification… Challenge failed for domain smoki.fish Challenge failed for domain www.smoki.fish http-01 challenge for smoki.fish http-01 challenge for www.smoki.fish Cleaning up challenges Some challenges have failed. IMPORTANT NOTES: - The following errors were reported by the server: My web server is (include version): nginx 1.12.2 The operating system my web server runs on is (include version): Ubuntu 14.04 My hosting provider, if applicable, is: no 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 The version of my client is (e.g. output of `certbot --version` or `certbot-auto --version` if you’re using Certbot): $ ./certbot-auto --version certbot 0.32.0 ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [March 21, 2019, 7:55am UTC](https://community.letsencrypt.org/t/dns-problem-servfail-looking-up-caa/89284/2 "2019-03-21T07:55:46Z")
It seems like the domain has some kind of DNSSEC or EDNS issues, but I don’t understand what’s happening really. [https://letsdebug.net/smoki.fish/29565](https://letsdebug.net/smoki.fish/29565) [http://dnsviz.net/d/smoki.fish/dnssec/](http://dnsviz.net/d/smoki.fish/dnssec/) [https://ednscomp.isc.org/ednscomp/592057cda1](https://ednscomp.isc.org/ednscomp/592057cda1) [https://unboundtest.com/m/CAA/smoki.fish/MBFV5NJZ](https://unboundtest.com/m/CAA/smoki.fish/MBFV5NJZ) After turning up debug logging, it seems that the problem is with the signature of your nameservers’ `NSEC` responses … one workaround could be to add CAA records for `smoki.fish` and `www.smoki.fish` to avoid any NSEC … ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [March 21, 2019, 8:46am UTC](https://community.letsencrypt.org/t/dns-problem-servfail-looking-up-caa/89284/3 "2019-03-21T08:46:37Z")
Unrelated but worth the mention: > **[DNSSEC:NSEC vs. NSEC3 | Internet Society](https://www.internetsociety.org/resources/deploy360/2014/dnssecnsec-vs-nsec3/)** > > The Domain Name System Security Extensions(DNSSEC) provide two different records for securely handling non-existent names in DNS, NSEC and NSEC3. They are mutually exclusive, so operators need to pick one when deploying DNSSEC. The Problem The... ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [March 21, 2019, 8:50am UTC](https://community.letsencrypt.org/t/dns-problem-servfail-looking-up-caa/89284/4 "2019-03-21T08:50:07Z")
Following [this trick](https://community.letsencrypt.org/t/acme-client-on-openbsd-6-3/61785/8?u=_az) from @mnordhoff to identify that these nameservers are running PowerDNS, if you run the nameservers , you could also try to rehash the zone: ``` sudo pdnsutil rectify-zone smoki.fish ``` or if you don’t run the nameservers, you can ask the operator to do the same. ---
**Author:** ![Ecwid](https://avatars.discourse-cdn.com/v4/letter/e/258eb7/32.png) [@Ecwid](https://community.letsencrypt.org/u/Ecwid)\ **Post date:** [March 21, 2019, 9:42am UTC](https://community.letsencrypt.org/t/dns-problem-servfail-looking-up-caa/89284/5 "2019-03-21T09:42:51Z")
Thank you very much for the answer! We’ll first try to remove all DNSSEC records except one with key id = 6935 which is pointed by DS record as I see here [https://mxtoolbox.com/SuperTool.aspx?action=ds%3asmoki.fish&run=toolpage](https://mxtoolbox.com/SuperTool.aspx?action=ds%3asmoki.fish&run=toolpage). If it doesn’t solve the problem, we’ll ask the operator to rehash the zone. Thanks a lot! I’ll come back soon. ---
**Author:** ![Ecwid](https://avatars.discourse-cdn.com/v4/letter/e/258eb7/32.png) [@Ecwid](https://community.letsencrypt.org/u/Ecwid)\ **Post date:** [March 21, 2019, 9:55am UTC](https://community.letsencrypt.org/t/dns-problem-servfail-looking-up-caa/89284/6 "2019-03-21T09:55:59Z")
How the CAA record we need to create should look like? ---
**Author:** ![JuergenAuer](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/juergenauer/32/26491_2.png) [@JuergenAuer](https://community.letsencrypt.org/u/JuergenAuer)\ **Post date:** [March 21, 2019, 9:56am UTC](https://community.letsencrypt.org/t/dns-problem-servfail-looking-up-caa/89284/7 "2019-03-21T09:56:19Z")
Hi @Ecwid > [@Ecwid](#): > > We’ll first try to remove all DNSSEC records except one with key id = 6935 which is pointed by DS record I don't know, if DNSSEC is directly the problem. The first nameserver of the fish-zone is buggy ( [https://check-your-website.server-daten.de/?q=smoki.fish](https://check-your-website.server-daten.de/?q=smoki.fish) ). > Fatal error: Nameserver doesn't support TCP connection: demand.alpha.aridns.net.au: Fatal error (-14). Details: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. - An existing connection was forcibly closed by the remote host Checking a CAA record: First smoki.fish is checked, if there is no CAA entry, fish is checked. So if you have a smoki.fish - CAA, the buggy nameserver is ignored. But DNSSEC without TCP-support is critical. So create a CAA entry to stop the check of .fish. There is a second thing: Your ip addresses: | Host | T | IP-Address | is auth. | ∑ Queries | ∑ Timeout | | --- | --- | --- | --- | --- | --- | | smoki.fish | A | 34.193.83.23 | yes | 1 | 0 | | | AAAA | | yes | | | | www.smoki.fish | C | [smoki.co](http://smoki.co) | yes | 1 | 0 | | | A | 34.193.83.23 | yes | | | Your www version has a CNAME to [smoki.co](http://smoki.co) - but that zone has no parent DS, but a local DNSKEY: > Fatal error: DNSKEY 55399 signs DNSKEY RRset, but no confirming DS RR in the parent zone found. No chain of trust created. But the ip address is the same, so perhaps it's possible to change ```nohighlight www.smoki.fish -> CNAME -> smoki.fish ``` so the `smoki.co` domain isn't touched / checked. ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [March 21, 2019, 9:57am UTC](https://community.letsencrypt.org/t/dns-problem-servfail-looking-up-caa/89284/8 "2019-03-21T09:57:55Z")
> [@Ecwid](#): > > How the CAA record we need to create should look like? You would need to create two CAA records to avoid this issue, otherwise the NSEC problem will stop you. ``` smoki.fish. 300 IN CAA 0 issue "letsencrypt.org" www.smoki.fish. 300 IN CAA 0 issue "letsencrypt.org" ``` ---
**Author:** ![Ecwid](https://avatars.discourse-cdn.com/v4/letter/e/258eb7/32.png) [@Ecwid](https://community.letsencrypt.org/u/Ecwid)\ **Post date:** [March 21, 2019, 10:03am UTC](https://community.letsencrypt.org/t/dns-problem-servfail-looking-up-caa/89284/9 "2019-03-21T10:03:02Z")
Thank you guys!!! You’re amazingly helpful. I’ll come back again as soon as we get managed all of that recommendations. Thanks! ---
**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 21, 2019, 2:54pm UTC](https://community.letsencrypt.org/t/dns-problem-servfail-looking-up-caa/89284/10 "2019-03-21T14:54:28Z")
FWIW… ``` version.bind. 5 CH TXT "Served by POWERDNS 3.2 $Id: packethandler.cc 3022 2013-01-05 13:00:10Z peter $" ``` Whatever the issue here is, it needs to be upgraded anyway. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [April 20, 2019, 2:54pm UTC](https://community.letsencrypt.org/t/dns-problem-servfail-looking-up-caa/89284/11 "2019-04-20T14:54:42Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.