AZ Tools

CAA 레코드 빌더 (DNS 인증 기관 권한 제한)

네트워크

CAA 레코드 (RFC 8659, 이전 6844) 는 DNS TXT 류의 레코드로, 공인 인증 기관에 어떤 CA 가 본 도메인에 인증서를 발급할 수 있는지 알려줍니다. CA/Browser Forum Baseline Requirements 에 따라 모든 CA 는 발급 직전에 CAA 를 확인해야 하며, 레코드가 존재하는데 자신이 목록에 없으면 거절합니다. 작지만 강력한 무단·오설정 인증서 발급 방어책이고, 무료입니다. 세 가지 태그: `issue` 는 일반 인증서 발급 권한, `issuewild` 는 와일드카드 인증서 발급 권한 (없으면 issue 와 동일), `iodef` 는 사고 보고용 연락처 (mailto:/https:). 각 레코드에 플래그 바이트가 있고, critical 비트 (128) 를 켜면 CA 가 연관 파라미터를 이해 못 할 때 거절. 이 도구는 레코드를 만들어 두 가지 포맷으로 출력: 전체 BIND 존 파일 문법 (마스터 존에 붙여넣기), tag/value 분리 행 (그렇게 묻는 컨트롤 패널용). 흔한 CA 목록으로 Let's Encrypt, DigiCert, Sectigo, Google, Amazon 등을 한 번에 추가. 특수 값 `;` 은 '모든 CA 거부' — 현재 인증서가 필요 없을 때 강력한 정책.

레코드

태그
태그
태그

흔한 CA 추가 (issue 레코드로)

BIND 존 포맷

example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"

태그 / 값 행

플래그·태그·값을 따로 묻는 DNS 컨트롤 패널용. 포맷: flags tag value

  0  issue      "letsencrypt.org"
  0  issuewild  "letsencrypt.org"
  0  iodef      "mailto:security@example.com"
CAA 레코드에 대해

CAA 는 Certificate Authority Authorization (RFC 8659). 공인 CA 에 본 도메인의 인증서를 발급해도 되는지 알려주는 DNS 레코드. CA 는 매 발급마다 CAA 를 확인해 자신이 목록에 없으면 거절합니다. 본 도구는 두 출력 포맷: 직접 존 파일에 붙여넣을 BIND 문법 (적절한 이스케이프 포함), 컨트롤 패널 (Cloudflare, Route53 등) 용 flags / tag / value 표. issue 나 issuewild 의 특수 값 `;` 은 '모든 CA 거부' — TLS 를 지금 안 쓴다면 강력한 기본값. CAA 는 계층적: apex 의 레코드가 모든 서브도메인을 커버 (하위에 더 구체적인 CAA 세트가 없는 한). CA 캐싱으로 인해 레코드가 완전히 전파되는 데 최대 8 시간.

사용법

  1. 도메인 (apex 또는 서브도메인) 입력. CAA 는 잎에서 위로 확인되므로 apex 에 설정하면 보통 전부 커버.
  2. 흔한 CA 버튼을 눌러 시작용 `issue` 레코드 추가. 태그·값·critical 플래그를 필요에 맞게 편집.
  3. 와일드카드 인증서를 발급할 거면 `issuewild` 레코드 추가. 안 할 거면 생략 — `issue` 만으로는 와일드카드를 커버 안 함.
  4. CA 가 정책 위반을 통지할 수 있도록 mailto:/https: 주소의 `iodef` 레코드 추가.
  5. BIND 출력을 존 파일에 붙여넣으세요 (컨트롤 패널이 tag·value 를 따로 물으면 행 포맷 사용).

자주 묻는 질문

CAA 레코드는 어디에 호스팅하나요?
보호하려는 같은 도메인. CAA 조회는 요청 이름에서 apex 까지 위로 올라갑니다 — `api.example.com` 인증서 요청은 `api.example.com`, 그 다음 `example.com`, 그 다음 루트 순으로 조회. 대부분 apex 한 곳에 CAA 세트 하나만 두고 모든 서브도메인을 커버합니다. 서브도메인별 CAA 는 거기서 다른 정책을 원할 때만 필요.
`issue letsencrypt.org` 가 다른 CA 의 와일드카드 발급도 막나요?
네 — `issue` 레코드가 있고 `issuewild` 레코드가 없으면 `issue` 가 와일드카드도 제한합니다. 그러나 `issuewild` 레코드가 하나라도 있으면 와일드카드에 대해 그게 우선. 가장 안전한 패턴은 일반·와일드카드 모두 원할 때 둘 다 명시하거나, 와일드카드가 절대 필요 없으면 `issue` 만 추가. 일반은 허용하면서 와일드카드는 거부할 때 `issuewild` 에 `;` 추가가 일반적.
critical 플래그는 무엇?
비트 7 (값 128) 이 issuer-critical 플래그. 알 수 없는 태그에 켜져 있으면 CA 는 발급을 거절해야 함. 현재는 `issue`, `issuewild`, `iodef` 만 정의되어 있어 critical 은 주로 미래 호환성에 영향. 일반 설정에선 끄세요 (flags = 0). 모든 CA 가 이해해야 한다고 명시적으로 지정할 태그에만 128 사용.
CA 가 새 CAA 레코드를 얼마나 빨리 반영하나요?
Baseline Requirements 에 따르면 CA 는 발급 시점에 CAA 를 확인하고, 이전 값의 캐시 TTL 은 최대 8 시간. 그래서 새 레코드가 모든 CA 에 완전히 적용되는 데 최대 8 시간. 초기 설정 시 캐시된 음성 값이 발급을 막지 않도록 TTL 을 5-60 분으로 두고 나중에 늘리세요.
DNSSEC 가 CAA 에 영향?
존이 DNSSEC 서명되어 있으면 CA 는 서명을 검증해야 하고, 서명되지 않은 응답을 누락으로 취급. 잘못 설정된 DNSSEC 가 CAA 검사를 깨뜨려 인증서 갱신을 막을 수 있습니다. CAA 강제에 의존하기 전에 dnsviz.net 같은 도구로 존을 검증하세요.

관련 도구