Closed kristianronningen closed 4 years ago
I noticed just now that the version here on github (0.0.5) is older than the one on pypi (0.0.7), and I also noticed the command line option --certbot-dns-directadmin:directadmin-propagation-seconds
exists, which would solve the "configurable delay" option. In order to keep the waiting to a minimum, I still think a check-and-retry approach could be worth looking into.
Cheers, I plan to release an updated version which has the default at 60 seconds. This after all my testing is most likely to succeed.
But still also there will be the configurable option for propagation seconds as you discover. But having 60 seconds as default just makes sense too.
I do like the idea of retries though too. Might allow it to succeed quicker than 60 secs in some cases so may look into that. Pull Request would be welcome though too ;)
Propagation delay is now 60 seconds as from version 0.0.12. Have also tidied the release process using TravisCI to help with disconnected versioning.
After (successfully) submitting the DNS TXT record, the plugin waits 15 seconds for propagation. However this is in most cases not enough, since DirectAdmin only performs a bind reload at the start of every minute. In addition, in my case, this reload would trigger a zone transfer to the actual name servers, which means an additional small delay.
One option would be to make the propagation delay configurable, but this would still only be a best-guess estimate for when the TXT record should be available.
Perhaps a better way is to add an option for number of retries?
I'm unsure if retries can be requested from the Let's Encrypt side, and if not, maybe it would make sense to, in the plugin itself, do a DNS lookup after the records have been added, to see if they have propagated, before returning control to certbot itself?
Such a feature could probably use an .ini-value of the name server the plugin should query for the newly created TXT record.