도메인에 CAA 레코드를 어떻게 설정합니까?

CAA 레코드란 무엇입니까?

CAA 레코드는 RFC 8659에서 정의한 DNS 리소스 레코드로, 도메인 소유자가 해당 이름에 대한 인증서를 발급할 수 있는 인증 기관을 목록으로 지정할 수 있게 합니다. 표기 형식은 CAA 다음에 플래그 값, 태그, 값이 옵니다. 플래그 필드는 1옥텟이며 비트 0은 발급자 필수(issuer critical) 플래그로, 설정되면 128로 표기합니다. 거의 모든 레코드는 0을 사용합니다. 태그는 issue 같은 단어이고, 값은 대개 따옴표로 묶인 문자열입니다.

인증 기관은 발급 전에 인증 대상으로 요청받은 이름의 CAA 레코드를 조회합니다. 그 이름에 레코드가 없으면 RFC 8659에 따라 상위 레이블을 차례로 올라가며 처음 발견한 CAA 레코드 세트에서 멈추고, 루트는 확인하지 않습니다. 어디에도 세트가 없으면 발급은 제한되지 않습니다. 따라서 apex의 레코드는 자체 레코드가 없는 모든 서브도메인에 적용됩니다.

인용하기 좋은 정의는 다음과 같습니다. CAA 레코드는 도메인에 대해 발급이 허용된 인증 기관을 DNS 수준에서 공개적으로 지정하는 허용 목록입니다.

크립토 프로젝트에 CAA 레코드가 왜 필요합니까?

DNS 하이재커는 가짜 프런트엔드를 진짜처럼 보이게 하려면 유효한 인증서가 필요하고, CAA는 그 단계를 더 어렵게 만들기 때문입니다. Blockaid는 2026년 2월 16일부터 23일 사이에 프런트엔드 침해 5건을 추적했으며, DNS 변경과 같은 날 SSL 인증서가 발급되었다는 하나의 특징을 지적했습니다. Nerochain 사례에서는 프로젝트의 도메인에 대해 와일드카드 인증서가 발급되었습니다.

2026년 11월 12일 기준 Wardmint가 Blockaid 보고서를 해석한 바에 따르면, 7일 동안의 침해 5건에서 CAA 레코드로 방해할 수 있는 공격자의 반복 습관이 적어도 하나 나타났습니다. 레코드가 내가 쓰는 인증 기관만 허용하고 있다면, DNS를 바꾼 공격자는 다른 인증 기관이 서명하기 전에 CAA 레코드도 바꿔야 하고, 그 추가 변경은 지켜볼 수 있는 신호가 됩니다.

CAA만으로는 방어가 되지 않습니다. DNS를 장악한 공격자는 CAA 레코드도 수정할 수 있으며, RFC 8659는 CAA가 이미 발급된 인증서에는 영향을 주지 않는다고 명시합니다. DNS 하이재킹으로부터 도메인을 보호하는 방법에 나온 통제와 나란히 놓인 하나의 계층으로 보고, 인증서 투명성 모니터링의 알림과 함께 사용하세요.

issue, issuewild, iodef의 정확한 문법은 무엇입니까?

각 레코드는 이름, 클래스, CAA, 플래그, 태그, 값의 형태이며, 값은 RFC 8659가 정한 대로 태그를 그대로 따릅니다. issue 태그는 발급이 허용된 발급자 도메인을 지정합니다. issuewild 태그는 와일드카드 이름에만 적용되며, 존재하면 와일드카드 요청에 대해 issue보다 우선합니다. iodef 태그는 mailto, http 또는 https를 사용하는 보고용 URL을 지정합니다.

어떤 이름에 대해서도 발급을 전면 금지하려면 발급자를 비워 둔 issue 레코드, 즉 따옴표 안의 세미콜론을 게시하세요. 일반 도메인이라면 사용하는 인증 기관마다 issue 레코드를 하나씩 게시하고, 와일드카드를 따로 통제하려면 issuewild 레코드를 하나 게시하세요. 정확한 발급자 식별자는 인증 기관이 정하는 도메인 이름이므로 해당 기관의 문서에서 가져오세요.

example.com.  3600  IN  CAA  0 issue "ca.example.net"
example.com.  3600  IN  CAA  0 issuewild ";"
example.com.  3600  IN  CAA  0 iodef "mailto:[email protected]"

parked.example.com.  3600  IN  CAA  0 issue ";"

방어용 도메인에 CAA 레코드를 어떻게 설정합니까?

리디렉션만 하는 방어용 도메인에서는 리디렉션을 제공하는 인증 기관 하나만 허용하고, HTTPS로 응답하는 것이 없다면 발급을 금지하세요. 웹 서비스 없이 주차된 도메인은 인증서가 필요 없으므로 0 issue ";"로 다른 누구도 발급할 수 없게 할 수 있습니다. 방문자를 HTTPS로 주 사이트로 전달하는 방어용 도메인은 그에 필요한 인증서가 있어야 하므로, 이를 제공하는 인증 기관을 허용해야 합니다.

방어용 도메인을 주 사이트로 리디렉션하는 방법의 계획에서 시작한 다음 해당하는 CAA 레코드를 추가하세요. Wardmint에서는 A, AAAA, CNAME, ALIAS, MX, TXT, NS, SRV, CAA 레코드를 지원하는 무료 DNS 호스팅, 관리형 DNSSEC, 원하시면 자체 네임서버(2~13개), 전달 설정과 같은 고객 영역에서 레코드를 추가합니다. .com, .net, .org, .io, .xyz, .app의 핵심 세트를 연 $128.94에 보유한 프로젝트는 여섯 개 이름 모두에 같은 CAA 세트를 적용합니다.

어떤 실수가 인증서 발급을 막습니까?

가장 흔한 실수는 사용 중인 줄 잊고 있던 인증 기관을 빠뜨리는 것입니다. 호스팅 플랫폼, 콘텐츠 전송 서비스, 이메일 제공업체가 서브도메인에 대해 자체 인증서를 요청하는 경우가 있습니다. CAA 세트에서 이들을 빠뜨리면 갱신이 실패하며, 인증서가 만료될 때까지 알아채지 못하는 경우가 많습니다. 게시하기 전에 도메인 아래의 이름을 제공하는 모든 서비스를 목록으로 만드세요.

두 번째 실수는 발급자 식별자의 철자가 틀리는 것으로, 허용하려던 인증 기관을 포함해 모두를 막게 됩니다. 실제 갱신으로 테스트하세요. 세 번째는 상위의 CAA 레코드가 자체 레코드가 없는 서브도메인에 적용된다는 점을 잊는 것으로, 제한적인 apex 레코드가 서브도메인의 갱신을 막을 수 있습니다.

레코드를 변경해도 이미 존재하는 인증서가 폐기되지는 않습니다. 예상치 못한 인증서가 발급되었다면 사고로 보고 DNS 하이재킹으로부터 도메인을 보호하는 방법의 절차를 따르세요. DNSSEC, CAA 레코드, 악용 신고 지원을 포함해 주 7일, 12시간 이내 이메일 답변, CAA 레코드에 대한 도움도 포함됩니다.