Warn that cnameStrategy Follow also follows wildcard-synthesized CNAMEs - #2230
Conversation
A wildcard CNAME covering _acme-challenge.<domain> is followed like an explicit one, so cert-manager tries to create the challenge TXT record at the wildcard target and the DNS provider rejects it as out of zone. See cert-manager/cert-manager#5716 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Richard Wall <richard@the-moon.net>
cert-manager-prow
Bot
added
dco-signoff: yes
✅ Deploy Preview for cert-manager ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Pull request overview
Adds documentation to warn users that cnameStrategy: Follow will also follow wildcard-synthesized CNAME answers (RFC 4592), which can cause DNS01 TXT updates to be attempted in an out-of-zone target and fail.
Changes:
- Add a warning block explaining wildcard-synthesized CNAME behavior with
cnameStrategy: Follow. - Provide an example failure mode and suggested mitigations (explicit
_acme-challenge.<domain>record orcnameStrategy: None).
Suppressed comments (1)
content/docs/configuration/acme/dns01/README.md:148
- The Route 53 error message is wrapped in an inline code span that contains a newline. Inline code spans cannot contain newlines in Markdown, so this is likely to render incorrectly. Keep the backticked text on a single line (or use a fenced code block inside the blockquote).
> challenge TXT record at `lb.example.org` — typically failing with an
> error such as Route 53's `RRSet with DNS name lb.example.org. is not
> permitted in zone example.com.`. To avoid this, create an explicit record
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| > found at `_acme-challenge.<domain>`, including one synthesized by a wildcard | ||
| > record. For example, a record like `*.example.com IN CNAME | ||
| > lb.example.org` also answers CNAME queries for |
There was a problem hiding this comment.
Fixed in b6e6dea — reflowed the blockquote so each code span stays on one line (both occurrences).
with claude fable-5
Copilot review flagged that two code spans in the blockquote were split across lines, which can render incorrectly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Richard Wall <richard@the-moon.net>
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hjoshi123 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
cert-manager-prow
Bot
added
the
approved
Adds a warning to the "Delegated Domains for DNS01" section: with
cnameStrategy: Follow, cert-manager also follows CNAMEs synthesised by wildcard records (RFC 4592), because they are indistinguishable from explicit ones in a DNS response. A wildcard CNAME covering_acme-challenge.<domain>therefore sends the challenge TXT record to the wildcard target, which the DNS provider rejects as out of zone.This has caught several users; see the diagnosis in cert-manager/cert-manager#5716 (comment: cert-manager/cert-manager#5716 (comment)) and the same failure with Cloudflare in cert-manager/cert-manager#5751.
Note that cert-manager/cert-manager#8639 proposes a code fix for #5751: detect a wildcard-synthesised CNAME (by querying
*.<domain>directly and comparing targets) and skip following it. Until something like that merges, this warning documents the behaviour of all released versions.with claude fable-5