DNS: leave CAA off by default #294

Merged

jcoffey-dev merged 1 commits from fix/caa-default-292 into main

2026-11-05 05:54:42 +00:00

jcoffey-dev commented

2026-11-05 04:37:14 +00:00

Owner

Fixes #292.

A domain with automatic certificates and automatic DNS published a CAA record at its apex by default, bound to this server's ACME account. It covers every name under the domain, so another ACME client there, like certbot on a web server, gets refused at its next renewal.

What changes

CAA comes out of the publishRecords default, in the schema and in the generated Default. The first-run setup path already left it off.
The field description now explains the trap, which also feeds the generated reference docs.
_validation-persist used to be built only as part of CAA, so a DNS-PERSIST-01 provider on a domain not publishing CAA could never validate. That was already true for domains made by first-run setup. It's now published either way for those providers.

Existing domains store their own list, so they keep whatever they publish today. Unticking CAA doesn't delete a record that's already out there, and the docs PR says so.

Tested

automation::automation_tests passes against Pebble, with the persist domain changed to publish no CAA.
With the new persist branch disabled, the same suite panics at acme.rs:439 because no certificate is issued, so the test does depend on it.
New unit test caa_is_off_by_default. Format, fork checks and cargo test --workspace --no-run are clean.

Not tested or not changed

Refusal by a real CA hasn't been reproduced. It rests on RFC 8657 and on Let's Encrypt's published support for accounturi.
The zone file shown for manual DNS still lists CAA, since someone is reading those records before adding them.

Goes with inbuxa/inbuxa-admin#162 (console default and warning) and inbuxa/inbuxa.org#124 (docs).

Fixes #292. A domain with automatic certificates and automatic DNS published a CAA record at its apex by default, bound to this server's ACME account. It covers every name under the domain, so another ACME client there, like certbot on a web server, gets refused at its next renewal. **What changes** - CAA comes out of the `publishRecords` default, in the schema and in the generated `Default`. The first-run setup path already left it off. - The field description now explains the trap, which also feeds the generated reference docs. - `_validation-persist` used to be built only as part of CAA, so a DNS-PERSIST-01 provider on a domain not publishing CAA could never validate. That was already true for domains made by first-run setup. It's now published either way for those providers. Existing domains store their own list, so they keep whatever they publish today. Unticking CAA doesn't delete a record that's already out there, and the docs PR says so. **Tested** - `automation::automation_tests` passes against Pebble, with the persist domain changed to publish no CAA. - With the new persist branch disabled, the same suite panics at `acme.rs:439` because no certificate is issued, so the test does depend on it. - New unit test `caa_is_off_by_default`. Format, fork checks and `cargo test --workspace --no-run` are clean. **Not tested or not changed** - Refusal by a real CA hasn't been reproduced. It rests on RFC 8657 and on Let's Encrypt's published support for `accounturi`. - The zone file shown for manual DNS still lists CAA, since someone is reading those records before adding them. Goes with inbuxa/inbuxa-admin#162 (console default and warning) and inbuxa/inbuxa.org#124 (docs).

jcoffey-dev added 1 commit 2026-11-05 04:37:14 +00:00

DNS: leave CAA off by default

github/ci (branch) GitHub Actions

Details

ci / fork-checks (pull_request) Skipped

Details

ci / build (pull_request) Skipped

Details

ci / github (pull_request) Successful in 4s

Details

cc282697e8

A CAA record with accounturi covers every name under the domain, so another
ACME client there, like certbot on a web server, is refused at its next
renewal. Nothing warned about it and it could be weeks before it showed.
New domains now have to ask for CAA. The field description says why, and
domains that already publish it keep it.

The DNS-PERSIST-01 validation record was only built as part of CAA, so
without this a persist provider on a domain not publishing CAA could never
validate. It's now published either way for those providers.

Fixes #292

jcoffey-dev referenced this pull request from inbuxa/inbuxa-admin

2026-11-05 04:37:39 +00:00

DNS guide: leave CAA off by default and say why #162

jcoffey-dev merged commit 753fbc2446 into main

2026-11-05 05:54:42 +00:00

jcoffey-dev deleted branch fix/caa-default-292

2026-11-05 05:54:42 +00:00

jcoffey-dev referenced this pull request

2026-11-06 06:57:58 +00:00

Version 27.1.0-rc.9 #298