IETF가 2024년 7월 16일 RFC 9615 "Automatic DNSSEC Bootstrapping Using Authenticated Signals from the Zone's Operator"를 발표했습니다. 아직 보안 위임이 되지 않은 영역(zone)을 처음 DNSSEC으로 연결할 때, 상위 영역(parent) 쪽이 하위 영역(child)의 CDS/CDNSKEY 레코드를 DNS 안에서(in-band) 암호학적으로 검증하고 DS 레코드를 등록하는 방법을 담은 문서입니다. 지금까지는 대역 외(out-of-band) 확인에 기대거나, "일정 시간 뒤 수락(Accept after Delay)"처럼 검증 강도가 약한 방식을 써야 했습니다.
무엇이 발표되었나
- 문서: RFC 9615 (저자 P. Thomassen, N. Wisiol)
- 상태: 표준화 과정(Standards Track), 제안 표준(Proposed Standard)
- 관계: RFC 7344를 갱신(update)하고, 이 문서 4장의 DS 등록 방법을 RFC 8078 3장의 방법보다 우선 권장하는 방법으로 정합니다.
RFC 8078은 상위 측 대리인(parental agent, 레지스트리나 레지스트라)이 하위 영역 정점(apex)의 CDS/CDNSKEY 레코드를 읽어 DS 레코드를 자동으로 만드는 방식을 정의했습니다. 이미 DS가 있는 경우, 예를 들어 키 교체(key rollover) 때는 기존 신뢰 사슬(chain of trust)로 CDS/CDNSKEY를 검증할 수 있습니다. 그런데 처음 DNSSEC을 켜는 부트스트래핑(bootstrapping) 단계에서는 하위 영역에 검증 경로가 아직 없습니다. 게다가 RFC 8078에는 DNSSEC을 켤 때 쓸 DNS 내부 검증 방법이 정의되어 있지 않았습니다.
RFC 9615는 이 빈 곳을 채우려고, DNS 운영자가 자신이 권한을 가진 영역에 관한 정보를 영역 단위로, 인증된 방식으로 공개하는 일반 신호(signaling) 메커니즘을 정의합니다. 위탁 DNS 운영자(managed DNS operator)는 이 신호로 자신이 관리하는 영역의 DNSSEC 키 정보를 안전하게 알릴 수 있습니다. 상위 측은 이 신호로 하위 영역 정점의 CDS/CDNSKEY를 검증하고, 검증에 성공하면 위임을 보안 상태로 전환합니다. 문서는 DNSSEC 부트스트래핑을 이 메커니즘의 여러 쓰임 가운데 하나로 보며, 앞으로 운영 메타데이터나 제3자 연동용 API 엔드포인트 같은 정보를 공개하는 데에도 쓰일 수 있다고 적고 있습니다.
영향 범위
- 레지스트리·레지스트라 등 상위 측 대리인: DS가 없는 위임에서도 대역 외 확인이나 지연 수락 없이 CDS/CDNSKEY를 암호학적으로 검증해 DS를 등록할 수 있게 됩니다.
- 위탁 DNS 운영자(하위 측 DNS 운영자): 관리하는 영역의 키 정보를 상위 측에 알리는 쪽입니다.
- 적용 제외 사례: 문서에 따르면 대부분의 도메인에 적용할 수 있지만, 하위 영역 이름이 지나치게 긴 경우와 네임서버가 모두 해당 도메인 안에 있는 경우(in-domain nameservers only)는 지원하지 않습니다(4.4절).
운영자가 할 일
- 이용하는 레지스트리나 레지스트라가 RFC 9615 방식의 DS 자동 등록을 지원하는지 확인합니다. 실제 적용 여부는 상위 측 대리인이 지원하는지에 달려 있습니다.
- 위탁 DNS 서비스로 여러 영역을 운영한다면 RFC 9615 본문, 특히 4장의 등록 절차를 검토하고, 사용 중인 DNS 소프트웨어가 이를 지원하는지 확인합니다.
- 네임서버가 모두 자기 도메인 안에 있는 영역은 이 방식으로 부트스트래핑할 수 없습니다. 이런 영역은 기존 DS 등록 절차를 계속 써야 합니다.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.