El tipo de registro CAA permite al propietario de un dominio declarar qué autoridad de certificación puede emitir certificados para ese dominio. Fue introducido en el RFC6844 y revisado posteriormente por el RFC8659. El registro contiene un byte de indicadores: el bit 0 es el indicador Issuer Critical, los bits 1 a 7 están reservados.

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
 }

Aquí está la trampa. Según las convenciones del RFC1035, el bit 0 es el bit más significativo. Activar el indicador crítico significa escribir 128, 10000000 en binario. Muchos usuarios leyeron la especificación y concluyeron que el valor debía ser 1, 00000001. Eso activa el bit 7, el bit menos significativo, que está reservado y debería ignorarse.

El RFC8659 añade una aclaración de numeración para acabar con la ambigüedad: 128 activa el bit crítico, 1 no. La aclaración llegó demasiado tarde. La interpretación errónea ya se había extendido por innumerables zonas DNS.

Esto coloca a autoridades de certificación como LetsEncrypt ante un dilema. La especificación exige que una CA rechace la emisión cuando una etiqueta de propiedad desconocida lleva el bit crítico. Pero una gran parte de los usuarios activó el bit equivocado. El código Boulder de LetsEncrypt resuelve el conflicto aceptando los datos incorrectos: su función filterCAA en va/caa.go comprueba ambos bits, y su comentario trata el bit mal utilizado como un sustituto informal del verdadero bit crítico.

El autor Remy Porter cierra con una cuestión de diseño. Las máscaras de bits permiten combinar valores de forma compacta mediante operaciones booleanas, pero la gente se equivoca con ellas constantemente. Si siete de ocho bits están reservados de todos modos, quizá un simple indicador habría sido la opción más acertada.