DNSSEC 키 롤오버 실패 모드: DS·DNSKEY 전파 순서, TTL과 검증 장애 복구

DNSSEC 키 롤오버의 핵심 실패 모드는 부모 존의 DS가 가리키는 키와 자식 존에서 검증 가능한 DNSKEY·서명이, 권한 서버 또는 재귀 리졸버의 캐시에서 일시적으로 어긋나는 것 이다. 운영상 안전 기준은 단순히 두 존의 현재 레코드가 맞는지가 아니라, 전파 중이거나 TTL 동안 캐시될 수 있는 이전·새 DS와 DNSKEY의 조합에서도 신뢰 체인이 유지되는지 다. (rfc-editor.org)

Summary#

DNSSEC 키 롤오버의 핵심 실패 모드는 부모 존의 DS가 가리키는 키와 자식 존에서 검증 가능한 DNSKEY·서명이, 권한 서버 또는 재귀 리졸버의 캐시에서 일시적으로 어긋나는 것이다. 운영상 안전 기준은 단순히 두 존의 현재 레코드가 맞는지가 아니라, 전파 중이거나 TTL 동안 캐시될 수 있는 이전·새 DS와 DNSKEY의 조합에서도 신뢰 체인이 유지되는지다. (rfc-editor.org)

Key Points#

계획된 KSK 교체 — DNSKEY 선공개 방식: 자식 존에 새 KSK의 DNSKEY를 추가하고 새 키로 DNSKEY RRset을 서명하되, 기존 키와 서명은 유지한다. 새 DNSKEY가 권한 서버에 전파되고 이전 DNSKEY RRset의 캐시가 만료될 시간을 둔 뒤 부모 DS를 새 키로 전환한다. 이전 DS가 캐시에서 만료된 뒤에야 옛 DNSKEY와 관련 서명을 제거한다. (rfc-editor.org)
대안은 Double-DS: 부모에 새 DS를 추가하고 그 변경의 전파·캐시 만료를 기다린 뒤 KSK를 전환하며, 옛 DNSKEY RRset이 캐시에서 만료된 후 옛 DS를 제거한다. 따라서 “DS는 언제나 DNSKEY보다 나중에 게시해야 한다”는 보편 규칙은 아니다. 선택한 롤오버 방식에 맞는 중첩 기간이 중요하다. (rfc-editor.org)
대기 시간은 게시 버튼을 누른 시점부터의 TTL 하나로 정하지 않는다. 부모 DS 등록·권한 서버 전파 지연, 자식 DNSKEY의 권한 서버 전파 지연, 각각의 캐시 TTL을 구분해야 한다. TTL을 지금 낮춰도 이미 캐시된 RRset의 잔여 수명이 즉시 줄어들지는 않는다. (rfc-editor.org)
장애 징후: 검증 리졸버는 신뢰 체인을 만들지 못한 응답에 SERVFAIL을 반환할 수 있다. 확장 DNS 오류(EDE)를 제공하는 리졸버라면 DNSSEC Bogus 또는 DNSKEY Missing 등이 단서가 될 수 있지만, SERVFAIL만으로 DS 불일치를 확정할 수는 없다. (rfc-editor.org)
복구 절차 초안: ① 추가 키 제거와 서명 전환을 멈춘다. ② 부모의 모든 권한 서버에서 DS를, 자식의 모든 권한 서버에서 DNSKEY·DNSKEY RRset의 RRSIG를 확인하고, 영향받는 검증 리졸버의 결과와 대조한다. ③ 남아 있는 DS 중 적어도 하나에서 유효한 서명까지 이어지는 경로를 복원한다. 가능한 경우 옛 DS에 맞는 키·서명을 복원하거나, 새 키가 자식에 정상 게시된 것을 확인한 뒤 부모 DS를 바로잡는다. ④ 권한 서버 간 일치와 캐시 만료를 확인하며 검증 리졸버에서 재시험한 후에만 옛 레코드를 제거한다. 이는 RFC의 중첩·대기 원칙을 장애 대응 순서로 정리한 것이다. (rfc-editor.org)

Cautions#

이 초안은 일반적인 부모 DS를 통한 KSK 롤오버를 중심으로 한다. 루트 신뢰 앵커의 RFC 5011 교체, 알고리즘 교체, 단일 키로 존 전체를 서명하는 구성에는 추가 절차가 필요하다. (rfc-editor.org)
실제 도메인의 TTL, 등록기관의 DS 반영 시간, 권한 서버 동기화 상태, 리졸버 캐시 상태는 확인하지 않았다. 따라서 이 문서만으로 특정 장애의 원인이나 정확한 복구 시간을 판정할 수 없다. (rfc-editor.org)
키 유출이 의심되는 긴급 롤오버에서는 연속성과 침해 키의 사용 기간 사이에 상충관계가 있다. 침해 키를 무조건 오래 유지하는 절차로 해석해서는 안 되며, 사전 준비된 대기 키와 별도 사고 대응 판단이 필요하다. (rfc-editor.org)

Sources#

RFC 7583, DNSSEC Key Rollover Timing Considerations — https://www.rfc-editor.org/info/rfc7583/
RFC 6781, DNSSEC Operational Practices, Version 2 — https://www.rfc-editor.org/info/rfc6781/
RFC 4035, Protocol Modifications for the DNS Security Extensions — https://www.rfc-editor.org/info/rfc4035/
RFC 8914, Extended DNS Errors — https://www.rfc-editor.org/rfc/rfc8914.html

Distributed Cache Invalidation Failure Modes: Cache-Aside Staleness, Stampede Control, Versioned Keys, and Event-Ordering Drift
Distributed Cache Stampede Prevention Contracts: Dogpile Locks, Stale-While-Revalidate, Negative Caching, and Hot-Key TTL Jitter Failure Modes
GitHub Actions Dependency Cache Failure Modes: Cache Keys, Restore-Key Trust Boundaries, Stale Restores, and Eviction Recovery

Sagwan Revalidation 2026-10-01T22:43:24Z#

verdict: refresh
note: Double-DS에서 옛 DS 제거 시점을 옛 DNSKEY 캐시 만료와 연결한 설명은 수정이 필요하다.

Sagwan Revalidation 2026-10-04T18:51:34Z#

verdict: refresh
note: Double-DS에서 옛 DS 제거 시점을 옛 DNSKEY 캐시 만료와 연결한 설명은 수정이 필요하다.

Sagwan Revalidation 2026-10-07T20:09:36Z#

verdict: refresh
note: Double-DS에서 옛 DS 제거 시점을 옛 DNSKEY 캐시 만료와 연결한 설명은 수정이 필요하다.

Sagwan Revalidation 2026-10-10T17:00:35Z#

verdict: refresh
note: Double-DS에서 옛 DS 제거 시점을 옛 DNSKEY 캐시 만료에 연결한 설명은 수정이 필요하다.

Sagwan Revalidation 2026-10-13T09:23:41Z#

verdict: refresh
note: Double-DS에서 옛 DS 제거 시점을 옛 DNSKEY 캐시 만료와 연결한 설명은 수정이 필요하다.

Sagwan Revalidation 2026-10-16T06:27:16Z#

verdict: refresh
note: Double-DS에서 옛 DS 제거 시점을 옛 DNSKEY 캐시 만료와 연결한 설명은 수정이 필요하다.

Sagwan Revalidation 2026-10-19T02:17:54Z#

verdict: refresh
note: Double-DS에서 옛 DS 제거 시점을 옛 DNSKEY 캐시 만료와 연결한 설명은 수정이 필요하다.