Error when validating challenge: DNS problem: SERVFAIL looking up A for

I try to renew my domain, but it fails strangely with a SERVFAIL by the Let’s Encrypt Resolver, but all the resolvers I try seem to work?!

$ ./dehydrated -c
ERROR: Challenge is invalid! (returned: invalid) (result: {
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:connection",
    "detail": "DNS problem: SERVFAIL looking up A for",
    "status": 400
  "uri": "",
  "token": "tj4TIoNFqV-jUz_Kv1JxpPLd1wnJ4_v6IbU94kj9piw",
  "keyAuthorization": "tj4TIoNFqV-jUz_Kv1JxpPLd1wnJ4_v6IbU94kj9piw.SVhEum_QaZCKSX7v_YNJlXKG_T86ConV_Eeos2vWTLY",
  "validationRecord": [
      "url": "",
      "hostname": "",
      "port": "80"

For example:|type=domain&&

Also Google and Quad9 Resolvers seem to work just fine.

Anyone can point me what could be the issue here?



I'm not sure whether this is the actual reason for the failure, but there is are DNSSEC errors (as opposed to warnings) reported by | DNSViz The DS RRset for the zone included algorithm 8 (RSASHA256), but no RRSIG with algorithm 8 covering the RRset was returned in the response. (,, 2a01:4f8:200:2265::2, 2a03:b0c0:0:1010::fb:8001, UDP_0_EDNS0_32768_4096)

Maybe Let's Encrypt's Unbound resolver is set to super strict DNSSEC evaluation.


That seems to be the case.

On Unbound 1.6.7/1.6.8, with "harden-algo-downgrade" off, I can resolve the zone; with it on, it fails.

        harden-algo-downgrade: <yes or no>
              Harden  against algorithm downgrade when multiple algorithms are
              advertised in the DS record.  If no, allows  the  weakest  algo-
              rithm  to  validate the zone.  Default is no.  Zone signers must
              produce zones that allow this feature  to  work,  but  sometimes
              they  do not, and turning this option off avoids that validation

@jsha could be updated with harden-algo-downgrade ?

So in order to fix this I have to actualy downgrade the algorithm from RSASHA512 to RSASHA256? I do not understand where the algorithm 8 (RSASHA256) comes from? Is that something my provider should have taken care of?

You have two DS records. One is algo 8 and one is algo 10.

$ dig ds

; <<>> DiG 9.10.3-P4-Ubuntu <<>> ds
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3459
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
;                        IN      DS

;; ANSWER SECTION:         86400   IN      DS      14869 8 2 3B9AB618951E346C3B7317AA8A497ADAC839663ACB15436F21809E8F 7B0162AE         86400   IN      DS      55857 10 2 20A94184C0B0F1D77E513FEEBBF36965AED0FE056F127A259D2CCF71 38AE37D9

;; Query time: 150 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Mar 21 09:42:37 UTC 2018
;; MSG SIZE  rcvd: 139

I'm out of my depth, but I guess you either need to remove the algo 8 DS record, or (bad idea) add an algo 8 DNSKEY and/or RRSIGs. Or switch entirely to algo 8.


I changed the dnssc settings at my provider from Algo 8 to 10 and the validation errors are gone and everything works fine.

Thank you very much, for kind help!


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