This may not be the correct "category" but I'm not sure where else to put it.
I wanted to reply in this thread to offer a solution to this persons issue that works for me, but it seems to be "closed" to further replies.
Anyway, my solution is, for each domain that I use LE for, to create a secondary NS record for the key to the challenge as this sample zonefile illustrates - it only lists the ONE nameserver for that "sub" domain. Yes, that isn't "compliant" with normal DNS expec
$ORIGIN ns1.domain.com.
@ IN SOA (with the normal zone SOA record data)
@ IN NS ns1.domain.com.
@ IN NS ns2.domain.com.
ns1 IN A 1.2.3.4
ns2 IN A 6.7.8.9
nsx IN A 1.2.3.4
_acme-challenge IN NS nsx.domain.com.
And then, I add a separate zone in the bind config, with a zonefile as follows - mostly an empty shell, but a very short TTL so when the authentication record is added it shows up very quickly.
Just as a heads up. TTL on validation records has nothing to do with how long it takes to get answers from secondary or even primary nameservers. It only affects how long recursive servers cache previously queried responses. But Let's Encrypt (and maybe all public CAs due to CAB rules?) don't query recursive resolvers for your validation records. They only query the authoritative nameservers.
So the "propagation delay" you're talking about is only the time it takes for the authoritative records to be transferred from the primary nameserver to the secondaries. That's generally controlled by the "refresh" value in the SOA record assuming you haven't configured other ways of speeding it up like DNS NOTIFY. There are also other DNS server solutions that allow for more or less instantaneous secondary updates through proprietary methods assuming all secondaries also run the same software.
Your solution works around the problem by only having a single nameserver for standalone zones associated with the validation record names. But it's not practical to implement at scale and shouldn't be necessary. You'd probably be better served by implementing DNS NOTIFY because then you gain the propagation benefits for all your records instead of just the ACME ones.
Yes, I'm aware of all that.. I do in fact have NOTIFY implemented, both between my master and the secondary I run myself, as well as the free secondary service I use.
I have less than a dozen zones, so this works for me. I wouldn't suggest that it would work for everyone, I was just sharing how I did it, for anyone to take for what they felt it was worth.
It also isolates the acme record into its own file which allows me to keep permissions on the normal zonefile not writable by the named user.
Tangentially, I think the term "propagation" in respect to DNS is misleading - because many people take it to mean the DNS servers are pushing out the data to other DNS servers all over, when that isn't remotely close.
Fun fact, if you have a planned migration where you need fast changeover for a particular zone, then you can temporarily dial your TTLs down to something like 5 minutes, sufficiently in advance (how far ahead depends on the current TTLs) so you get caches that honor them to be ready to get new records quickly when you make the change, then once its all settled in you can put them back to normal. You'll obviously get a higher rate of query traffic during that interval.
You will also likely be able to use dns-persist-01 in the near future, which effectively trades DNS challenge response updates with having a fixed set of ACME accounts that are allowed to request certs courtesy of a static TXT record.