Le type d'enregistrement CAA permet au propriétaire d'un domaine d'indiquer quelle autorité de certification est autorisée à émettre des certificats pour ce domaine. Il a été introduit par la RFC6844 puis révisé par la RFC8659. L'enregistrement comporte un octet de drapeaux : le bit 0 est le drapeau Issuer Critical, les bits 1 à 7 sont réservés.

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
 }

Voici le piège. Selon les conventions de la RFC1035, le bit 0 est le bit de poids fort. Activer le drapeau critique signifie donc écrire 128, soit 10000000 en binaire. De nombreux utilisateurs ont lu la spécification et conclu que la valeur devait être 1, soit 00000001. Cela active le bit 7, le bit de poids faible, qui est réservé et censé être ignoré.

La RFC8659 ajoute une précision de numérotation pour lever l'ambiguïté : 128 active le bit critique, 1 non. La clarification est arrivée trop tard. L'erreur d'interprétation s'était déjà répandue dans d'innombrables zones DNS.

Cela place les autorités de certification comme LetsEncrypt devant un dilemme. La spécification exige qu'une CA refuse l'émission lorsqu'une balise de propriété inconnue porte le bit critique. Mais une grande partie des utilisateurs ont activé le mauvais bit. Le code Boulder de LetsEncrypt résout le conflit en acceptant les données erronées : sa fonction filterCAA dans va/caa.go vérifie les deux bits, et son commentaire traite le bit mal utilisé comme un substitut informel du véritable bit critique.

L'auteur Remy Porter conclut par une question de conception. Les masques de bits permettent de combiner des valeurs de façon compacte grâce aux opérations booléennes, mais les gens s'y trompent constamment. Si sept bits sur huit sont de toute façon réservés, un simple drapeau aurait peut-être été un choix plus judicieux.