The CAA record type in DNS allows domain owners to specify which certificate issuers are authorized to issue certificates for their domain. Initially defined in RFC6844 and later updated by RFC8659, the core concept remains the same. A key feature of CAA records is the "Issuer Critical" flag, intended to make issuers validate the record before issuing a certificate.This critical flag was designed as bit 0 of a flag bitmask, meaning a value of 128 should be used to enable it. However, a common misunderstanding led many to use the value 1, interpreting bit 7 as the critical flag. This misinterpretation is widespread among users who haven't thoroughly read the RFC.Certificate issuers like Let's Encrypt faced a dilemma: strictly adhere to the specification and reject incorrectly configured records, or accommodate the widespread error to maintain functionality. They chose the latter, effectively accepting a value of 1 as an alias for the critical flag. This decision acknowledges the practical reality of user error over strict adherence to the original specification.The provided Go code snippet for filterCAA demonstrates how this is handled in practice. It filters for "issue" and "issuewild" tags and also checks for unrecognized critical tags. Notably, the code checks if the flag is set to 128 (the correct value) or 1 (the commonly used, incorrect value) to determine if an unrecognized critical tag is present. This inclusivity of both values reflects the accommodation of the widespread user error regarding the critical flag.The author questions the wisdom of using bitmasks for such flags when it leads to confusion and errors, suggesting simpler flag mechanisms might have been more readable and less error-prone. While acknowledging the utility of bitmasks, the anecdote highlights how their complexity can lead to significant operational issues in real-world implementations. The interaction between technical specifications, user understanding, and practical implementation is a recurring theme.
filterCAAdemonstrates how this is handled in practice. It filters for "issue" and "issuewild" tags and also checks for unrecognized critical tags. Notably, the code checks if the flag is set to 128 (the correct value) or 1 (the commonly used, incorrect value) to determine if an unrecognized critical tag is present. This inclusivity of both values reflects the accommodation of the widespread user error regarding the critical flag.The author questions the wisdom of using bitmasks for such flags when it leads to confusion and errors, suggesting simpler flag mechanisms might have been more readable and less error-prone. While acknowledging the utility of bitmasks, the anecdote highlights how their complexity can lead to significant operational issues in real-world implementations. The interaction between technical specifications, user understanding, and practical implementation is a recurring theme.