other tests

[dougbeattie]

This is a good list of test, but I was wondering if there are other cases that CAs might want to test for. For example:

• NXDOMAIN: It's probably OK to issue in this case because the CA may not require a domain to be in DNS to perform domain validation (and domain validation is not directly related to CAA), but this is a good test to verify proper processing (however the CA decides to handle it). Let's Encrypt does not, https://letsencrypt.org/docs/caa/, but that could be because all of their domain validation methods requires the domain to be in DNS.
• servfail: All CAs should not issue if DNS returns this. It's easy enough to test by entering a bogus domain, so maybe you don't need a domain test for this, but it's a good test to be aware of and that CAs should handle.
• timeout: While CAs can issue if they retry and they know that the failure is outside of their infrastructure, perhaps a timeout test case would be a good addition?

Thanks for all of the other tests, this will help validate our CAA logic!

[AGWA]

Good idea for a SERVFAIL test. I have added servfail.caatestsuite-dnssec.com and also refused.caatestsuite-dnssec.com to test a REFUSED reply. My interpretation of the BRs is that if the SERVFAIL or REFUSED comes from outside the CA's infrastructure, the CA retries once, and there is no DNSSEC delegation, then the CA is allowed to issue anyways. Therefore, these tests have a DNSSEC delegation.

For testing timeouts, you can use blackhole.caatestsuite-dnssec.com, which doesn't respond to DNS queries. It has a DNSSEC delegation, so issuance is never allowed.

As for the other suggestions, I'm focusing only on tests that block issuance. Since CAs can be more restrictive than required, it's not possible to craft allowed-to-issue tests that are universally useful. So CAs will need to augment these tests with ones that are appropriate to their own policies.