On Fri, 3 Sep 2021 19:40:47 -0700 (PDT) Li-Chun CHEN <[email protected]> wrote:
> > > > 3) if some other status is detected, the system skips over this > > step - i.e. does not consult a RAO, but assumes issuance is > > permitted as far as CAA records are concerned? > > > > Our RA system will made the CAA checking in accordance with Section > 3.2.2.8 of the BR, and a certificate is permitted to issue if the > following conditions are met: > > a. if the dig output is 'NOERROR' or some other status (except > 'ERROR'); and "ERROR" is not a status code used by dig as far as I can tell: <https://gitlab.isc.org/isc-projects/bind9/-/blob/3df71614c8322ee6a0e5f2c2fff6ac11fa4f362c/lib/dns/rcode.c#L51> Could you clarify what version of dig you are using, and what status you are referring to? Is it the DNS RCODE? > b. the lookup has been retried at least once; and > > c. there does not have a DNSSEC validation chain to the ICANN > root. How do you determine this? I understand that your resolver validates DNSSEC, but when standard DNS resolvers encounter an error, they don't report any information about DNSSEC to the client (dig in this case). This means that dig wouldn't be able to distinguish between an error due to an invalid DNSSEC signature (which means you absolutely must not issue) and an externally-caused error in an unsigned zone (which means you may issue after a retry). You also haven't answered my earlier question of how you determine if a failure is outside your infrastructure. In particular, how does dig distinguish between a SERVFAIL caused by a misconfiguration in your resolver (which means you must not issue), versus a SERVFAIL caused by a misconfiguration in an authoritative server (which means you may issue after a retry)? Have you ensured that you unconditionally block issuances for all of the Deny Tests at <https://caatestsuite.com/>? Is the infrastructure that runs the "HiNET DNS resolver" included in the scope of your WebPKI audits? Regards, Andrew -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20210904104517.250afb8682294791faffe026%40andrewayer.name.
