요약

  • RFC 6844는 도메인 보유자가 해당 이름에 인증서를 발급할 수 있는 인증기관을 DNS에 지정하도록 했다. 첫 조회 규칙은 CNAME이나 DNAME을 따라간 뒤 목적지의 상위 이름도 검색할 수 있었다. 그래서 호스팅 사업자의 CAA 정책이 고객 이름의 발급 확인에 들어갈 수 있었다.
  • RFC 8659는 DNS의 일반적인 별칭 해석을 유지하되, 상위 이름을 찾는 범위를 검사 중인 FQDN으로 한정했다. 고객 정책과 호스팅 사업자의 이름 트리를 더 분명히 구분한 변경이다.

DNS 응답 뒤에 인증서 발급 질문이 남는다

가상의 예를 들어 www.client.example이 tenant.platform.example을 가리키는 CNAME이라고 하자. 고객의 이름은 공동 호스팅 사업자의 DNS 이름 공간을 통과한다. 인증서를 발급하기 전에 인증기관은 한 가지를 더 확인해야 한다. www.client.example에 적용되는 CAA 레코드 집합은 무엇인가?

조회가 경계를 넘으면 답은 단순하지 않다. 고객은 하나의 DNS 이름 트리를 관리하고, 호스팅 사업자는 다른 트리를 관리한다. 리졸버는 별칭을 따라 순식간에 다른 이름 공간으로 넘어갈 수 있다. 고객이 자기 영역에 올리지 않은 정책까지 적용하려고 인증기관도 사업자의 부모 이름을 검색해야 할까?

2013년 1월 공개된 RFC 6844는 DNS 리소스 레코드인 Certification Authority Authorization, 유형 257을 정의했다. 도메인 보유자는 해당 이름에 인증서를 발급할 수 있는 인증기관을 하나 이상 지정할 수 있었다. 표준을 준수하는 기관은 발급 전에 관련 CAA 레코드 집합을 확인하고, 인증서 정책이나 실무 규정의 예외가 적용되지 않는 한 그 정책과 맞지 않는 요청을 거부해야 했다.

CAA는 도메인 보유자가 이름의 다른 정보와 함께 DNS에 발급 정책을 게시하게 했다. 인증기관은 발급 전에 그 정책을 확인해야 했다. 그러나 DNS 이름 사이를 건너는 조회에서 무엇이 “관련된” 레코드인지가 정책의 범위를 결정했다.

2013년 조회는 두 이름 트리를 오갈 수 있었다

RFC 6844의 처리 규칙은 요청한 이름에서 부모 이름으로만 올라가지 않았다. CAA 조회가 어떤 라벨에서 레코드를 찾지 못했는데 그 자리에 CNAME 또는 DNAME 별칭이 있으면, 절차는 목적지로 이동해 다시 검색할 수 있었다. 거기서도 찾지 못하면 원래 이름의 부모로 올라갔다.

가상의 이름을 보면 결과가 보인다. www.client.example이 tenant.platform.example을 가리키고, 호스팅 사업자가 platform.example에 CAA 0 issue "issuer.example"을 게시했다고 하자. RFC 6844의 재귀 규칙은 별칭을 따라가서 platform.example까지 올라가 정책을 찾을 수 있었다. 사업자가 자기 부모 영역에 올린 레코드가 고객 이름의 발급 조회에 들어갈 수 있었다.

이 규칙은 적용할 CAA 집합을 찾으려는 것이지, 고객 도메인의 소유권을 호스팅 사업자로 넘기는 것은 아니었다. 하지만 DNS 해석과 정책 상속이 같은 재귀 과정에 묶였다. 고객 이름은 사업자의 별칭을 거쳐 그 부모 이름까지 닿을 수 있었다. 공동 호스팅에서는 고객 별칭마다 사업자가 자기 트리 상단에 게시한 정책이 따라붙을 가능성이 생겼다.

2019년에는 요청된 이름의 트리 안에서만 상위 검색을 했다

2019년 11월 공개된 RFC 8659는 RFC 6844를 대체하고 처리 알고리즘을 바꿨다. 인증기관은 여전히 요청된 FQDN의 CAA를 일반 DNS 방식으로 조회하고, 그 과정에서 별칭이 해석될 수 있다. 조회 결과에 CAA 집합이 없으면 검사 대상 FQDN의 부모 라벨을 따라 올라간다. 발견한 각 CNAME 또는 DNAME 목적지의 부모 트리를 별도로 검색하지는 않는다.

차이는 좁지만 중요하다. 별칭 목적지 이름 자체에 CAA 레코드가 있으면 일반 DNS 조회가 이를 반환할 수 있다. 달라진 부분은 목적지의 부모 이름을 별도 경로로 올라가던 검색이다. 고객 이름 트리의 부모 정책은 여전히 고객의 하위 도메인에 적용될 수 있다. 그러나 CNAME이 호스팅 사업자의 이름 공간을 가리킨다는 이유만으로 사업자의 상위 정책이 고객 조회에 들어가지는 않는다.

RFC 8659는 RFC 6844와의 차이를 설명하며 이유를 밝힌다. 원래 이름과 모든 별칭 이름의 트리를 함께 올라가는 방식은 별칭이 많은 이름에서 비효율적이었다. 호스팅 사업자도 자기 FQDN의 정책을 설정하면서 고객 FQDN에 원치 않는 정책을 적용하지 않기가 어려웠다. 개정된 규칙은 질문을 좁혔다. 일반 DNS 별칭 해석 뒤 요청된 이름에는 어떤 CAA 집합이 적용되고, 그 이름의 부모는 어떤 정책을 갖는가?

인증기관의 발급 결정이지 브라우저의 검증 절차가 아니다

CAA는 인증서 발급 전에 작동한다. 브라우저가 이미 발급된 인증서를 다시 판단하도록 하는 장치가 아니며, DNS를 바꿔도 기존 인증서가 취소되지 않는다. 표준은 인증서에 의존하는 쪽이 현재 CAA 레코드를 인증서 검증에 사용하지 못하게 한다. 레코드는 발급 시점의 권한을 말한다.

CAA 레코드가 DNS 응답 자체를 인증해 주는 것도 아니다. RFC 8659는 DNSSEC를 강하게 권고하지만 의무화하지 않는다. 조회가 차단되거나 응답 형식이 깨지거나 빈 응답이 잘못 처리되면 인증기관은 신뢰할 정책 답을 얻지 못한다. RFC의 배포 고려사항은 이런 문제를 열거한다. 발급자가 정책을 가져와 해석할 수 있어야 접근 규칙이 작동하기 때문이다.

CAA에는 여러 속성이 있다. issue는 일반 인증서 발급에 적용되며, issuewild가 있으면 와일드카드 요청을 다룬다. 발급자 값이 비어 있으면 어떤 인증기관도 발급하지 말라는 뜻으로 쓸 수 있다. 태그는 정책 내용을 정하고, 2019년 개정은 그 내용을 어느 이름 트리에서 찾을지 정했다.

이것이 역사적 변화다. 첫 CAA 표준은 도메인 보유자가 DNS에서 발급자를 지정할 자리를 만들었다. 후속 표준은 그 이름 트리와 호스팅 사업자의 이름 트리를 더 정확히 갈랐다. DNS는 여전히 별칭을 해석하지만, 권한 검색은 모든 목적지의 부모를 고객 이름의 부모로 취급하지 않는다.

여기에 나온 이름은 알고리즘을 바탕으로 만든 예시이며, 보고된 사고가 아니다. RFC는 의도된 규칙을 입증한다. 각 인증기관의 실제 구현을 측정하려면 도메인과 시각이 연결된 CAA 조회 기록과 발급 결정 로그가 필요하다.

출처