Random DNS Problems getting Let’s Encrypt certificate

Help
1

Hello,

we have problems getting a Let’s Encrypt certificate for our GitHub Enterprise Server. The GitHub Enterprise Server includes the acme.sh script and tries to get the certificates for our GitHub Enterprise Server and a lot of it’s subdomains:

But the script fails at different (sub)domains with one of the following messages:

avatars.github.dev.cicd.bhs-world.com:Verify error:DNS problem: query timed out looking up A for avatars.github.dev.cicd.bhs-world.com; no valid AAAA records found for avatars.github.dev.cicd.bhs-world.com

maven.github.dev.cicd.bhs-world.com:Verify error:DNS problem: query timed out looking up CAA for bhs-world.com

maven.github.dev.cicd.bhs-world.com:Verify error:DNS problem: query timed out looking up A for maven.github.dev.cicd.bhs-world.com; DNS 

maven.github.dev.cicd.bhs-world.com:Verify error:DNS problem: SERVFAIL looking up CAA for github.dev.cicd.bhs-world.com - the domain's nameservers may be malfunctioning

npm.github.dev.cicd.bhs-world.com:Verify error:DNS problem: query timed out looking up CAA for dev.cicd.bhs-world.com

npm.github.dev.cicd.bhs-world.com:Verify error:DNS problem: query timed out looking up A for npm.github.dev.cicd.bhs-world.com; no valid AAAA records found for npm.github.dev.cicd.bhs-world.com

I think the GitHub Enterprise Server executes the following command:

sudo -u acme-client acme.sh --allow-sudo --syslog 6 --debug --config-home /tmp/tmp.acme-workdir.wfnqa2rFXY --issue --stateless -d github.dev.cicd.bhs-world.com -d assets.github.dev.cicd.bhs-world.com -d avatars.github.dev.cicd.bhs-world.com -d codeload.github.dev.cicd.bhs-world.com -d containers.github.dev.cicd.bhs-world.com -d docker.github.dev.cicd.bhs-world.com -d gist.github.dev.cicd.bhs-world.com -d maven.github.dev.cicd.bhs-world.com -d media.github.dev.cicd.bhs-world.com -d npm.github.dev.cicd.bhs-world.com -d nuget.github.dev.cicd.bhs-world.com -d pages.github.dev.cicd.bhs-world.com -d raw.github.dev.cicd.bhs-world.com -d render.github.dev.cicd.bhs-world.com -d rubygems.github.dev.cicd.bhs-world.com -d uploads.github.dev.cicd.bhs-world.com

Our Nameservers are:

bhs-world.com => Nameserver auth54.ns.de.uu.net. and auth04.ns.de.uu.net.

For cicd.bhs-world.com we have set the nameserver entries to ns3-03.azure-dns.org, ns4-03.azure-dns.info, ns2-03.azure-dns.net, ns1-03.azure-dns.com

For dev.cicd.bhs-world.com we have set the nameserver entries to ns1-08.azure-dns.com, ns3-08.azure-dns.org, ns2-08.azure-dns.net, ns4-08.azure-dns.info. Here we have the A-Records for github.dev.cicd.bhs-world.com and *.github.dev.cicd.bhs-world.com.

How to determine which of the involved DNS server is broken? Where is this DNS verification executed? It this done on my server or at Let’s Encrypt? A few days ago, after many many retries the certificate was created. But now when I try to get a new certificate I still run into this issues.

Thank you for your help!

Timon

1 Like
2

Sites like DNSViz can help. E.g., see avatars.github.dev.cicd.bhs-world.com | DNSViz.

At the Let's Encrypt validation server. Some ACME clients will do their own lookup before triggering the challenge at the LE validation server though. Not sure what your client does, but it looks like the errors come from the LE validation server.

6 Likes
3

Check all your nameservers are responding to both UDP and TCP queries. SERVFAIL is unacceptable because the process is trying to validate your DNS control and broken stuff isn't going to pass.

Also, acme.sh usually defaults to ZeroSSL as the CA, so double check Let's Encrypt is the actual CA being used.

As a guess I'd say the one or more DNS nameservers needs a restart, and my further guess would be that it's the servers higher up the chain towards bhs-world.com
DNS Viz seems particularly annoyed about auth54.ns.de.uu.net (194.128.171.100) not responding to TCP queries for some records and that seems to be intermittent across multiple attempts.

6 Likes
4

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