Upload DNS data (bash script which rsyncs the data to my authoritative DNS provider).
Poll the domain’s authoritative nameservers directly (i.e. ignore my local resolver) until they all respond with the correct challenge (my hook script).
Allow LetsEncrypt’s server to check the challenge (letsencrypt.sh - once my hook script returns control to it).
One potential problem I see with this is that the LetsEncrypt servers might have a cached response for the DNS lookup (TXT _acme-challenge.example.org), and so when the challenge is checked it won’t match what LE expects. Is there any way to work around this - or do the LE servers always do a fresh (i.e. ignoring any resolver cache) lookup for the challenge? I always use a low (120 seconds) TTL for the TXT challenge records.
I wrote my own bash script ( getssl ), and I’m just going on experience that it doesn’t cache but does a fresh check from lots of testing and cert generation using the DNS-01 challenge.
There doesn’t appear to be anything in the documentation which requires the query skip any resolver cache, the closest I can find about the process is:
"To validate a DNS challenge, the server performs the following steps:
Compute the SHA-256 digest of the key authorization
Query for TXT records under the validation domain name
Verify that the contents of one of the TXT records matches the digest value
If all of the above verifications succeed, then the validation is successful. If no DNS record is found, or DNS record and response payload do not pass these checks, then the validation fails."
I had also done some testing and reached the same conclusion, but “I’ve run some tests and it seems to work in this way” isn’t really good enough for software that will be released to others and used for clients.
Indeed, I’m not saying that black box testing is supposed to make you sure that certain things work in a certain way, but some additional confirmation through testing that something works they way it’s said it should … - that never hurts