We are currently unable to issue or renew any certificates across our entire subnet. The issue persists across every single IP in this block. It seems like our IPs (specifically our Authoritative DNS servers hosted on this subnet) might be blocked at the Akamai WAF level or by Let's Encrypt's routing rules.
Here are our network details:
ASN: AS214584
Subnet: 178.253.225.0/24
We are getting DNS timeout errors for all domains pointing to name servers on this subnet. Here is the exact error log for one of the domains:
"detail': 'DNS problem: query timed out looking up A for autodiscover.emintrinsic.com; DNS problem: query timed out looking up AAAA for autodiscover.emintrinsic.com', 'status': 400"
We checked our edge routers and internal firewalls, and there are no rules dropping Let's Encrypt validation traffic (Port 53 or Port 80) on our end.
Could you please check your Unbound DNS / Akamai firewall logs for this subnet to see if our ASN is blacklisted?
I ran Let's Debug against autodiscover.emintrinsic.com and it reproduces it: the staging test authorization fails with the same "query timed out looking up A / AAAA", while public resolvers (Google, Cloudflare) get 178.253.225.50 from lin1/lin2.nethub.com.tr without any trouble. So the nameservers do answer in general, just not to the queries coming from Let's Encrypt.
Let's Encrypt doesn't publish its validation IPs and validates from several network perspectives, so the usual culprit is something on the path that filters by source: response rate limiting on the DNS server, geo/anti-DDoS filtering at the upstream, or an ACL in the DNS daemon itself.
Two quick checks: run a Let's Debug test and watch whether those queries even reach 178.253.225.194/.195 (query log or tcpdump on port 53), and query them from a VM outside your network and country:
dig @178.253.225.194 autodiscover.emintrinsic.com A +dnssec
dig @178.253.225.194 autodiscover.emintrinsic.com A +tcp
If the queries never show up in your logs, it's being dropped upstream before it reaches you.
The error is for querying your authoritative DNS servers for A and/or AAAA records. What rules did you look for that would be unique to Let's Encrypt DNS queries? They are standards-compliant DNS queries.
We can tell from the error and confirmed by the Let's Debug test that the failure is from the Let's Encrypt primary data center. Do you block traffic from certain larger networks? I believe from the primary center Let's Encrypt uses a Cloudflare commercial network. Could all such traffic be blocked near you?
You'll have to wait for someone from LE Staff to look at Unbound logs. They may not do that for problems at a single requesting location. I have never heard of the primary validation center to block ASNs nor have I heard it having an Akamai firewall blocking its own outbound traffic. Is Akamai involved on your side? Why do you mention it?
I don't see any certs issued by Let's Encrypt for any emintrinsic.com domain in the past 180 days. I see two from ZeroSSL and two by other issuers for your mail subdomain.
Do you have an example of a domain that was issued by Let's Encrypt? It might help isolate when the problem started. When did you first notice it?