I suspect this is working as intended, but I’d like to verify.
We attempted to have a certificate issued for a domain that had no blocking CAA record, had DNSSEC enabled, and the authoritative NS did not provide a non-existence proof for the CAA type (making the lack of CAA record invalid).
Is this a necessary security feature, or a potential oversight? It seems to me DV with DNSSEC would necessarily require crypto proofs for the A/AAAA/TXT records which are used to prove ownership, not the CAA which authorizes a CA. I’m not intimately familiar with the RFC though, so I’m not sure. It might be nice to help early adopters of DNSSEC to drop the non-existence proof requirement for CAA records, but I defer to the smarter people in the room.
If you had a prohibitive CAA record (
0 issue ;) in your signed zone, being able to evade it by
forging an unsigned stripping the NSEC would be pretty disappointing.
I think the RFC does address this directly:
DNSSEC provides a proof of non-existence for both DNS domains and RR
set within domains. DNSSEC verification thus enables an issuer to
determine if the answer to a CAA record query is empty because the RR
set is empty or if it is non-empty but the response has been
looks like your name server is wrong. Or better: The DNSSEC implementation your name server uses is buggy.
The non-existence proof of a record is an important part of DNSSEC, it’t 50 % of DNSSEC.
So if a domain uses DNSSEC, doesn’t have a CAA record and doesn’t proof the non-existence:
Don’t use DNSSEC or update your configuration.
And it’s not a problem of the ACME-RFC.
DNSSEC isn’t something that’s “new”. Sounds like you use a DNSSEC software that is too old and not updated, if this software doesn’t support CAA records.
Yep, as @_az and @JuergenAuer said, we won’t issue if we get an error during CAA validation, which includes the scenario you describe.
Also, validating DNSSEC during validation isn’t actually required by the BRs. We choose to do it because the extra validation is valuable for those who have enabled DNSSEC.
Thank you for the insights! @jsha @_az @JuergenAuer
Wait, it isn’t? I thought it was, per 220.127.116.11:
CAs are permitted to treat a record lookup failure as permission to issue if:
- the failure is outside the CA’s infrastructure;
- the lookup has been retried at least once; and
- the domain’s zone does not have a DNSSEC validation chain to the ICANN root
That last requirement, “the domain’s zone does not have a DNSSEC validation chain to the ICANN root” to me implies that if the domain’s zone does have a DNSSEC validation chain to the ICANN root, then CAs MUST NOT treat a record lookup failure as permission to issue.
That section gives two options: Implementing DNSSEC, or never treating lookup failure as permission to issue. A CA that treats CAA lookup failure as a fatal error doesn’t have to validate DNSSEC.
Let’s Encrypt actually does both – they validate DNSSEC and consider CAA failures to be fatal errors.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.