DNS CAA(Certification Authority Authorization) 레코드는 도메인 보유자가 공개 인증기관(CA)에 인증서 발급 권한을 알리는 DNS 정책입니다. CA는 인증서 발급 전에 요청 이름에 적용되는 CAA 레코드를 확인합니다. 다만 CAA는 발급 전 추가 통제이며 인증서 검증이나 오발급 방지를 완전히 대체하지 않습니다.

도메인과 상위 DNS 이름의 CAA 정책을 조회해 발급 권한을 확인하는 흐름을 나타낸 개념 이미지

CAA가 제한하는 범위

RFC 8659에서 CAA는 CA가 인증서를 발급하기 전에 수행하는 권한 확인입니다. DNS 이름에 CAA가 게시되어 있으면 CA는 관련 레코드 집합과 요청이 일치하는지 확인해야 합니다. 일치하지 않으면 발급하지 않아야 하지만, 정책 또는 인증 업무 규정에 정의된 예외가 적용될 수 있습니다. CAA가 허용하는 CA를 지정하는 것은 발급 과정에 추가 조건을 제공하는 일이지, 도메인 소유권 확인을 없애거나 브라우저의 인증서 신뢰 판단을 바꾸는 일이 아닙니다.

CAA는 현재 게시된 발급 권한을 설명합니다. 인증서가 발급된 뒤 CAA 정책이 바뀔 수 있기 때문에, 지금의 DNS 레코드만으로 과거 발급이 당시 정책과 맞았는지 판단할 수 없습니다. RFC는 relying party가 CAA 레코드를 인증서 검증의 일부로 사용하지 않도록 명시합니다. 따라서 CAA 구성은 CA의 사전 발급 검사와 사후 인증서 검증을 구분해 이해해야 합니다.

CA가 적용 레코드를 찾는 방식

CA는 인증서 요청의 각 FQDN에 대해 그 이름에서 시작해 상위 도메인으로 올라가며 처음 발견한 CAA 레코드 집합을 사용합니다. 예를 들어 www.example.com에 레코드가 없고 example.com에 레코드가 있다면 상위 이름의 집합이 적용될 수 있습니다. 중간 하위 도메인에 별도 CAA가 있으면 그 집합이 더 가까운 정책으로 사용됩니다. RFC의 조회 절차는 CNAME 등 DNS 별칭 처리도 포함하므로, 단순히 등록 도메인의 화면 설정만 확인하는 것으로 충분하지 않을 수 있습니다.

여러 이름을 포함하는 인증서 요청에서는 CA가 요청된 모든 이름과 와일드카드 이름에 대한 권한을 확인합니다. 운영자는 인증서의 SAN 목록과 실제 DNS 위임 구조를 함께 살펴야 합니다. 하위 도메인에 독립적인 CA를 사용한다면 각 이름에서 어느 CAA 집합이 먼저 발견되는지 확인하고, 부모 도메인의 정책이 예상과 달리 적용되는지 점검합니다. Let's Encrypt 안내도 가장 가까운 이름의 레코드가 우선하며 별칭을 따라 조회한다고 설명합니다.

issue, issuewild와 추가 조건

일반적인 issue 속성은 해당 이름의 비와일드카드 인증서 발급자를 제한하며, 별도의 issuewild가 없으면 와일드카드 발급에도 적용됩니다. 와일드카드에 다른 권한을 주고 싶을 때 issuewild를 사용합니다. 관련 집합에 issuewild가 있으면 와일드카드 요청에서는 issue가 무시되고, 여러 같은 속성의 허용 값은 추가적으로 결합될 수 있습니다. 각 값에 다른 CA를 나열하면 어느 하나가 허용한 CA가 발급할 수 있으므로 허용 목록을 검토할 때 이 점을 고려해야 합니다.

CAA 레코드는 플래그, 태그, 값으로 구성됩니다. issue 값에는 CA 식별 이름을 두며, 빈 발급자 이름은 발급을 허용하지 않도록 요청하는 데 사용할 수 있습니다. iodef는 정책 위반 보고 방법을 지정하지만, 그 자체가 발급을 제한하는 태그는 아닙니다. critical flag가 설정된 알 수 없는 태그를 CA가 만나면 RFC는 해당 이름의 발급을 하지 않도록 요구합니다. 초기에 의미를 정확히 알지 못하는 태그에 critical flag를 설정하면 발급 실패를 일으킬 수 있으므로 CA 지원 여부를 확인해야 합니다.

실무자 관점: 발급 전에 시험하고 한계를 기록

Let's Encrypt 운영 안내는 issue 레코드에 validationmethods 또는 accounturi 같은 추가 매개변수를 지정하는 방법과, CA 조회에서 SERVFAIL이 발생할 때 점검할 DNSSEC 검증·권한 네임서버·지원하지 않는 질의 유형을 설명합니다. 이런 매개변수의 의미와 지원 범위는 발급 CA마다 다를 수 있으므로 일반적인 CAA 문법만 보고 적용하지 말고 해당 CA 문서를 확인하세요. 변경 전에는 실제 FQDN과 와일드카드 이름에 대한 조회 결과를 점검하고, 발급 자동화의 staging 경로에서 정상 발급과 거부 결과를 함께 확인하는 편이 안전합니다.

CAA는 허용된 CA 자체의 잘못된 발급을 막지 못하며, DNS에서 레코드가 억제되거나 위조되는 위험도 남습니다. RFC 8659는 가능한 경우 CA가 DNSSEC을 검증할 것을 권고하지만 DNSSEC은 CAA 자체가 아닙니다. 도메인 운영자는 DNS 레코드와 위임·별칭 경로를 정확히 유지하고, 허용 CA의 조직 내부 발급 통제도 확인해야 합니다. CAA의 목적은 오발급 위험을 줄이는 추가 제어이지 인증서나 DNS를 무조건 안전하게 만드는 보장이 아닙니다.

참고 자료