# \_acme-challenges mismatch from dns-rfc2136 **URL:** \ **Category:** Help\ **Created:** [March 13, 2020, 10:36pm UTC](https://community.letsencrypt.org/t/acme-challenges-mismatch-from-dns-rfc2136/116334 "2020-03-13T22:36:13Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Alex\_HQuest](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/alex_hquest/32/3347_2.png) [@Alex\_HQuest](https://community.letsencrypt.org/u/Alex_HQuest)\ **Post date:** [March 13, 2020, 10:36pm UTC](https://community.letsencrypt.org/t/acme-challenges-mismatch-from-dns-rfc2136/116334/1 "2020-03-13T22:36:13Z")
While trying to issue a wildcard certificate to a domain, using DNS-RFC2136 (BIND) plugin in a “certonly” request, [certbot](https://certbot.eff.org/) registers two TXT \_acme-challenge entries on my DNS server, and none matches the ACME challenge expected by the server. Therefore it fails verification. This is happening with both the dns-rfc2136 plugin and a manual hook I’ve been happily using for the past 2+ years. My original certbot was an ancient 0.38 version, which was updated to 1.3.0 as part of a troubleshooting session. The “certupdate” command is just a wrapper script that does a few things prior and after the certificate is issued. It is my understanding wildcard certificates are only issued if requested with DNS challenge, so the HTTP based options are a no go for me. Any advices around this DNS challenge are welcome. **Certbot command - [certbot.log.txt](https://community.letsencrypt.org/uploads/short-url/cxbFdapzMh1yHRrdqDcznBrpE9v.txt) (218 Bytes)** **CLI output - [certbot\_cli.log.txt](https://community.letsencrypt.org/uploads/short-url/tZOLnNkUnpQ8MRbQggJ59IBQNyl.txt) (1.1 KB)** **BIND logging DDNS output - [named\_ddns.log.txt](https://community.letsencrypt.org/uploads/short-url/ka7zKuiyUoc33c3p1lVVKaWCoa4.txt) (1.4 KB)** **BIND logging zone Xfer output - [named\_zone\_xfer.log.txt](https://community.letsencrypt.org/uploads/short-url/kPhFkbdBvb16u7ZLpcHuPl929T3.txt) (837 Bytes)** **letsencrypt.log logfile - [letsencrypt.log.txt](https://community.letsencrypt.org/uploads/short-url/vp9TVqMUBe7FLcBnyK2ma0cL8vx.txt) (30.0 KB)** ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [March 13, 2020, 10:46pm UTC](https://community.letsencrypt.org/t/acme-challenges-mismatch-from-dns-rfc2136/116334/2 "2020-03-13T22:46:42Z")
Looking at the authorization ([https://acme-staging-v02.api.letsencrypt.org/get/authz-v3/43595567](https://acme-staging-v02.api.letsencrypt.org/get/authz-v3/43595567)), we can see the error: > DNS problem: SERVFAIL looking up TXT for \_acme-challenge.hquest.pro.br - the domain's nameservers may be malfunctioning Running a test through any one of DNS testing sites ([Let's Debug](https://letsdebug.net/hquest.pro.br/112378)), we can see there's a problem with the DNSSEC configuration of the domain: > DNS response for hquest.pro.br had fatal DNSSEC issues: validation failure \: no keys have a DS with algorithm RSASHA1-NSEC3-SHA1 from 2001:470:100::2 for key hquest.pro.br. while building chain of trust ---
**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 13, 2020, 10:51pm UTC](https://community.letsencrypt.org/t/acme-challenges-mismatch-from-dns-rfc2136/116334/3 "2020-03-13T22:51:35Z")
According to their [website](https://dns.he.net/), Hurricane Electric’s DNS service doesn’t support DNSSEC. They’ve been “looking into” it for a long time. [That is not a criticism.] ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [March 13, 2020, 10:58pm UTC](https://community.letsencrypt.org/t/acme-challenges-mismatch-from-dns-rfc2136/116334/4 "2020-03-13T22:58:31Z")
“not supporting” and “having a misconfigured DNS server” are two different things @mnordhoff. A DNS server shouldn’t response with SERVFAIL. ---
**Author:** ![Alex\_HQuest](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/alex_hquest/32/3347_2.png) [@Alex\_HQuest](https://community.letsencrypt.org/u/Alex_HQuest)\ **Post date:** [March 13, 2020, 11:00pm UTC](https://community.letsencrypt.org/t/acme-challenges-mismatch-from-dns-rfc2136/116334/5 "2020-03-13T23:00:27Z")
HE does not support hosting master DNSSEC entries, however they work just fine as slave. And yep, seems there are more pressing concerns on my zone. Appreciated for the hints - assumed this piece was OK when it is not. ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [March 13, 2020, 11:10pm UTC](https://community.letsencrypt.org/t/acme-challenges-mismatch-from-dns-rfc2136/116334/6 "2020-03-13T23:10:50Z")
A post was split to a new topic: [DNS-01 problem with dehydrated](https://community.letsencrypt.org/t/dns-01-problem-with-dehydrated/116338) ---
**Author:** ![Alex\_HQuest](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/alex_hquest/32/3347_2.png) [@Alex\_HQuest](https://community.letsencrypt.org/u/Alex_HQuest)\ **Post date:** [March 13, 2020, 11:15pm UTC](https://community.letsencrypt.org/t/acme-challenges-mismatch-from-dns-rfc2136/116334/7 "2020-03-13T23:15:39Z")
After fixing the DS record on my upstream provider for this domain, and let a few minutes for the propagation to do its magic, I have it all set now, with brand new/renewed certificates! Thank you @_az for the hint of the [letsdebug](https://letsdebug.net/) website - added it to my links arsenal. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [April 12, 2020, 11:15pm UTC](https://community.letsencrypt.org/t/acme-challenges-mismatch-from-dns-rfc2136/116334/8 "2020-04-12T23:15:42Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.