mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-11 22:30:44 +01:00
Feature request: TXT propogation delay #364
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @WayneManion on GitHub (Jul 21, 2018).
My ISP recently blocked all inbound traffic on port 80, so I had to switch from getting my cert the old-fashioned way to this new-fangled DNS-01 business. I switched my nameservers over to Cloudflare because the company I leased the domain names through doesn't have a suitable API.
I had no luck getting dehydrated to work until I added a 10-second delay into the script in between uploading the challenge string and the verification step. Is this something that could be added as a command line option in the future?
Thanks
@jobe1986 commented on GitHub (Jul 21, 2018):
Honestly given that it is an issue limited to some hook script implementations, I would personally see it as more of something that should be dealt with within the hook script rather then within dehydrated itself.
For example a good DNS setup handling low volumes of domains shouldn't need more then half a second delay. However a larger volume DNS setup may have to rely on other propagation methods such as database mirroring which results in larger propagation delays.
@txr13 commented on GitHub (Jul 22, 2018):
Hook scripts should check to ensure the changes have propagated before returning.
@sineverba commented on GitHub (Jul 22, 2018):
@txr13 In
deploy_challengeyou mean, I think. Right?@txr13 commented on GitHub (Jul 22, 2018):
Correct. The deploy_challenge hook should not return until the challenge has actually been fully deployed (propagated).
@sineverba commented on GitHub (Jul 23, 2018):
I'm investigating the issue got the user with mine script: it writes DNS on Cloudflare and returns the ID.
I found this answer: https://community.letsencrypt.org/t/i-have-to-wait-until-dns-propagate-for-issuing-certificate/18573/5
I read "you need to ensure all Authoritative DNS servers for the name you want a certificate for are updated, this is not “propagation” and is purely under the control of your or your hosting supplier. Once the servers are updated, you don’t have to wait for any “propagation”, the Let’s Encrypt systems will interrogate these Authoritative servers themselves directly about the new domain."
In effect never got an issue.
But, I will try to got "inspired" by your email hook: I see you did implement the check ;-)
@txr13 commented on GitHub (Jul 23, 2018):
You (and the commenter) are technically correct—we’re not technically waiting for master/slave propagation. :) I used that term for simplicity’s sake, but yes, the only thing you really have to check is that all authoritative servers have the challenge live. The code I helped write for the email hook does that, so please borrow away if it helps!
@lukas2511 commented on GitHub (Jul 26, 2018):
Yea, like others already said: The hook-script is responsible for waiting for propagation before handing control back to dehydrated. There are various reasons why dehydrated doesn't do this by itself (additional dependencies, unknown network-situation on users systems, anycast can become a problem, etc.).