Repository navigation
Conversation
With SET_CAA=false plain dns-01 never looked at CAA before asking the CA. A CAA record that refuses this account -- one an earlier SET_CAA=true run pinned to a previous account, after the account changed, or the operator's own record naming another CA -- then refused every attempt, each spending one of Let's Encrypt's five failed validations per hostname per hour, and nothing in the container would ever fix it. Check the CAA in force first with dnsguide's existing check_caa (new --caa-only) and fail the pass with a clear message instead. DNS that cannot be read does not block. A fresh account has no URI yet, so an accounturi pin can only be caught from its second pass on. With SET_CAA=true the stale record is the container's own to replace, so that path is unchanged. Signed-off-by: Kevin Wang <wy721@qq.com>
kvinwang
force-pushed
the
fix/ingress-caa-precheck
branch
from
October 16, 2026 02:34
ed407d4 to
cb516ab
Compare
Collaborator
Author
|
Superseded: CAA handling is being made uniform across modes (register first, publish, check, issue once) in a follow-up PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
With
SET_CAA=false, plain dns-01 never checked CAA before asking the CA. A CAA that refuses this account — left pinned to a previous account by an earlierSET_CAA=truerun (the account changes when/etc/letsencryptis lost orACME_STAGING/ACME_DIRECTORY_URLswitches), or the operator's own record naming another CA — refused every attempt. Each one spent one of Let's Encrypt's 5 failed validations per hostname per hour, and the container never fixes the record itself.What
dnsguide.py --caa-only: one-shot run of the existingcheck_caa(walks up to the governing CAA set, checks issuer,validationmethodsandaccounturi). Exits 3 only when CAA forbids issuance; anything else (unreadable DNS, a crash) leaves the decision to the CA.dns01.sh: withSET_CAAoff (non-delegation), check beforecertman.pyand fail the pass with a clear message.SET_CAA=trueand delegation are unchanged: there the container replaces the record itself.accounturipin is caught from its second pass on.SET_CAAandDOH_RESOLVERS; a TESTING.md negative-path row.Tests
TestCaaOnly(pinned to another account → 3, inherited other CA for a wildcard → 3, no CAA → 0, resolver failure → 0); 78 unit tests pass.www.google.com→ 3 ("issue allows 'pki.goog'"),*.github.comandexample.com→ 0.process_domainstubbed withSET_CAA=false: check exit 0 or 1 → issues; 3 → fails the pass without calling certman.