TXT record is updated but manual verification fails

LE always gets the latest value when it checks it doesn't cache anything?

Are there linux commands to show the type of information on bgp.tools like anycast tags?

the domain

How does LE verify the TXT records? Does it wait until all name servers from dig -t NS <your-domain> have been propagated or does it check all of them and verify that any one of them has it?

Each perspective will use one name server, having multiple perspectives means that multiple name servers are queried. This means that all your name servers need the record in order for the challenge to succeed.

In addition to what Max said ...

No, LE does not wait. As soon as your manual auth hook returns, Certbot will send the "cert request" to LE for validation. The LE primary center checks first and if successful the secondary centers will check. There are currently 5 centers total.

If the error message indicates "Secondary ..." it passed the primary but failed one or more of the secondary.

If you leave too many TXT records behind it can result in LE not seeing any due to excessive packet size. Make sure you aren't accumulating them.

What is perspective in LE?

If dig -t NS <your-domain> has 3 NS records, there will be 15 checks (5 centers x 3 name servers) and all need to see the TXT record?

A Let's Encrypt perspective just means one of its validation centers around the world. It's called multi-perspective validation per the industry standard specs.

Each of the centers randomly choose a single path when walking your DNS authoritative tree. It is statistically likely that different paths will be walked from each center (or at least some variation).

Each center must see a correct value from whatever path it chose. Actually, currently one secondary center is allowed to fail but not sure if that includes wrong TXT values seen or only things like comms timeouts. That shouldn't matter for what you are doing anyway

You know, it is incredibly difficult and time-consuming to help with such generic info. You probably would have been done by now had you instead changed your DNS provider at your registrar to something like Cloudflare :slight_smile:

Sorry Cloudflare is not the answer for everything in technology.

People should understand things and LE should add technical details from topics like this to their documentation to help with that instead of encouraging the internet to send Cloudflare their unencrypted traffic and centralize the internet more.

No, which is why literally hundreds of DNS providers are well supported by various ACME Clients.

Cloudflare is well-documented, works well at scale, and supported by many ACME Clients. We often recommend it when someone is struggling with their provider. You don't have to use their CDN, you can just use them as a DNS provider.

It's hard to know what you are struggling with exactly because you are fairly opaque about your specific problems. If you add the needed TXT records so they can be viewed world-wide using any of your authoritative DNS servers it should be fine.

A couple other tools for your DIY effort are below.

Another possible option for you would be to use the interactive manual cert request until the dns-persist-01 option becomes available.

In short, you add a TXT record once to your DNS that persists for multiple challenges - even indefinitely. See: DNS-PERSIST-01: A New Model for DNS-based Challenge Validation - Let's Encrypt

It is only available in Let's Encrypt's Staging system today. Hopefully the standards will evolve enough to allow it to roll out soon. Once it is available in production expect it to be supported by at least some ACME Clients. There has been much talk and excitement about this new challenge. That said, I haven't heard how rapidly the EFF plans to get it added to Certbot. Sometimes Certbot is further behind other clients in adding new features.