We would like to use let’s encrypt certs on a domain where we use “dns loadbalancing” where the main record (on Route53) is a NS record pointing at each of our gateway’s that in turn run a DNS server pointing at itself.
When running: certbot certonly --manual --preferred-challenges dns -d $DOMAIN -m $EMAIL --keep-until-expiring
We get error:
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: <domain>
Type: connection
Detail: DNS problem: query timed out looking up TXT for
_acme-challenge.<domain>
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
Seems to me that let’s encrypt is not following the NS records and doing another lookup there. Could this be the issue? Any way to work around it? Webroot seems to be failing for the same reason (unable to resolve ).
Hmmm… The error suddenly changed from a connection error to unauthorized.
Press Enter to Continue
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. next.taghub.net (dns-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: No TXT record found at _acme-challenge.next.taghub.net
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: next.taghub.net
Type: unauthorized
Detail: No TXT record found at _acme-challenge.next.taghub.net
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
next.taghub.net. 30 IN NS 34.248.70.255.
next.taghub.net. 30 IN NS 35.187.183.44.
NS records are supposed to be hostnames, but aside from that…
I’m pretty sure one or both of those nameservers usually drops queries, and one or both of them doesn’t support case randomization, which causes the resolver to retry and make more queries. Bad in isolation, very bad in combination.
That's also a critical issue, but the Let's Encrypt error in your first post was on the _acme-challengeTXT query.
(Not supporting a record type should never be a thing. DNS servers should have a valid negative response to queries for unknown record types. Additionally, any DNS server with RFC 3597 input has been able to serve actual CAA records since about 2002.)