DNS problem: SERVFAIL for DNSSEC signed domain

Issuance Tech
1

Howdy Crypters,

I’m encountering the following issue when trying to get a certificate for my DNSSEC signed domain (greenhat.ch).

acme: Error 0 - urn:acme:error:connection - DNS problem: SERVFAIL looking up A for laki.greenhat.ch

The domain resolution works perfectly fine globally (see whatsmydns.net) and the DNSSEC signing is done properly as verified with the DNSSEC-Debugger.

When trying to issue the certificate on the same server for another, non-dnssec signed record it works perfectly fine, so my conclusion is that there is something off with the DNSSEC resolution of the Let’s Encrypt ACME backend.

I’ve checked through the several DNS related issues here, but did not fine anything which is solely related to DNSSEC. Are you aware of any issue related to DNSSEC?

Thanks for your help.

2

I am seeing DNS issues for that domain.

If I check whois for your primary nameservers I get
lily.ns.cloudflare.com
theo.ns.cloudflare.com

If I try and query them for the IP address for your domain - I get a timeout
;; connection timed out; no servers could be reached

I’d guess that the one that worked fine wasn’t set up to use the cloudflare nameservers.

3

http://dnsviz.net/d/laki.greenhat.ch/dnssec/

I also found something intresting. you have a dead DS with algo 8 (probably from an old implementation, which is creating warnings.

1 Like
4

Checking your nameservers (lily.ns.cloudflare.com and theo.ns.cloudflare.com) they are now responding and returning the correct value.

5

If it might seem useful, my domain uses DNSSEC and I have had no problem with LE issuing. Therefore, I think that the issue here is unrelated with DNSSEC.

6

Was your domain also dnssec misconfigured ? Because here parent annonced a DS that do not exists. That can lead to dnssec validation failure and so to a SERVFAIL response.

That seems to have been corrected, but dsviz.net seems to always have the old DS in cache.

$ host -t DS greenhat.ch h.nic.ch
Using domain server:
Name: h.nic.ch
Address: 194.42.48.120#53
Aliases: 

greenhat.ch has DS record 2371 13 2 6049A9C0111CCEC801B71334C8478CA79409F35F476985A27661ED31 F829C2B9
1 Like
7

Indeed, the stale DS record was causing this issue. I’ve recently performed an change to cloudflare which of course involved adding a second DS record. I was not aware the several DS records can lead to validation errors as long there is a valid DS record given. Anyway, LE works fine now without the old DS record.

Thanks for your help!

Cheers,
Daniel

1 Like
8

looks weird. from a logical standpoint it should be fine if at least one DS matches.

9

There are two cases in which a stale DS record can lead to validation failure even though there are other DS records for current DNSKEY:

  1. By RFC 4509 section 3, the existence of any SHA-256 digest DS record for a domain (even a stale or otherwise invalid one) should force all SHA-1 digest DS records to be ignored.

  2. An implementation that supports only some DNSKEY algorithms (e.g. RSA family but not ECDSA family) can fail to validate a DNSSEC-signed domain which has a stale DS record for a supported algorithm, even though there is a valid DS record for a current DNSKEY if that DNSKEY uses an unsupported algorithm.

Case 2 probably applied here as there are still a number of implementations (e.g. Windows) that do not support the ECDSAP256 (type 13) algorithm used by CloudFlare.

10

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