Why doesn't LE's DNS find my TXT record when google DNS does?

[lifeboy]

My domain is: fw.fast.za.net
My hosting provider, if applicable, is: self-hosted MIAB.
I can login to a root shell on my machine (yes or no, or I don't know): Yes
The version of my client is: acme.sh v.3.0.8

When I attempt to renew the certifcate, the TXT record for _acme-challenge.fw.fast.za.net is created and validated by google's dns service (as part of the testing process that acme.sh performs). I can also validate that the TXT record is created by using the dig command. However, the LE DNS service doesn't find the record, even after more than 5 minutes.

What does LE DNS do differently than Google?

I set the ttl for the TXT record to 300s. Could that be too short? Surely too long could pose a problem, but too short not?

[Sun 25 Aug 2024 21:15:16 SAST] _j_str='{
  "identifier": {
    "type": "dns",
    "value": "fw.fast.za.net"
  },
  "status": "invalid",
  "expires": "2024-09-01T19:14:18Z",
  "challenges": [
    {
      "type": "dns-01",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/395024439436/xkLrMw",
      "status": "invalid",
      "validated": "2024-08-25T19:15:12Z",
      "error": {
        "type": "urn:ietf:params:acme:error:dns",
        "detail": "DNS problem: NXDOMAIN looking up TXT for _acme-challenge.fw.fast.za.net - check that a DNS record exists for this domain",
        "status": 400
      },
      "token": "9go9BeluKDOjHrWcYP7iejEOxMt7JWXlJBGWUIlmCWo"
    }
  ]
}'

[lifeboy]

Some more information:

When I use the DNS lookup tool (DNS InBrowser.App) to check a test TXT record I created, _testrecord.fw.fast.za.net, I get this using google dns:

{
  "Status": 3,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": false,
  "CD": false,
  "Question": [
    {
      "name": "_testrecord.fw.fast.za.net",
      "type": 16
    }
  ],
  "Authority": [
    {
      "name": "fast.za.net",
      "type": 6,
      "TTL": 86400,
      "data": "ns1.box2.gtahardware.co.za. hostmaster.box2.gtahardware.co.za. 2024082213 7200 3600 1209600 86400"
    }
  ]
}

But when I select Cloudflare, I get an error:

[Sun 25 Aug 2024 21:15:16 SAST] _j_str='{
  "identifier": {
    "type": "dns",
    "value": "fw.fast.za.net"
  },
  "status": "invalid",
  "expires": "2024-09-01T19:14:18Z",
  "challenges": [
    {
      "type": "dns-01",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/395024439436/xkLrMw",
      "status": "invalid",
      "validated": "2024-08-25T19:15:12Z",
      "error": {
        "type": "urn:ietf:params:acme:error:dns",
        "detail": "DNS problem: NXDOMAIN looking up TXT for _acme-challenge.fw.fast.za.net - check that a DNS record exists for this domain",
        "status": 400
      },
      "token": "9go9BeluKDOjHrWcYP7iejEOxMt7JWXlJBGWUIlmCWo"
    }
  ]
}'

[lifeboy]

Apologies. The post above has the Cloudflare response incorrect. Here is the actual response.

{
  "Status": 3,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": false,
  "CD": false,
  "Question": [
    {
      "name": "_testrecord.fw.fast.za.net",
      "type": 16
    }
  ],
  "Authority": [
    {
      "name": "fast.za.net",
      "type": 6,
      "TTL": 86400,
      "data": "ns1.box2.gtahardware.co.za. hostmaster.box2.gtahardware.co.za. 2024082213 7200 3600 1209600 86400"
    }
  ]
}

[MikeMcQ]

Let's Encrypt walks the DNS tree looking at the authoritative servers. Your DNS config has faulty delegation or nameserver config. This can lead LE to seeing a different answer to a query than resolver type query systems

The dnsviz.net test site shows your problem in graphic form. Also try https://unboundtest.com and repeatedly try a query. Each query may choose a different sequence of auth servers so each one must respond correctly.

https://dnsviz.net/d/fw.fast.za.net/dnssec/

Note especially this

[lifeboy]

Ah, that makes sense. Time too kick Namecheap's but again! This is not the first time this has happened!