[PR #386] [CLOSED] DNS-01 challenge response only after DNS propagation #821

New Issue

adam · 2025-12-29T01:29:28+01:00

adam commented

2025-12-29 01:29:28 +01:00

📋 Pull Request Information

Original PR: https://github.com/dehydrated-io/dehydrated/pull/386
Author: @Contik
Created: 5/2/2017
Status: ❌ Closed

Base: master ← Head: master

📝 Commits (1)

3aa96d9 DNS-01 challenge response only after DNS propagation

📊 Changes

1 file changed (+74 additions, -0 deletions)

View changed files

📝 dehydrated (+74 -0)

📄 Description

In a situation where a registered domain has more than one nameserver, all of which are equally weighted and thus equally likely to be the one answering Let's Enrypt's query for a proper DNS TXT record Let's Encrypt sometimes queries too quickly and doesn't find the TXT record it needs. It gets a reply from a nameserver that hasn't had the TXT record propagated to it yet.

This change uses dig (which is now a dependency) to check all of a registered domain's authoritative nameservers for presence of the correct DNS TXT record. Challenge response is only triggered when all of a registered domain's authoritative nameservers reply with the correct record.

With this change dehydrated by default begins at a 10-second wait time after the first failed nameserver check and doubles that amount for each consecutive check: nameserver checks start 10, then 20, then 40 seconds apart and so on. Default maximum wait time is 3,600 seconds or 1 hour after which dehydrated does its challenge response anyway which may or may not succeed (same as now).

Anecdotal data point: For registrar INWX with a set of 5 equally weighted nameservers on a registered domain the average wait time for propagation to all 5 of them is 4mins 30s ± a few seconds after which dehydrated's challenge response always succeeds whereas prior to this change success was more of a gamble.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/dehydrated-io/dehydrated/pull/386 **Author:** [@Contik](https://github.com/Contik) **Created:** 5/2/2017 **Status:** ❌ Closed **Base:** `master` ← **Head:** `master` --- ### 📝 Commits (1) - [`3aa96d9`](https://github.com/dehydrated-io/dehydrated/commit/3aa96d99165365901e1b1350fe8c57f6df57ed7d) DNS-01 challenge response only after DNS propagation ### 📊 Changes **1 file changed** (+74 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `dehydrated` (+74 -0) </details> ### 📄 Description In a situation where a registered domain has more than one nameserver, all of which are equally weighted and thus equally likely to be the one answering Let's Enrypt's query for a proper DNS TXT record Let's Encrypt sometimes queries too quickly and doesn't find the TXT record it needs. It gets a reply from a nameserver that hasn't had the TXT record propagated to it yet. This change uses `dig` (which is now a dependency) to check all of a registered domain's authoritative nameservers for presence of the correct DNS TXT record. Challenge response is only triggered when all of a registered domain's authoritative nameservers reply with the correct record. With this change `dehydrated` by default begins at a 10-second wait time after the first failed nameserver check and doubles that amount for each consecutive check: nameserver checks start 10, then 20, then 40 seconds apart and so on. Default maximum wait time is 3,600 seconds or 1 hour after which `dehydrated` does its challenge response anyway which may or may not succeed (same as now). _Anecdotal data point: For registrar INWX with a set of 5 equally weighted nameservers on a registered domain the average wait time for propagation to all 5 of them is 4mins 30s ± a few seconds after which `dehydrated`'s challenge response always succeeds whereas prior to this change success was more of a gamble._ --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

adam added the pull-request label 2025-12-29 01:29:28 +01:00

adam closed this issue

2025-12-29 01:29:28 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#821