Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
Detail: During secondary validation: DNS problem: server failure at resolver looking up A for www.bfopcu.eg.net; DNS problem: server failure at resolver looking up AAAA for www.bfopcu.eg.net
Detail: During secondary validation: DNS problem: SERVFAIL looking up A for www.jadm.eg.net - the domain's nameservers may be malfunctioning; DNS problem: SERVFAIL looking up AAAA for www.jadm.eg.net - the domain's nameservers may be malfunctioning
I don't see any issues when I do a "dig +trace " either.
This means the main dns query succeeds. The secondary ones don't. Are you using some kind of firewall in front of your dns servers? Some kind of geoblocking or ratelimiting, perhaps?
We are not using any firewall in front of our DNS servers. But our DNS servers are for 'bepress.com'.
The hostname 'www.bfopcu.eg.net' points to a CNAME record of 'dcbfopcu.bepress.com'. We control the name server for 'bepress.com'. We host the web site 'www.bfopcu.eg.net', which is why we're trying to obtain an SSL cert for it. We've been successful getting the cert in the past; we're trying to do a renewal for it.
How am I to determine which of the secondary LE datacenters is having a problem resolving the DNS and exactly what the nature of the problem is? Is it that it can't reach the DNS servers "ns.eunet.eg.net (195.43.0.49)" and "ns1.eunet.eg.net (195.43.0.51)"?
The only thing I can see is what's in our certbot logs.
You should try again to see if the problem goes away. Failing that, you can play with unboundtest.com until you get a failure log (it won't fail every time, it might not fail at all).
Regarding the Authoritative AAAA records exist for ns-433.awsdns-54.com, but there are no corresponding AAAA glue records. in DNSViz, Check that ns-433.awsdns-54.com on AWS is indeed still supposed to be one of your domains nameservers, or possibly consider removing it temporarily because according to DNS vis it's not responding as expected to AAAA record queries (that's my interpretation, could be wrong), or check with AWS support.
I assume you are trying to perform DNS domain validation for your certificate, not HTTP domain validation (you have multiple IPs so http validation likely wouldn't work).
Do they have any other domain names using that name server that CNAME to you? That is, do any of them work?
Let's Encrypt walks the DNS tree from the root to the end result using the authoritive name servers as they are found. And, if DNSSEC is enabled it checks that.
I wasn't able to reproduce the problem with https://unboundtest.com. That more often means there is some sort of rejection happening due to the larger volume, the origin, or the types of DNS queries that LE makes. But, just usually not always.
Still, it looks like there might be some problems in the eg.net tree per dnsviz. And, also some possible problems in the DNSSEC for that tree too. I am not expert at this tool but it is why I asked if DNSSEC is new to their tree EDNS Compliance Tester
As an aside, have you always used two EC2 IPs to satisfy the HTTP Challenge. Because that takes some care so that either one can respond properly. It looks like an HTTP Challenge because the error message indicates problems looking up A / AAAA records which are not needed for a DNS Challenge. That wouldn't cause the DNS query failures ... I am just curious.
