In the SPASM group, we are refining CAA (RFC 6844) based on the changes that were needed in order to get it passed at the CA/Browser Forum. There's one sticky bit in particular I'd like input on. Here's the current language in the BRs:
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.4.pdf > 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. It would be nice if we could provide more solid language for a future BR update, or possibly for a CAA update. The goal here is to work around the issue that a small but significant number of domains return errors when asked for CAA ((I'd guesstimate 1%?). CAs would like to be able to assume there is no CAA record present for those domains and issue anyhow. However, if you're using a standard recursive resolver inside your own infrastructure, and you get a SERVFAIL, how do you distinguish whether that was a DNSSEC validation failure or another type? I realize the extended-error draft will help enormously with that, but I'm looking for a solution that can be deployed before that is done. One idea: Run two recursive resolvers, one validating and one not. If you get an error from both, it's a network error; if you get an error from the validating one and success from the non-validating one, it's a DNSSEC error and you should refuse issuance. A second issue: How does one determine automatically whether a failure is "outside a CA's infrastructure?" This was inserted as a bit of a handwave to get the ballot passed, but it would be nice if we could formalize this concept, or declare that it's unenforceable. Thanks, Jacob _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
