I think the DNSSEC chain (or lack there of) should also be returned. This provides some non-reputability of the CAA records, as well as allowing a CA to see if some vantage points see DNSSEC signatures where others don't - possibly a sign of meddling.
Was brought up by @TheEnbyperor. Although an interesting idea for better transparency and non-repudiation, in the current state of the world, DNS resolvers do not return DNSSEC authentication chains back to the clients (for practical reasons). The validation is done by the resolver, and the client trusts the process.
We can recommend in the draft that for CAA checks, perspectives should prefer use of DNSSEC validating resolvers. By setting the DO bit, we can receive the RRSIG record for CAA of the domain, and the AD bit gives indication that the resolver performed the validation.
The question then boils down to, should each perspective return the base64 encoded RRSIG record as well in the response for the CAA check? Would that help provide value for non-reputability?
Was brought up by @TheEnbyperor. Although an interesting idea for better transparency and non-repudiation, in the current state of the world, DNS resolvers do not return DNSSEC authentication chains back to the clients (for practical reasons). The validation is done by the resolver, and the client trusts the process.
We can recommend in the draft that for CAA checks, perspectives should prefer use of DNSSEC validating resolvers. By setting the DO bit, we can receive the RRSIG record for CAA of the domain, and the AD bit gives indication that the resolver performed the validation.
The question then boils down to, should each perspective return the base64 encoded RRSIG record as well in the response for the CAA check? Would that help provide value for non-reputability?