Intermittent "DNS problem: query timed out" (A/AAAA and CAA) affecting multiple domains on same authoritative NS — packet capture shows queries never arriving

Help
1

My domain is: makernet.com.br and espectro.net.br (both authoritative on the same nameservers)

I ran this command: HestiaCP's own Let's Encrypt integration (v-add-letsencrypt-domain), which drives the ACME v2 API directly.

It produced this output:

For makernet.com.br (repeated multiple times):

Error: Let's Encrypt validation status 400 (makernet.com.br). Details:
400:"DNS problem: query timed out looking up A for makernet.com.br;
DNS problem: query timed out looking up AAAA for makernet.com.br"

For espectro.net.br (order 3191901541, finalize step, HTTP 403):

{
  "type": "urn:ietf:params:acme:error:caa",
  "detail": "Error finalizing order :: rechecking caa: While processing CAA
  for espectro.net.br: DNS problem: query timed out looking up CAA for
  espectro.net.br",
  "status": 403
}

Timestamp: 2026-08-25T12:18:25Z

My web server is: nginx (behind HestiaCP)
OS: Ubuntu 22.04.5 LTS
Hosting: self-hosted, own ASN (AS52719), own authoritative BIND9 (dual NS, IPv4-only)
Root shell: Yes
Control panel: HestiaCP (latest)

What we've already ruled out: named/BIND9 healthy and fast (<1ms) for every query we could observe via tcpdump; no firewall/fail2ban blocking; DHCP secondary IP has a stable MAC reservation; BGP visibility of our /24 is near-universal (324/326 RIS peers); clean zero-loss traceroute to a live AWS/CloudFront IP; during the exact failure window, dozens of legitimate queries from Google, Cloudflare, and 5 distinct AWS IPs got correct sub-millisecond answers — but the specific CAA query that caused the 403 never shows up anywhere in that same capture, despite covering its exact timestamp.

Question for the community/staff: Given multi-perspective validation, is it possible to tell which specific validation perspective/network failed for order 3191901541 (finalize at 2026-08-25T12:18:25Z)? That would let us narrow down which network path to escalate with our upstream transit provider.

2

The domains seem to be using Cloudflare, is this a recent change?

3

https://unboundtest.com/ is pretty helpful with problems like this.

LE will check AAAA first and stop right there if thats not correct so Id double check that, it also checks via both TCP and UDP do make sure your DHCPd is on both.

Also look at why:
dig @jocelyn.ns.cloudflare.com espectro.net.br. CAA
vs
dig @jocelyn.ns.cloudflare.com makernet.com.br. CAA

is happening, like @MaxHearnden said if it very new could be prapogation?

And check your auth svrs, seems like makernet still wants ns1.makernet...

OT: Provider's give out ASNs for /24s? With classless and not having to have your upstream have the greater /22, /20, etc seems like a great way to make BGP explode in size :confused: