From 11589bd2e78e5b4baead2f558c977f5c20596511 Mon Sep 17 00:00:00 2001 From: Steve Atkins Date: Thu, 30 Oct 2025 14:18:30 +0000 Subject: [PATCH] Fix wording in rfc2136 documentation on rate limits Signed-off-by: Steve Atkins --- content/docs/configuration/acme/dns01/rfc2136.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/docs/configuration/acme/dns01/rfc2136.md b/content/docs/configuration/acme/dns01/rfc2136.md index 86e9dd32df3..1f032b381f8 100644 --- a/content/docs/configuration/acme/dns01/rfc2136.md +++ b/content/docs/configuration/acme/dns01/rfc2136.md @@ -161,11 +161,11 @@ Note how the `tsig-secret` and `tsig-secret-key` match the configuration in the ## Rate Limits -The `rfc2136` provider waits until *all* nameservers to in your domain's SOA RR +The `rfc2136` provider waits until *all* nameservers authoritative for your domain respond with the same result before it contacts Let's Encrypt to complete the challenge process. This is because the challenge server contacts a non-authoritative DNS server that does a recursive query (a query for records it -does not maintain locally). If the servers in the SOA do not contain the correct +does not maintain locally). If not all the authoritative servers contain the correct values, it's likely that the non-authoritative server will have bad information as well, causing the request to go against rate limits and eventually locking the process out. @@ -204,4 +204,4 @@ requested, the provider will begin processing the request. - Compared to the other providers that often use REST APIs to modify DNS RRs, this provider can take a little longer. You can `watch kubectl certificate yourcert` to get a display of what's going on. It's not uncommon for the process - to take five minutes in total. \ No newline at end of file + to take five minutes in total.