dehydrated responds too quickly when using dns-01 #322

New Issue

adam · 2025-12-29T01:22:39+01:00

adam commented

2025-12-29 01:22:39 +01:00

Originally created by @theber-regis on GitHub (Apr 4, 2018).

When using dns-01 with a hook script, dehydrated moves directly from deploy_challenge to responding to challenge before the nsupdate has had time to complete. I have found that I need to wait at least 130 seconds after the deploy to ensure that the update has completed before responding to the challenge.

This trivial patch works reliably in my environment.

diff --git a/dehydrated b/dehydrated
index 40f9221..83ebfeb 100755
--- a/dehydrated
+++ b/dehydrated
@@ -781,6 +781,8 @@ sign_csr() {

Validate pending challenges

local idx=0

echo " + Sleep for 130 seconds to allow dns-01 hook to complete and update"
sleep 130
while [ ${idx} -lt ${num_pending_challenges} ]; do
echo " + Responding to challenge for ${challenge_names[${idx}]} authorization..."

Originally created by @theber-regis on GitHub (Apr 4, 2018). When using dns-01 with a hook script, dehydrated moves directly from deploy_challenge to responding to challenge before the nsupdate has had time to complete. I have found that I need to wait at least 130 seconds after the deploy to ensure that the update has completed before responding to the challenge. This trivial patch works reliably in my environment. diff --git a/dehydrated b/dehydrated index 40f9221..83ebfeb 100755 --- a/dehydrated +++ b/dehydrated @@ -781,6 +781,8 @@ sign_csr() { # Validate pending challenges local idx=0 + echo " + Sleep for 130 seconds to allow dns-01 hook to complete and update" + sleep 130 while [ ${idx} -lt ${num_pending_challenges} ]; do echo " + Responding to challenge for ${challenge_names[${idx}]} authorization..."

adam closed this issue

2025-12-29 01:22:39 +01:00

adam commented

2025-12-29 01:22:40 +01:00

@lukas2511 commented on GitHub (Apr 4, 2018):

This non-dehydrated-issue has been reported multiple times and generally just waiting some time (especially hardcoded 2+ minutes...) is not a good idea.

Your hook-script should (after deploying the challenge) verify that all authoritative nameservers are serving the challenge. If waiting 2+ minutes works for you fine, go ahead and just add the sleep 130 to your hook script, but this definitively doesn't belong into dehydrated.

@lukas2511 commented on GitHub (Apr 4, 2018): This non-dehydrated-issue has been reported multiple times and generally just waiting some time (especially hardcoded 2+ minutes...) is not a good idea. Your hook-script should (after deploying the challenge) verify that all authoritative nameservers are serving the challenge. If waiting 2+ minutes works for you fine, go ahead and just add the `sleep 130` to your hook script, but this definitively doesn't belong into dehydrated.

adam commented

2025-12-29 01:22:43 +01:00

@thinrope commented on GitHub (Feb 29, 2020):

I was just about to submit similar PR ;-D

My reason is that when I have multiple domains (and subdomains), since deploy_challenge() is called once per item, the hook script needs to wait for each item. So either introduce new API deploy_challenges() (but how is that going to work with more than one hook_script?) or add the delay in main; alternatively add another hook verify_precheck() called once after all deploy_challenge() that can be sleep 120 or something in the hook script.

Imagine you have to do 100 domains with dns-01, how will you code your hook script with today's API?

If there is other solution - I am all ears. But I have seen quite a few hook scripts resort to sleep in the dns-01 case.

@thinrope commented on GitHub (Feb 29, 2020): I was just about to submit similar PR ;-D My reason is that when I have multiple domains (and subdomains), since `deploy_challenge()` is called once per item, the hook script needs to wait for each item. So either introduce new API `deploy_challenges()` (but how is that going to work with more than one hook_script?) or add the delay in main; alternatively add another hook `verify_precheck()` called once after all `deploy_challenge()` that can be `sleep 120` or something in the hook script. Imagine you have to do 100 domains with dns-01, how will you code your hook script with today's API? If there is other solution - I am all ears. But I have seen quite a few hook scripts resort to `sleep` in the dns-01 case.

adam commented

2025-12-29 01:22:43 +01:00

@txr13 commented on GitHub (Feb 29, 2020):

@thinrope The solution, as I see it, is a combination of using HOOK_CHAIN and writing your hook to verify the challenges are deployed correctly and ready for validation. (See https://github.com/dehydrated-io/dehydrated/blob/master/docs/hook_chain.md for more detail.)

If you set HOOK_CHAIN=yes in your config, the deploy_challenge function will be called once per certificate, allowing the hook to deploy all challenges for all domain names on the certificate in one shot. (Please note that you need to be using a DNS provider which allows more than one TXT record at a time--most do, but some do not.)

I've contributed code to https://github.com/bennettp123/dehydrated-email-notify-hook and specifically to the function has_propagated. If you look at the hook script, it uses has_propagated to verify that all the authoritative nameservers for the domains being validated actually have the records live. (Let's Encrypt in particular validates directly against the authoritative nameservers for each domain name, which is why the script tests for that, rather than testing against a downstream resolver or hardcoding a fixed delay.)

The hook script I linked to is specifically designed for email, with the propagation check being used to determine when the admin has actually installed the records, but the same code should be able to be used and adapted for use in other hook scripts as a propagation check.

@txr13 commented on GitHub (Feb 29, 2020): @thinrope The solution, as I see it, is a combination of using `HOOK_CHAIN` and writing your hook to verify the challenges are deployed correctly and ready for validation. (See https://github.com/dehydrated-io/dehydrated/blob/master/docs/hook_chain.md for more detail.) If you set `HOOK_CHAIN=yes` in your config, the `deploy_challenge` function will be called once per certificate, allowing the hook to deploy all challenges for all domain names on the certificate in one shot. (Please note that you need to be using a DNS provider which allows more than one TXT record at a time--most do, but some do not.) I've contributed code to https://github.com/bennettp123/dehydrated-email-notify-hook and specifically to the function `has_propagated`. If you look at the hook script, it uses `has_propagated` to verify that all the authoritative nameservers for the domains being validated actually have the records live. (Let's Encrypt in particular validates directly against the authoritative nameservers for each domain name, which is why the script tests for that, rather than testing against a downstream resolver or hardcoding a fixed delay.) The hook script I linked to is specifically designed for email, with the propagation check being used to determine when the admin has actually installed the records, but the same code should be able to be used and adapted for use in other hook scripts as a propagation check.

adam commented

2025-12-29 01:22:43 +01:00

@thinrope commented on GitHub (Mar 1, 2020):

That HOOK_CHAIN=yes is new to me, thanks! I'll have a stab at rewriting the Joker hook script with that, test (in few weeks when I need to renew) and report.

@thinrope commented on GitHub (Mar 1, 2020): That `HOOK_CHAIN=yes` is new to me, thanks! I'll have a stab at rewriting the Joker hook script with that, test (in few weeks when I need to renew) and report.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#322