DNS의 CAA 레코드 타입은 도메인 소유자가 자신의 도메인에 대한 인증서를 발급할 수 있는 인증 기관을 지정할 수 있도록 합니다. RFC6844에 처음 정의되었고 RFC8659에 의해 나중에 업데이트되었지만, 핵심 개념은 동일하게 유지됩니다. CAA 레코드의 주요 기능 중 하나는 "Issuer Critical" 플래그로, 인증서 발급 전에 인증 기관이 레코드를 검증하도록 의도되었습니다.이 중요 플래그는 플래그 비트마스크의 비트 0으로 설계되었으며, 이를 활성화하려면 128의 값이 사용되어야 합니다. 그러나 일반적인 오해로 인해 많은 사람들이 비트 7을 중요 플래그로 해석하여 1의 값을 사용했습니다. 이 오해는 RFC를 철저히 읽지 않은 사용자들 사이에서 널리 퍼져 있습니다.Let's Encrypt와 같은 인증서 발급 기관은 딜레마에 직면했습니다. 사양을 엄격하게 준수하고 잘못 구성된 레코드를 거부하거나, 기능성을 유지하기 위해 널리 퍼진 오류를 수용해야 했습니다. 그들은 후자를 선택하여 사실상 1의 값을 중요 플래그의 별칭으로 받아들였습니다. 이 결정은 원래 사양에 대한 엄격한 준수보다 사용자 오류의 실제 현실을 인정합니다.filterCAA를 위한 제공된 Go 코드 스니펫은 이것이 실제로 어떻게 처리되는지 보여줍니다. "issue" 및 "issuewild" 태그를 필터링하고 인식되지 않는 중요 태그도 확인합니다. 특히, 이 코드는 인식되지 않는 중요 태그가 있는지 여부를 결정하기 위해 플래그가 128(올바른 값) 또는 1(일반적으로 사용되는 잘못된 값)로 설정되었는지 확인합니다. 두 값 모두를 포함하는 것은 중요 플래그에 대한 널리 퍼진 사용자 오류를 수용하는 것을 반영합니다.저자는 이러한 플래그에 비트마스크를 사용하는 것이 혼란과 오류를 야기할 때 그 지혜에 의문을 제기하며, 더 간단한 플래그 메커니즘이 더 읽기 쉽고 오류가 적을 수 있다고 제안합니다. 비트마스크의 유용성을 인정하면서도, 이 일화는 복잡성이 실제 구현에서 상당한 운영 문제를 야기할 수 있음을 강조합니다. 기술 사양, 사용자 이해 및 실제 구현 간의 상호 작용은 반복되는 주제입니다.