요약

  • draft-ietf-dnsop-dnssec-keyrestore-02는 좁은 범위의 재난을 다룹니다. 사적 서명 키가 사용 불능이 되었지만, 사용 가능한 백업은 없고, 완전한 사전 서명 존과 여전히 유효한 서명만 남아 있는 상황입니다.
  • 안전한 복구는 서명 만료, 자식 DNSKEY 전파, 부모 DS 게시, 세컨더리 로딩, 캐시 퇴역마다 서로 다른 시계를 따릅니다. 서명자는 여러 전환을 시작할 수 있지만 그 전부를 혼자 완결할 수는 없습니다.
  • 운영자는 각 전환의 권한 주체, 증거, 가장 이른 안전 시점을 기록한 복구 시계 영수증을 보관해야 합니다. 이것은 Daniel Kade의 거버넌스 권고이며 IETF 요구 사항이 아닙니다.

경보 화면이 항상 공개된 장애는 아닙니다. 하드웨어 보안 모듈이 고장 나거나, 운영자가 키 접근을 잃거나, 재해로 사적 키 자료를 사용할 수 없게 됩니다. 그러나 권위 있는 서버는 여전히 서명된 존을 돌려줍니다. 검증 리졸버는 여전히 서로 맞아떨어지는 DNSKEY와 RRSIG, 그리고 해당하는 경우 부모 DS를 찾습니다. 사용자는 아무것도 느끼지 못할 수 있습니다.

이 조용한 구간은 정반대의 두 가지 위험을 만듭니다. 당황하면 기존 서명이 만료되기 전에 유효한 존을 bogus 상태로 만들 수 있습니다. 안도하면 장애를 감추고 있는 서명이 곧 만료될 때까지 그 구간을 낭비할 수 있습니다. 따라서 좋은 복구는 상태를 정확히 명명하는 것에서 시작합니다. 서비스는 검증 연속성은 유지했지만 새 상태를 서명할 능력은 잃었다는 것입니다.

DNSSEC Key Restore의 개정 02는 2026년 8월 10일에 게시되었습니다. 이 문서는 DNSOP 워킹 그룹의 활성 Internet-Draft로, 렌더링된 문서에서는 Informational을 목표로 하며 아직 진행 중인 작업입니다. RFC도, BCP도 아니고, 저자의 고용주인 RIPE NCC의 배포 약속도 아닙니다. 이 드래프트는 사전 서명 존을 다룹니다. 온라인 서명과 루트 존은 명시적으로 범위 밖입니다.

그 제목은 의도적으로 절제되어 있습니다. 이 절차는 사라진 사적 키를 복원하지 않습니다. 검증이 여전히 의존하는 공개 레코드와 기존 서명을 보존하면서 대체 키 자료를 도입함으로써 서명 기능을 복원합니다.

정상 답변 뒤에 동결된 존이 숨어 있을 수 있다

이 드래프트는 사용 불능 키를 더 이상 서명을 생성할 수 없는 사적 부분으로 정의합니다. 하드웨어 고장, 자연재해, 운영자 실수, 악의적 행동이 원인이 될 수 있습니다. 키가 여전히 서명할 수 있다면 유출된 키는 별개의 상태입니다. 이 구분은 중요합니다. 유출은 적대적 사용 문제를, 사용 불능은 연속성 문제를 낳기 때문입니다. 둘을 동의어로 취급하면 잘못된 대응이 나올 수 있습니다.

장애 발생 순간에도 존은 여전히 올바르게 서명되어 서비스 중일 수 있습니다. RRSIG 수명 때문에 검증이 실패하기까지 며칠이 남는 경우가 많습니다. 그러나 “많은 경우”는 서비스 보장이 아닙니다. 남은 구간은 존 전체의 서명 실제 개시·만료 시각, 여전히 게시된 레코드, 검증자가 캐시했을 수 있는 조합에 따라 결정됩니다.

이 구간 동안 존은 안전하게 변경할 수 없을 수 있습니다. 새 주소, 서비스 철회, 메일 라우팅 수정, 인시던트 대응 레코드는 관련 기존 키가 변경된 RRset에 서명할 수 없다면 단순히 삽입할 수 없습니다. 가시적인 해석 실패가 없다는 사실은 변경 준비 상태에 대해 아무것도 말해 주지 않습니다. 안정적인 답변은 기존 상태가 보존되었다는 증거일 수 있고, 정상 운영이 계속된다는 증거가 아닙니다.

이어서 드래프트의 중심 예방 조치가 나옵니다. 서명 소프트웨어는 사적 부분이 없다는 이유만으로 기존 DNSKEY를 폐기해서는 안 됩니다. 기존 RRSIG를 보존해야 하며, 서명자가 제거할 경우 운영자가 수동으로 다시 추가해야 할 수도 있습니다. 기존 공개 자료는 더 이상 운영적으로 생산적이지 않지만, 의존하는 모든 캐시 수평선이 지나갈 때까지는 검증에 결정적입니다.

복구 경로는 키 역할에 따라 달라진다

DNSSEC 검증은 키를 암호학적으로 동일하게 취급하지만 복구는 그렇지 않습니다. 권한 경로는 사용 불능 키가 Zone Signing Key인지, Key Signing Key인지, Combined Signing Key인지에 따라 달라집니다.

ZSK가 고장 나고 KSK가 작동 가능한 상태라면, 운영자는 새 ZSK를 DNSKEY RRset에 추가하고 작동하는 KSK로 그 RRset에 서명할 수 있습니다. 새 키가 하나의 권위 서버에 나타났다고 해서 곧 준비된 것은 아닙니다. 드래프트의 게시 구간은 권위 전파 지연과 DNSKEY TTL을 합칩니다:Ipub = Dprp + TTLkey. 이 수평선이 지나야만 캐시된 DNSKEY 집합이 문제될 수 있는 어디에서든 대체 키를 사용할 수 있다고 간주합니다.

이후 존은 새 ZSK로 서명할 수 있습니다. 퇴역은 또 다른 시계입니다. 기존 ZSK는 새 서명이 완료되고, 변경이 전파되었으며, 기존 키로 만든 서명이 더 이상 캐시에 남아 있을 수 없을 때까지 유지됩니다:Iret = Dsgn + Dprp + TTLsig. 키 장애, 키 게시, 서명 활성화, 안전한 제거는 서로 다른 네 개의 사건입니다.

KSK가 고장 나고 ZSK가 작동 가능한 상태라면, 자식은 자기 존 내부에서 이 문제를 해결할 수 없습니다. 대체 KSK에 대한 신뢰는 부모의 DS 레코드를 통해 연결되어야 합니다. 드래프트는 Double-DS 방식을 사용합니다. 새 DS를 제출하고, 부모의 등록과 게시를 기다리고, 새 DS가 전파되어 캐시에 자리 잡도록 한 뒤, 자식에서 새 KSK를 활성화합니다.

부모 게시 시각은 제출 시각에 등록 지연을 더한 값입니다:Tpub = Tsbm + Dreg. 이어서 준비 시점은 부모 전파와 DS TTL을 더합니다:IpubP = DprpP + TTLds. RFC 7583은 이미 거버넌스 관점을 분명히 하고 있습니다. 부모를 포함하는 KSK 타이밍은 존 관리자가 전적으로 통제하지 않습니다. “접수됨”이라는 API 영수증은 부모의 게시나 리졸버의 캐시를 앞당길 수 없습니다.

Combined Signing Key가 고장 나면 두 표면이 동시에 만나게 됩니다. 대체 키는 부모 측 Double-DS 경로를 필요로 하는 동시에, 존은 평소의 서명 능력 자체를 잃습니다. 기존 CSK 레코드와 서명은 새 DS, 새 키, 새로 서명된 존이 각자의 수평선을 통과할 때까지 유지되어야 합니다. 퇴역 구간에는 서명 지연, 자식 전파, DNSKEY와 RRSIG TTL 중 큰 값이 포함됩니다. 하나의 키처럼 보이던 단순성이 더 넓은 복구 의존성으로 변합니다.

장애는 자동화를 다시 절차로 되돌린다

건강한 DNSSEC 운영은 CDS나 CDNSKEY를 통해 부모 DS 유지를 자동화할 수 있습니다. 그러나 장애 상태에서는 새 DS를 요청하는 그 레코드 자체를 사용 불능인 ZSK나 CSK로 인증할 수 없을 수 있습니다. 개정 02는 따라서 해당 복구 경로를 수동 부모 업데이트로 되돌립니다.

수동이 비공식이라는 뜻은 아닙니다. 누군가는 권한 있는 자식을 확인하고, 요청을 인증하고, 대체 자료를 검증하고, 평소 자동화에 대한 예외를 승인하고, 접수와 게시를 구분해야 합니다. 이 절차는 DNS 호스트, 등록기관, 레지스트리, 부모 존 운영자를 넘나들 수 있습니다. 암호학적 장애는 평소 자동화가 가려 왔던 제도적 경로를 드러냅니다.

세컨더리 서비스는 두 번째 수동 접합부를 만듭니다. SOA를 바꾸지 않고 새 DNSKEY를 도입하면 기존 키가 더 이상 서명할 수 없는 레코드를 변경하는 일을 피할 수 있습니다. 그러나 바뀌지 않은 SOA는 IXFR이나 AXFR에 의존하는 세컨더리에게 변경된 콘텐츠를 가져오라는 평소 신호를 주지 못할 수 있습니다. 세컨더리를 강제로 로드해야 할 수 있습니다. 프라이머리가 한 번 성공적으로 응답했다고 해서 모든 권위 인스턴스가 같은 복구 상태를 갖는다는 증거는 되지 않습니다.

ZONEMD는 또 다른 결과를 더합니다. DNSKEY RRset을 바꾸면 존 내용이 바뀌고 기존 다이제스트가 무효화됩니다. 새 다이제스트를 생성하고 서명해야 합니다. 드래프트의 Knot DNS 구현 노트는 설명된 절차에서 그 다이제스트의 수동 생성이 지원되지 않는다고 말합니다. 이것은 경계에 대한 유용한 증거이며, 이 방식이 모든 제품에 걸쳐 완성되었다는 증명은 아닙니다.

IETF 126에서 참가자들은 TTL과 서명 만료의 더 정밀한 비교, 그리고 구현 세부를 요청했습니다. 발표자는 이 접근이 Knot DNS에서 작동했다고 보고했고, 의장은 구현 섹션을 요청했습니다. 이렇게 나온 드래프트의 증거는 의미 있지만 좁습니다. 이를 다중 벤더 상호운용성 주장으로 확대해서는 안 됩니다.

복구 시계 영수증

인시던트 티켓은 보통 장애 시각과 해결 시각을 기록합니다. 이 복구에는 너무 거칩니다. 두 끝점 사이에는 서로 다른 주체가 소유한 전환들이 있고, 각각 자체적인 증거와 가장 이른 안전 시점을 갖습니다.

복구 시계 영수증은 인시던트 분류, 영향받은 키 역할, 알고리즘으로 시작해야 합니다. 통상적인 서명 수명에 의존하기보다, 검증 연속성의 상한이 되는 가장 이른 RRSIG 만료를 계산해야 합니다. 기존 DNSKEY와 서명이 여전히 서비스 중이라는 증명을 보존해야 합니다. 새 키가 권위 인스턴스 전반에 게시된 사실과, 키가 준비되었다고 판단하는 데 쓰인 전파 및 TTL 입력값을 기록해야 합니다.

KSK나 CSK 복구에서는 영수증이 부모 제출, 인증, 접수, 관측된 게시, 캐시 준비 시점을 분리해야 합니다. 이것들은 동의어가 아닙니다. 세컨더리에 대해서는 강제 로드 대상 전부와 관측된 콘텐츠 또는 일련번호 상태를 기록하면서, SOA가 바뀌지 않으면 평소 비교가 어려워진다는 점을 함께 밝혀야 합니다. ZONEMD에 대해서는 새 다이제스트가 생성되었는지, 왜 일시적으로 이용 불가였는지, 누가 그 상태를 승인했는지 기록해야 합니다.

마지막으로 영수증은 새 서명이 완료된 시점을 특정하고, 새로 서명된 RRset의 경계가 있는 표본을 보여 주며, 기존 DNSKEY, DS, RRSIG 자료의 가장 이른 퇴역 시점을 계산하고, 실제 제거는 별도로 기록해야 합니다. 각 수동 예외에는 의사결정 책임자와 정정 경로가 필요합니다.

목적은 비밀을 공개하는 것이 아닙니다. 사적 키, HSM 구성, 개인 인시던트 데이터는 공개 기록에 속하지 않습니다. 아티팩트 해시, 키 태그, 타임스탬프, 정책 버전, 관측된 RRset, 책임 조직 역할은 서명 환경을 노출하지 않으면서 유용한 증거 사슬을 만들 수 있습니다.

측정은 볼 수 없는 것을 인정해야 한다

어떤 운영자도 모든 재귀 캐시를 검사할 수 없습니다. 따라서 TTL 기반 타이밍은 보편적 관측이 아니라 보수적인 수평선을 사용합니다. 여러 지점에서의 독립 질의는 표본화된 권위 및 재귀 경로가 기대 상태에 도달했음을 보여 줄 수 있습니다. 그러나 오래된 조합이 어디에도 남아 있지 않음을 증명하지는 못합니다.

이 한계야말로 공식과 입력값을 보존해야 하는 이유입니다. 검토자가Dprp,TTLkey,TTLds,TTLsig와 운영자가 가정한 서명 지연을 알면, 전환이 선택된 안전 마진을 존중했는지 검증할 수 있습니다. 그런 입력 없는 초록 대시보드는 계산을 단순한 주장으로 바꿉니다.

상태 어휘도 똑같이 중요합니다. 요청은 제출됐지만 접수되지 않을 수 있고, 접수됐지만 게시되지 않을 수 있으며, 게시됐지만 준비되지 않을 수 있고, 준비됐지만 활성화되지 않을 수 있으며, 활성화되었어도 기존 자료가 아직 안전하게 제거 가능하지 않을 수 있습니다. 이것들을 “복구됨”으로 압축하면 결론이 증거보다 앞서게 됩니다.

이 드래프트가 증명하는 것과 그렇지 않은 것

개정 02는 사전 서명 존을 의도적으로 insecure 또는 bogus 상태로 만들지 않고 서명 능력을 복구하는 기술적으로 근거 있는 방법을 제공합니다. 기존 공개 자료를 보존하고 캐시 수평선을 존중하는 것이 복구 이후의 뒷정리가 아니라 복구의 일부임을 보여 줍니다. 그 공식은 여러 의존성을 명시적으로 만듭니다.

그러나 보편적인 복구 시간, 감사 형식, 부모 서비스 약속, 리졸버 센서스를 제공하지는 않습니다. 모든 서명자 아키텍처에 적용되지 않습니다. 자동화가 실패했다는 이유만으로 모든 수동 단계가 안전하다고 말하지 않습니다. 그리고 키가 유출된 경우에 요구되는 별개의 대응을 대체하지도 않습니다.

거버넌스 결론은 이 한계들에서 나옵니다. 기존 서명은 임시 연속성 예산을 벌어 줄 뿐입니다. 하나의 주체에게 부모, 세컨더리, 캐시에 대한 통제권을 주지 않습니다. 복구 절차는 각 시계가 그것을 움직일 수 있는 권한과, 그것이 움직였음을 증명하는 증거에 연결될 때 비로소 책임 있는 것이 됩니다.

출처

  1. DNSSEC Key Restore — 개정 02
  2. DNSSEC Key Restore의 Datatracker 기록
  3. DNSSEC Key Restore 문서 이력
  4. IETF 126 DNSOP 회의록
  5. DNSOP 활성 문서
  6. DNSOP 차터
  7. RFC 9364: DNS Security Extensions
  8. RFC 7583: DNSSEC Key Rollover Timing Considerations
  9. RFC 8078: Managing DS Records from the Parent via CDS/CDNSKEY
  10. RFC 8976: Message Digest for DNS Zones
  11. RFC 9499: DNS Terminology