DNS 中的 CAA 记录类型允许域名所有者指定哪些证书颁发机构（CA）有权为其域名颁发证书。该记录类型最初在 RFC 6844 中定义，随后由 RFC 8659 更新，但其核心概念保持不变。CAA 记录的一个关键特性是“颁发者关键”（Issuer Critical）标志，旨在促使颁发机构在颁发证书前验证该记录。该关键标志被设计为标志位掩码的第 0 位，因此启用它应使用值 128。然而，一种普遍的误解导致许多人使用值 1，将第 7 位误认为是关键标志。这种误解在尚未仔细阅读 RFC 的用户中广泛存在。Let's Encrypt 等证书颁发机构面临两难：要么严格遵循规范并拒绝配置错误的记录，要么为了保持功能而迁就这种广泛存在的错误。它们选择了后者，实际上将值 1 接受为关键标志的别名。这一决定承认了用户错误的现实情况，而非严格遵循原始规范。所提供的 filterCAA Go 代码片段展示了这一机制在实际中的处理方式。它过滤“issue”和“issuewild”标签，并检查是否存在未识别的关键标签。值得注意的是，代码会检查标志是否设置为 128（正确值）或 1（广泛使用但不正确的值），以判断是否存在未识别的关键标签。同时接受这两个值反映了对关键标志方面广泛用户错误的迁就。作者质疑在此类标志中使用位掩码的明智性，因为这导致了混淆和错误，并建议更简单的标志机制可能更具可读性且不易出错。尽管承认位掩码的实用性，但该轶事突显了其复杂性如何在实际实现中引发严重的运营问题。技术规范、用户理解与实际实施之间的相互作用是一个反复出现的主题。