# DNS problem: SERVFAIL **URL:** \ **Category:** Help\ **Created:** [June 15, 2020, 7:58pm UTC](https://community.letsencrypt.org/t/dns-problem-servfail/125892 "2020-06-15T19:58:53Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Krasax](https://avatars.discourse-cdn.com/v4/letter/k/a9a28c/32.png) [@Krasax](https://community.letsencrypt.org/u/Krasax)\ **Post date:** [June 15, 2020, 7:58pm UTC](https://community.letsencrypt.org/t/dns-problem-servfail/125892/1 "2020-06-15T19:58:53Z")
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: nepheli.ydns.eu I ran this command: sudo certbot --apache It produced this output: Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator apache, Installer apache Obtaining a new certificate Performing the following challenges: http-01 challenge for nepheli.ydns.eu Waiting for verification… Cleaning up challenges Failed authorization procedure. nepheli.ydns.eu (http-01): urn:ietf:params:acme:error:dns :: DNS problem: SERVFAIL looking up CAA for nepheli.ydns.eu - the domain’s nameservers may be malfunctioning IMPORTANT NOTES: - The following errors were reported by the server: My web server is (include version): Apache/2.4.38 The operating system my web server runs on is (include version): Raspbian 10 (Buster) My hosting provider, if applicable, is: 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 0.31.0 ---
**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:** [June 15, 2020, 8:19pm UTC](https://community.letsencrypt.org/t/dns-problem-servfail/125892/2 "2020-06-15T20:19:42Z")
Hi @Krasax > [@Krasax](#): > > Detail: DNS problem: SERVFAIL looking up CAA for nepheli.ydns.eu - > the domain’s nameservers may be malfunctioning that looks interesting. Unboundtest reports a Servfail - [https://unboundtest.com/m/CAA/nepheli.ydns.eu/KMDBT7JV](https://unboundtest.com/m/CAA/nepheli.ydns.eu/KMDBT7JV) but the reason is unclear, there are some bogus results: > Jun 15 20:00:21 unbound[1025:0] info: validated DNSKEY ydns.eu. DNSKEY IN > Jun 15 20:00:21 unbound[1025:0] info: validate(nodata): sec\_status\_bogus My tool doesn't see an error - [https://check-your-website.server-daten.de/?q=nepheli.ydns.eu](https://check-your-website.server-daten.de/?q=nepheli.ydns.eu) in the ydns.eu zone: > Status: Valid Chain of trust. Parent-DS with Algorithm 13, KeyTag 42554, DigestType 2 and Digest "lc9T1RFKJ7XnmfX2lWE76vZQ33Bq+VcdwK3MX5luq0w=" validates local Key with the same values, Key ist Secure Entry Point (SEP) of the zone but the zone is the same, so that zone is signed. The Versign dnssec check is happy - [DNSSEC Analyzer - nepheli.ydns.eu](https://dnssec-analyzer.verisignlabs.com/nepheli.ydns.eu) - all is green. DNSViz [nepheli.ydns.eu | DNSViz](https://dnsviz.net/d/nepheli.ydns.eu/dnssec/) has one thing, may be the problem - the DNSKEY of the `ydns.eu` zone has only 512 bit, may be too short. Checking directly the main domain - [https://check-your-website.server-daten.de/?q=ydns.eu](https://check-your-website.server-daten.de/?q=ydns.eu) - the CAA is signed. > RRSIG Type 257, expiration 2020-06-25 00:00:00 validates the CAA - Result: [5|issueletsencrypt.org](http://5%7Cissueletsencrypt.org) Yep, it's always the same: > Jun 15 20:00:23 unbound[1025:0] info: query response was ANSWER > Jun 15 20:00:23 unbound[1025:0] info: validated DNSKEY ydns.eu. DNSKEY IN > Jun 15 20:00:23 unbound[1025:0] info: validate(nodata): sec\_status\_bogus Looks like the DNSKEY is too small. PS: No, that's wrong. That's an Algorithm 13, so it's a EC key, P-256 is used, so it's a 256 bit public key. ---
**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:** [June 15, 2020, 8:42pm UTC](https://community.letsencrypt.org/t/dns-problem-servfail/125892/3 "2020-06-15T20:42:53Z")
That looks wrong: ![2020-06-15.nepheli.ydns.eu](https://global.discourse-cdn.com/letsencrypt/original/3X/f/e/fecd662ebcb2527e373121f10c4a5bb0ec04f3f2.png) First rechecked with my own Unbound-instance: > [1592253126] libunbound[24588:0] info: validate(nodata): sec\_status\_bogus > nepheli.ydns.eu. has no CAA record (BOGUS (security failure)) > validation failure \: nodata proof failed from 2a00:1328:e000:504::1:104 and 217.115.6.76 The first validated RRSIG says: The domain name `nepheli.ydns.eu` exists and has that A-record. But if that domain name exists and if no CAA RR exists, there is a NoData proof required (not a NXDomain proof). But the NSEC > RRSIG Type 47, expiration 2020-06-25 00:00:00 validates the NSEC RR that proves the not-existence of the CAA RR. Owner neoxnet.ydns.eu, NextOwner: nerd.ydns.eu. isn't a NoData proof, it's a NXDomain proof. NoData -\> the owner of the NSEC must be nepheli.ydns.eu. neoxnet.ydns.eu \< nepheli.ydns.eu \< nerd.ydns.eu --\>\> nepheli.ydns.eu doesn't exist. So the zone NSEC3 list may be incomplete. PS: Yep, rechecked manual. get-DNS:nepheli.ydns.eu CAA+ ns1.ydns.io|6|2a00:1328:e000:504::1:104 sends a NoData-answer (NoError) and a NSEC that proves NXDomain. ---
**Author:** ![Krasax](https://avatars.discourse-cdn.com/v4/letter/k/a9a28c/32.png) [@Krasax](https://community.letsencrypt.org/u/Krasax)\ **Post date:** [June 18, 2020, 8:39am UTC](https://community.letsencrypt.org/t/dns-problem-servfail/125892/4 "2020-06-18T08:39:37Z")
Thank you very much for your time and the long reply. I have to say, I understood only a part of what you were saying. So if I get you right, it tries to confirm that nepheli.ydns.eu is the owner of the domain nepheli.ydns.eu. However, in the list it looks up (is this the zone NSEC3 list?) there’s neoxnet.ydns.eu and nerd.ydns.eu with nepheli.ydns.eu missing (which I guess should be in-between them). Is this a problem of the configuration of my server? Or of the DNS-provider? What can I do to solve that problem? ---
**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:** [June 18, 2020, 9:32am UTC](https://community.letsencrypt.org/t/dns-problem-servfail/125892/5 "2020-06-18T09:32:01Z")
> [@Krasax](#): > > So if I get you right, it tries to confirm that nepheli.ydns.eu is the owner of the domain nepheli.ydns.eu. However, in the list it looks up (is this the zone NSEC3 list?) there’s neoxnet.ydns.eu and nerd.ydns.eu with nepheli.ydns.eu missing (which I guess should be in-between them). DNSSEC has a concept of "not existing proofs". That's complex. Check Authenticated Denial of Existence in the DNS > **[RFC 7129: Authenticated Denial of Existence in the DNS](https://datatracker.ietf.org/doc/html/rfc7129)** > > Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists but does not have the specific resource record (RR) type you were asking for. When... > [@Krasax](#): > > Is this a problem of the configuration of my server? Or of the DNS-provider? > What can I do to solve that problem? It's not your server, it's your dns provider. The dns software of the ydns.eu - zone needs an update. I've updated my tool - [https://check-your-website.server-daten.de/?q=nepheli.ydns.eu](https://check-your-website.server-daten.de/?q=nepheli.ydns.eu) ![2020-06-18.nepheli.ydns.eu](https://global.discourse-cdn.com/letsencrypt/original/3X/4/9/492b18103be9da280802e9cad2027a51189dcffc.png) But it looks like a subdomain service, so the owners of `ydns.eu` have to update their software. If not, you can't create a certificate. If there is a CAA record, only the listed CAs are allowed to create certificates. If there is no CAA record, every CA can create a certificate. But in combination with DNSSEC that requires a correct authenticated denial of the existence of the CAA record. The RRs sent from the dns software aren't correct. PS: Ask there and send them a link to this topic. ---
**Author:** ![Krasax](https://avatars.discourse-cdn.com/v4/letter/k/a9a28c/32.png) [@Krasax](https://community.letsencrypt.org/u/Krasax)\ **Post date:** [June 18, 2020, 1:32pm UTC](https://community.letsencrypt.org/t/dns-problem-servfail/125892/6 "2020-06-18T13:32:02Z")
Since the problem was at the DNS provider, I figured the quickest solution is to change them. Now everything works properly. Thanks again for your help! ---
**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:** [June 18, 2020, 1:39pm UTC](https://community.letsencrypt.org/t/dns-problem-servfail/125892/7 "2020-06-18T13:39:57Z")
> [@Krasax](#): > > I figured the quickest solution is to change them Yep. Some of these DNSSEC things are very old. If a dns provider doesn't support these, that's bad. PS: Same with dns providers with missing or wrong CAA support. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [July 18, 2020, 1:40pm UTC](https://community.letsencrypt.org/t/dns-problem-servfail/125892/8 "2020-07-18T13:40:01Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.