From the Certbot docs, it says to use a 25 second delay at the end for the DNS to propagate. This is fine for a certificate with a few domains, but when you have a certificate with 20 to 30+ domains (like we do), it can take a very long time (15 minutes when waiting 30 seconds per domain). This is a long time when building up a new server. Most of the time 10 seconds works, but it’s still not always enough time to propagate and then the challenge fails. I know a star cert will work better, but that’s still not out until early next year.
What would be nice, is if the manual auth hook would run though each of the authenticator hooks first, then wait a configurable amount of time before attempting the validation. From the looks of it, it already runs each of the hooks before attempting validation.
Does anyone know if this is possible? Or if not, is it worth opening a feature request for?
Ideally the DNS API would offer a blocking step where it promises that after you wait for that step your authoritative DNS including any slaves/clones will give the newly requested answers. Then sleeping arbitrary amounts of time ceases to be necessary.
I see that designate documents a “synchronize” call but it’s optional & it’s not even clear to me what it does.
From the documentation, the python-designateclient doesn't appear to have any sort of --sync or --block flag to wait until it finishes propagating, which sucks. While asynchronous commands have their place, there are times they can make automation much more difficult.
I suppose another option is to query the domain's DNS NS record and poll the NS every few seconds until the ACME challenge matches (or timeout after X time). This could be done in the same script that sets up the DNS TXT record, and would only take the amount of time needed. On the plus side, it should better guarantee that when the Let's Encrypt ACME servers query the NS to verify the challenge that it will be there.