LE DNS still doesn't find TXT record when all others tested do

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

LE DNS still doesn't "find" the TXT record when a new one is created.

I have added a TXT record in fw-1b.fast.za.net, yet LE's server don't find the record even after 20 minutes.

DNZViz really does not like your DNS and that's often a sign of problems with DNSSEC: _acme-challenge.fw-1b.fast.za.net | DNSViz

6 Likes

Is DNSSEC a requirement for LE to be able to issue a certificate? Surely that's a little over the top?

No, DNSsec is not a requirement for LE to issue a certificate. However, if DNSsec is configured, then it must be properly done.

5 Likes

All I can see in the DNSViz analysis is that DNSSEC is not there... I don't see any errors per se. What is it that you see that's incorrectly configured?

Can you show the error message exactly? Is it still that NXDOMAIN you got earlier as a result of faulty DNS delegation?

The https://unboundtest.com site queries DNS similar to LE and it sees a TXT record (now anyway). The dnsviz report is hard (for me) to interpret as using it for TXT records gives different results than for A/AAAA queries.

You could try using unboundtest to check the TXT record(s) and see if a new one shows up for a new request.

4 Likes

I don't get an error message per se. I use the acme.sh script and it just keeps on trying to read the records for 20 minutes until it times out.

The script tries to read https://cloudflare-dns.com/dns-query?name=_acme-challenge.fw-1b.fast.za.net&type=TXT which gives http error 400, so that doesn't work. Strangely enough, it does work for other domains with DNSSEC.

Oh, that sounds like a better problem to ask about on the Cloudflare community.
https://community.cloudflare.com/

They will know better how that HTTPS lookup should work. I am guessing that lookup is being done by the acme.sh Cloudflare plugin. Yes?

You might try disabling that pre-check in acme.sh. Ideally with a short delay before submitting request to LE after setting up that TXT record. I don't know how to do that off-hand in acme.sh.

2 Likes

Nope, it's part of the regular acme.sh TXT lookup. Cloudflare just happens to be the default if it works. (acme.sh/acme.sh at eaf11009d1d93513e6a3d3a962bc6efbd3a2803b · acmesh-official/acme.sh · GitHub -> acme.sh/acme.sh at eaf11009d1d93513e6a3d3a962bc6efbd3a2803b · acmesh-official/acme.sh · GitHub -> acme.sh/acme.sh at eaf11009d1d93513e6a3d3a962bc6efbd3a2803b · acmesh-official/acme.sh · GitHub)

That said, the "check to see if that CF site works" is just GET-ting the main site and not actually checking the functionality. And currently it doesn't do much. It can't even resolve google.com: https://cloudflare-dns.com/dns-query?name=google.com&type=A.

You can probably force use of a different DNS resolver company by setting the environment variable $DOH_USE. E.g. for Google it needs to be set to "2":

export DOH_USE=2

And see if that works.

I don't know how to disable the cloudflare lookup, but....
If disable the lookup completely, by using --dnssleep 300 on my acme.sh command, it waits for 300 seconds and then LE's servers only find the old records, not the new one.

After more than an hour, the old records are still there and the new one not.

Type

In your terminal before running acme.sh and I believe it should use Google instead of Cloudflare for the lookup test.

Why are there any old TXT records?
[they are NOT reuseable]

3 Likes

The script timed out and I killed it so I can check how long it takes to propagate the records. Yes, I understand they're not reusable, but I'm trying to see where the problem is.

I see the records are now gone when I do a lookup.

I changed it to google and it validates within seconds, but then LE's server don't find the record.

[Fri Oct  4 19:28:07 SAST 2024] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Fri Oct  4 19:28:07 SAST 2024] Using pre-generated key: /tmp/acme/Primary/fw-1b.fast.za.net_ecc/fw-1b.fast.za.net.key.next
[Fri Oct  4 19:28:07 SAST 2024] Generating next pre-generate key.
[Fri Oct  4 19:28:07 SAST 2024] Single domain='fw-1b.fast.za.net'
[Fri Oct  4 19:28:10 SAST 2024] Getting webroot for domain='fw-1b.fast.za.net'
[Fri Oct  4 19:28:10 SAST 2024] Adding TXT value: GMfRMxCtVG5GNMTRdiWXozMan0YsYRGmzyOfMqto3qI for domain: _acme-challenge.fw-1b.fast.za.net
[Fri Oct  4 19:28:10 SAST 2024] Using miab challenge add
[Fri Oct  4 19:28:22 SAST 2024] Successfully created the txt record
[Fri Oct  4 19:28:22 SAST 2024] The TXT record has been successfully added.
[Fri Oct  4 19:28:23 SAST 2024] Let's check each DNS record now. Sleeping for 20 seconds first.
[Fri Oct  4 19:28:44 SAST 2024] You can use '--dnssleep' to disable public dns checks.
[Fri Oct  4 19:28:44 SAST 2024] See: https://github.com/acmesh-official/acme.sh/wiki/dnscheck
[Fri Oct  4 19:28:44 SAST 2024] Checking fw-1b.fast.za.net for _acme-challenge.fw-1b.fast.za.net
[Fri Oct  4 19:28:50 SAST 2024] Success for domain fw-1b.fast.za.net '_acme-challenge.fw-1b.fast.za.net'.
[Fri Oct  4 19:28:50 SAST 2024] All checks succeeded
[Fri Oct  4 19:28:50 SAST 2024] Verifying: fw-1b.fast.za.net
[Fri Oct  4 19:28:51 SAST 2024] Pending. The CA is processing your order, please wait. (1/30)
[Fri Oct  4 19:28:55 SAST 2024] fw-1b.fast.za.net: Invalid status. Verification error details: During secondary validation: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.fw-1b.fast.za.net - check that a DNS record exists for this domain
[Fri Oct  4 19:28:55 SAST 2024] Removing DNS records.
[Fri Oct  4 19:28:55 SAST 2024] Removing txt: GMfRMxCtVG5GNMTRdiWXozMan0YsYRGmzyOfMqto3qI for domain: _acme-challenge.fw-1b.fast.za.net
[Fri Oct  4 19:28:55 SAST 2024] Using miab challenge delete
[Fri Oct  4 19:28:56 SAST 2024] Successfully removed the txt record
[Fri Oct  4 19:28:56 SAST 2024] Successfully removed
[Fri Oct  4 19:28:56 SAST 2024] Please check log file for more details: /tmp/acme/Primary/acme_issuecert.log

This means the primary validation (from the US) succeeded. However, some or all of the secondary validation attempts did not succeed. And they partly from all over the world.

This could be due to a few things, e.g.:

  • your DNS provider needs more time to propogate all the changes to their world wide instances of their nameservers;
  • or your DNS provider might be geoblocking specific regions, but that is rare.
3 Likes

You have a very slow DNS sync problem with the "powerdns":

C:\>nslookup -q=soa fast.za.net ns1.box2.gtahardware.co.za | find "serial"
        serial  = 2024100408

C:\>nslookup -q=soa fast.za.net puck.nether.net | find "serial"
        serial  = 2024100408

C:\>nslookup -q=soa fast.za.net powerdns.fast.za.net | find "serial"
        serial  = 2024100406
7 Likes

Hmm... I have nver considered that a secondary may be different from the primary... Let me check that out, thanks.

1 Like

If you have it wait... long enough:

C:\>nslookup -q=soa fast.za.net puck.nether.net | find "serial"
        serial  = 2024100408

C:\>nslookup -q=soa fast.za.net ns1.box2.gtahardware.co.za | find "serial"
        serial  = 2024100408

C:\>nslookup -q=soa fast.za.net powerdns.fast.za.net | find "serial"
        serial  = 2024100408

They eventually do sync up.

3 Likes

Do you have any advice on how I could coax PowerDNS to be propagate faster? Do I tell MIAB to do that (ie push a record change to PowerDNS or does PowerDNS pull this?

I'm asking here instead of elsewhere, since we're having the discussion although this is technically not an LE problem.