마지막 업데이트: | 모든 문서를 참조
CAA는 사이트 소유자가 도메인 이름을 포함한 인증서를 발급할 수 있는 CA (인증 기관)를 지정할 수 있도록 하는 DNS 레코드 유형입니다. CA가 의도하지 않은 인증서 오용의 위험을 줄이기 위해 RFC 6844에 의해 2013년에 표준화되었습니다. 기본적으로 모든 공용 CA는 공용 DNS의 모든 도메인 이름에 대한 인증서를 발급할 수 있습니다 (단, 해당 도메인 이름의 제어를 확인한 경우). 즉 많은 공용 CA의 유효성 검사 프로세스 중 하나에 버그가 있는 경우, 모든 도메인 이름이 잠재적으로 영향을 받습니다. CAA는 도메인 소유자가 이 위험을 줄일 수 있는 방법을 제공합니다.
CAA 사용하기
CAA에 대해 신경쓰지 않는다면 일반적으로 아무것도 할 필요가 없습니다 (아래 CAA 오류 참조). CAA를 사용하여 도메인의 인증서를 발급할 수 있는 인증 기관을 제한하려면 CAA 레코드 설정을 지원하는 DNS 공급자를 사용해야 합니다. 해당 공급자 목록을 보려면 SSLMate의 CAA 페이지를 확인하십시오. 공급자가 나열되면, SSLMate의 CAA 레코드 생성기를 사용하여 허용하려는 CA를 나열한 CAA 레코드 집합을 생성할 수 있습니다.
Let’s Encrypt의 CAA 도메인 이름 식별자는 letsencrypt.org
입니다. 이것은 공식적으로 CPS (인증서 사용 약관) 4.2.1절에 문서화되어 있습니다.
레코드를 넣는 위치
주 도메인이나 하위 도메인의 모든 CAA 레코드를 설정할 수 있습니다. 예를 들어, www.community.example.com
이 있다면, 전체 이름이나 community.example.com
, 또는 example.com
에 대한 CAA 레코드를 설정할 수 있습니다. CA는 각 버전을 왼쪽에서 오른쪽으로 검사하고, CAA 레코드를 보는 즉시 중지합니다. 예를 들어 community.example.com
의 CAA 레코드는 example.com
의 CAA 레코드보다 우선시합니다. CAA 레코드를 추가하는 대부분의 사람들은 이를 등록된 도메인 (예: example.com)에 추가하여 모든 하위 도메인에 적용하려고 합니다. 또한 하위 도메인에 대한 CAA 레코드는 더 관대한지, 제한적인지 여부에 관계없이 상위 도메인보다 우선합니다. 따라서 하위 도메인은 상위 도메인에서 제한을 완화할 수 있습니다.
CAA 유효성 검사는 다른 모든 DNS 요청과 마찬가지로 CNAME을 따릅니다. www.community.example.com
이 web1.example.net
에 대한 CNAME인 경우, CA는 먼저 www.community.example.com
에 대한 CAA 레코드를 요청한 다음, 해당 도메인에 대한 CNAME이 있음을 확인하는 대신에 web1.example.net
에 대한 CAA 레코드를 요청할 것이다. 도메인 이름에 CNAME 레코드가 있는 경우, DNS 표준에 따라 다른 레코드를 가질 수 없습니다.
CAA RFC는 CA가 CNAME 확인 결과의 상위 도메인도 확인해야 하는 “트리 클라이밍"이라는 추가 동작을 지정합니다. 이 추가 동작은 나중에 정오표에 의해 제거되었으므로 Let’s Encrypt와 다른 CA는 이를 구현하지 않습니다.
CAA 에러
Let’s Encrypt는 발행한 모든 인증서 이전에 CAA 레코드를 확인하기 때문에 CAA 레코드를 설정하지 않은 도메인에 대해서도 오류가 발생하는 경우가 종종 있습니다. 오류가 발생하면 발급을 금지하지만, 오류로 인해 표시되지 않는 CAA 레코드가 있을 수 있으므로 영향을 받은 도메인에 대해 발급할 수 있는지 여부를 알 수있는 방법이 없습니다.
CAA 관련 오류가 발생하면 준비 환경에 대해 몇 번 더 시도하고 오류가 임시적인지, 영구적인지 확인하십시오. 영구적인 경우, DNS 공급자 또는 스위치 공급 업체에 지원 문제를 제보해야 합니다. DNS 공급자가 누구인지 확실하지 않으면 호스팅 제공 업체에 문의하십시오.
CAA에 익숙하지 않은 일부 DNS 제공 업체는 처음에 “저희는 CAA 레코드를 지원하지 않습니다.“라며 문제 보고서에 응답합니다. DNS 공급자는 CAA 레코드를 특별히 지원할 필요가 없습니다. 알 수 없는 쿼리 유형 (CAA 포함)에 대해 NOERROR 응답만 하면 됩니다. 알 수 없는 쿼리 유형에 대해 NOTIMP를 비롯한 다른 opcode를 반환하면 RFC 1035 위반이며 수정해야 합니다.
SERVFAIL
사람들이 직면하는 가장 일반적인 오류 중 하나는 SERVFAIL입니다. 이 오류는 대부분 DNSSEC 유효성 검사 실패를 나타냅니다. SERVFAIL 오류가 발생하면 dnsviz.net과 같은 DNSSEC 디버거를 사용해야 합니다. 그래도 해결이 되지 않으면, 네임 서버가 응답이 비어있는 경우에만 잘못된 서명이 생성될 수 있습니다. 그리고 CAA 응답은 일반적으로 비어 있습니다. 예를 들어, PowerDNS는 4.0.3 이하 버전에서 이 버그가 있었습니다.
DNSSEC를 활성화하지 않고 SERVFAIL 오류가 나타난 경우, 두 번째로 가장 가능성이 높은 이유는 권한 있는 네임 서버가 NOTIMP를 반환했기 때문입니다. 이는 위에서 설명한 것처럼 RFC 1035 위반입니다. 대신 빈 응답으로 NOERROR를 리턴해야 합니다. 이 경우 DNS 공급자에게 버그 또는 지원 문의를 제출하십시오.
마지막으로 SERVFAIL은 권한 있는 네임 서버의 정지로 인해 발생할 수 있습니다. 네임 서버의 NS 레코드를 확인하고 각 서버를 사용할 수 있는지 확인하십시오.
Timeout
때때로 CAA는 시간 초과를 쿼리합니다. 즉, 권위 있는 네임 서버는 여러 번의 재시도 후에도 응답으로 응답하지 않습니다. 일반적으로 이것은 네임 서버가 알 수 없는 쿼리 유형으로 DNS 질의를 삭제하도록 잘못 구성된 방화벽을 가지고 있을 때 발생합니다. DNS 공급자에게 지원 문의를 제출하고 방화벽이 구성되어 있는지 물어보십시오.