"ocsp.int-x3.letsencrypt.org could not be resolved" error: NXDOMAIN issue with

Issuance Tech
1

I receive the occasional “ocsp.int-x3.letsencrypt.org could not be resolved (110: Operation timed out) while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org” error. After reviewing the previous topics related to this in the Community Forum, I ascertained that none of the issues/solutions were pertinent to the problem.

Investigating further using DNS Viz, I found there are multiple issues, 2 errors and 7 warnings. See link.

The two errors are:

ocsp.int-x3.letsencrypt.org.edgesuite.net/CNAME: A query for ocsp.int-x3.letsencrypt.org.edgesuite.net results in a NOERROR response, while a query for its ancestor, org.edgesuite.net, returns a name error (NXDOMAIN), which indicates that subdomains of org.edgesuite.net, including ocsp.int-x3.letsencrypt.org.edgesuite.net, don’t exist. (2.16.130.64, 2.22.230.64, 23.61.199.64, 23.211.133.64, 84.53.139.64, 84.53.139.65, 95.100.168.64, 95.100.173.64, 95.101.36.64, 96.7.49.64, 96.7.49.65, 184.26.160.64, 184.26.161.67, 184.85.248.64, 184.85.248.65, 193.108.91.2, 2600:1401:1::40, 2600:1401:2::2, 2600:1408:1c::40, 2600:1480:1::40, 2600:1480:800::40, 2600:1480:b000::40, 2a02:26f0:117::40, UDP_0_EDNS0_32768_4096)

org/DNSKEY: No response was received from the server over UDP (tried 4 times). (2001:500:b::1, UDP_0_EDNS0_32768_512)

The warnings, which can be seen in detail at the link above, relate to UDP payload size, missing AAAA glue records and NS names found in the authoritative NS RRset, but not in the delegation NS RRset.

Perhaps the errors I see on occasion may relate to these problems. Thought someone might want to investigate.

Thanks,
Terry

2

Hi, Terry,

I think the DNSViz issues you found are unrelated to your resolution timeouts.

The error with the CNAME on ocsp.int-x3.letsencrypt.org.edgesuite.net is a consequence of Akamai’s authoritative DNS implementation. This breaks that hostname’s resolution for resolvers that use strict QNAME minimisation (RFC 7816), but that’d be a persistent problem, not sporadic. We first identified this last year and have been following up with Akamai to get it fixed.

The error fetching DNSKEY over UDP from the .org root servers is something I see often on DNSViz - for many domains - and I’ve never been able to replicate it. The same goes for the UDP payload size warning. I think it’s a quirk of their testing servers’ connectivity.

The other warnings are best practices issues but shouldn’t affect resolution at all.

Unfortunately, in order to figure out what’s going on, I think we’ll need some deeper troubleshooting of your DNS resolver(s) at the moment when a timeout happens. What resolvers are you using?

1 Like
3

In retrospect, this is almost certainly a consequence of

https://letsencrypt.status.io/pages/incident/55957a99e800baa4470002da/5b5f5aa93a343f54d7982864

4

They've been saying that so many years someone made a meme:

5

We just got word earlier today that Akamai has fixed their compatibility with strict QNAME minimisation, and I have verified it. :confetti_ball:

2 Likes
6

OH MY GOD YOU HAVE MAGIC POWERS!

4 Likes
7

Also FYI to everybody looking at Akamai QNAME minimization issue and using Unbound DNS resolvers: Unbound versions at least 1.7.1 and 1.7.2 had a bug in QNAME minimization feature that got triggered with Akamai’s CDN domains. Upgrade to Unbound 1.7.3 to fix the QNAME minimization bug.

2 Likes
8

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