DNS-01 challenge and rfc_dns_2136 authenticator and BIND issue

Server
1

DNS challenge failing: NXDOMAIN looking up TXT alludes to BIND setups that use internal and external views having issues and suggests the issues go away if using BIND 9.10 and above

I am using the split DNS way of defining an internal view and an external view in named.conf , each incorporating identical zones and so before I go upgrading the BIND program with a non-CentOS 7 or Fedora file, I want to see if anyone knows something better

I turned my DNS into an authoritative server and dropped the Google servers as the authoritarian resolvers.

I have not found anyone who has the rfc_dns_2136 authenticator working using the

certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /credentials.ini -d “*.xxxxxxx.com” -d xxxxxxx.com --server https://acme-v02.api.letsencrypt.org/directory

command which is the easiest and proper way to automate renewals for wildcard certs if one is using BIND - but the post above seems to show a bug.

Still from most posts I have seen no one has posted working authenticator and cleanup shell script either for the manual hook mode either.

Additionally it appears one must manually create an _acme-challenge.xxxxxxx.com domain and assign a key or there is a no SOA error in the var/log/letsencrypt log - and then presumably one needs a CNAME pointing to get the cert to issue without messing with the important zone one does not want to be dynamically screwed with.

I can see the delivery of the DNS-01 challenge TXT with a dig -t TXT _acme-challenge.xxxxxxx.com while the waiting period for propagation is happening and the var/log/letsencrypt log says it successfully writes the TXT record, but fails actually with a TXT not found and 403 error anyway.

Cleaning up challenges
Failed authorization procedure. xxxxxxxx.com (dns-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: No TXT record found at _acme-challenge.xxxxxxxx.com, xxxxxxx.com (dns-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: No TXT record found at _acme-challenge.xxxxxxx.com

The 403 is reported in the log, and this is a “generic” error

Does anyone have info that can be shared on this issue ??
or what a " urn:ietf:params:acme:error:unauthorized " error means ??
or . . . know of a definitive “step by step” setup guide using CNAMES and a dummy validation zone domain like this -> https://github.com/Neilpang/acme.sh/wiki/DNS-alias-mode but for the certbot client and can be used with the rfc_dns_2136 authenticator ??

2

The error message is just saying that there was no TXT record found when the validation server tried to query it.

With a split brain setup like you have, are you sure the TXT record is getting created in the external view? If the server is internal, it might also be writing the record only to the internal view.

3

Yes, no I know - BIND 9 - <= 9.10 has that problem - because when I remove the external view and restart the server the error message is then " DNS problem: SERVFAIL looking up TXT for _acme-challenge.xxxxxxx.com " - and this bug issue is documented in post 26 at DNS challenge failing: NXDOMAIN looking up TXT

I can see the TXT file with a DIG - and the solution which as documented that works is to use Google’s public server as documented in post 26 above - which originally is how I had it set up

The problem is the solution is to upgrade to BIND 9.11 - which is not available officially for CentOS 7, and I would have to use Fedora files - which would mean also having to install Python 3.4 - and possibly screw up the entire server

I am researching if upgrade to BIND 9.11 or above can safely be done on a Centos 7 box.

The problem then right now becomes needing to configure a Fedora repository so that yum will be able to keep the Centos 7 server up to date on the BIND and dependency files - and I am not sure what other files yum might see in the Fedora repo that it thinks are upgrades to the EL 7 or Centos 7 files

I could of course abandon the views setup for BIND - which might be the easiest thing to do

The real issue is that without a separate zone for _acme-challenge.xxxxxxx.com - the dns-rfc2136 authenticator will screw up the domain to be renewed by replacing all the subdomain DNS entries with a $ORIGIN command in place of the subdomain name.xxxxxxxx.com - and it still fails

AND the letsencrypt log shows a complaint about no SOA for _acme-challenge.xxxxxxx.com

Since there is already wildcard cert configured in place it seems it is what is actually causing the DNS fail

I am not sure I am setting up the CNAME configuration as shown at https://github.com/Neilpang/acme.sh/wiki/DNS-alias-mode for certbot so the rfc_dns_2136 authenticator can use it. That guide is of course for the acme.sh method.

Is there some way to troubleshoot that using the rfc_dns_2136 authenticator or does someone know how to do this as shown at Renew using dns-01 challenge as shown by sahsanu and schoen

should it be

xxxxxxxx.com. 14400 IN CNAME _acme-challenge.xxxxxxxx.com.

OR

_acme-challenge.xxxxxxxx.com. 14400 IN CNAME xxxxxxxx.com.

in the zone file of the domain to be renewed as to how the rest of the server is setup authenticated because it is not clear how to do this for a wildcard cert request??

Steps 1 and 2 at Renew using dns-01 challenge leaves me a bit confused on how to set up the rest of the server authentication process

4

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