The CAA record type lets a domain owner declare which certificate authority may issue certificates for a domain. It was introduced in RFC6844 and later revised by RFC8659. The record carries a flags byte: bit 0 is the Issuer Critical flag, bits 1 to 7 are reserved.

default:
 // The critical flag is the bit with significance 128. However, many CAA
 // record users have misinterpreted the RFC and concluded that the bit
 // with significance 1 is the critical bit.
 if (caaRecord.Flag & (128 | 1)) != 0 {
 criticalUnknown = true
 }

Here is the catch. Per the conventions of RFC1035, bit 0 is the most significant bit. Setting the critical flag therefore means writing 128, binary 10000000. Many users read the specification and concluded the value should be 1, binary 00000001. That sets bit 7, the least significant bit, which is reserved and supposed to be ignored.

RFC8659 adds a numbering note to end the ambiguity: 128 activates the critical bit, 1 does not. The clarification arrived too late. The misreading had already spread across countless DNS zones.

That puts certificate authorities like LetsEncrypt in a bind. The spec says a CA must refuse issuance when an unknown property tag carries the critical bit. But a large share of users set the wrong bit. LetsEncrypt's Boulder codebase resolves the conflict by accepting the bad data: its filterCAA function in va/caa.go checks both bits, and its comment treats the misused bit as an informal stand-in for the real critical flag.

Author Remy Porter closes with a design question. Bitmasks allow compact combination of values through boolean operations, but people get them wrong constantly. If seven of eight bits are reserved anyway, maybe a plain flag would have been the wiser choice.