2026년 10월 11일, 루트 KSK가 바뀐다 — 지금 루트 존에 실제로 들어 있는 것

들어가며 — 87일 뒤에 일어나는 일
지금 루트 존에 실제로 뭐가 있나
두 키의 정체 — IANA 트러스트 앵커 파일
8단계, 6년
RFC 5011 — 왜 대부분은 아무것도 안 해도 되나
10월 11일의 절벽 — 그리고 흔한 오해
2017년의 교훈 — 텔레메트리가 실제로 드러낸 것
지금 내 리졸버는 준비됐나 — 그리고 이 확인이 생각보다 어려운 이유
채택률은 지금 얼마인가 — 공개된 숫자가 없습니다
이 롤오버가 바꾸지 않는 것 — 알고리즘
알고리즘 롤오버의 역설 — 1536비트 논쟁
언제 이게 당신 문제가 아닌가
마치며
참고 자료

들어가며 — 87일 뒤에 일어나는 일

2026년 10월 11일, DNS 루트 존의 키 서명 키(KSK)가 KSK-2017에서 KSK-2024로 바뀝니다. 오늘이 7월 16일이니 87일 남았습니다.

이 문장은 두 가지로 읽힙니다. 검증(validation)을 하지 않는 리졸버를 쓰고 있다면 이건 뉴스가 아닙니다. 아무 일도 일어나지 않습니다. DNSSEC 검증을 하는 리졸버를 운영하고 있고 트러스트 앵커가 갱신되지 않았다면, 그날 그 리졸버는 모든 이름에 대해 SERVFAIL을 반환하기 시작합니다. 루트를 못 믿으면 그 아래 전부를 못 믿으니까요.

ICANN의 FAQ는 이 상황을 완곡하게 표현합니다 — 준비되지 않은 상태에서 DNSSEC을 켜 두었다면 "상당한 재정적 영향(significant financial impact)"을 볼 수 있고, 최종 사용자는 도메인을 조회할 때마다 에러를 보게 되며, 이는 고객 지원 전화로 이어질 수 있다고요.

이 글은 추상적인 설명 대신 루트 존을 직접 열어보는 데서 시작하겠습니다.

지금 루트 존에 실제로 뭐가 있나

루트 서버에 직접 물어보면 됩니다. 아래는 2026년 7월 16일에 제가 직접 실행한 결과입니다.

$ dig . DNSKEY +dnssec +norec @a.root-servers.net

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8931
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
.  172800  IN  DNSKEY  256 3 8 AwEAAeCYD6Z7WWKVLeuWgowKP+3g...   ; ZSK
.  172800  IN  DNSKEY  257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WS...   ; KSK-2017
.  172800  IN  DNSKEY  257 3 8 AwEAAa96jeuknZlaeSrvyAJj6ZHv...   ; KSK-2024
.  172800  IN  RRSIG   DNSKEY 8 0 172800 20260801000000 (
                                         20260711000000 20326 . ...

;; MSG SIZE  rcvd: 1139

여기서 읽어야 할 것이 몇 가지 있습니다.

레코드가 4개입니다. 플래그 256짜리 ZSK 하나, 플래그 257짜리 KSK 둘(KSK-2017과 KSK-2024), 그리고 RRSIG 하나. 두 KSK가 이미 몇 년째 나란히 존에 올라와 있습니다.

그런데 RRSIG는 하나뿐이고, 서명한 키 태그가 20326입니다. 이게 KSK-2017입니다. 즉 오늘 시점에 루트 DNSKEY 세트에 서명하는 키는 여전히 KSK-2017 하나입니다. KSK-2024는 존에 실려 있을 뿐 아직 아무것도 서명하지 않습니다. 10월 11일에 바뀌는 게 정확히 이것입니다 — 서명자가 20326에서 38696으로 넘어갑니다.

서명 유효기간도 보입니다. 20260711000000부터 20260801000000까지, 즉 7월 11일부터 8월 1일까지입니다. 루트 KSK 서명은 분기마다 열리는 키 서명식(key ceremony)에서 미리 생성해 두고 슬롯 단위로 게시합니다.

그리고 응답 크기가 1139바이트입니다. 이 숫자는 나중에 다시 나옵니다.

두 키의 정체 — IANA 트러스트 앵커 파일

IANA가 게시하는 트러스트 앵커 파일을 받아서 실제로 파싱해 보면 이렇습니다.

id=Kjqmt7v  tag=19036  alg=8  validFrom=2010-07-15  validUntil=2019-01-11  (공개키 없음)
id=Klajeyz  tag=20326  alg=8  validFrom=2017-02-02  validUntil=(없음)     RSA 2048비트, e=65537
id=Kmyv6jo  tag=38696  alg=8  validFrom=2024-07-18  validUntil=(없음)     RSA 2048비트, e=65537

세 가지를 짚고 갑니다.

첫째, 파일에는 키가 셋 들어 있습니다. 19036은 KSK-2010으로, 2019년에 폐기됐고 validUntil이 박혀 있습니다. 이 파일을 파싱하는 코드를 직접 짠다면 validFrom과 validUntil을 반드시 봐야 합니다. "파일에 있는 키를 전부 트러스트 앵커로 넣는" 순진한 구현은 이미 죽은 키를 집어넣습니다.

둘째, KSK-2024의 validFrom이 2024-07-18입니다. 이게 루트 존에 게시된 날이 아니라 IANA 파일에 올라온 날입니다. 이 날짜는 뒤에서 다시 의미를 갖습니다.

셋째, 가장 중요한 것 — 세 키 모두 알고리즘 8입니다. 그리고 공개키를 직접 디코딩해 보면 KSK-2017과 KSK-2024 둘 다 지수 65537의 RSA 2048비트 키입니다. 즉 이번 롤오버는 키를 바꾸지만 암호 알고리즘은 그대로입니다. 이 이야기는 뒤에서 따로 하겠습니다.

8단계, 6년

ICANN의 FAQ(2026년 5월 22일자)에 따르면 KSK 수명 주기는 약 6년에 걸친 8개 단계로 구성되고, 키가 실제로 서명에 쓰이는 기간은 약 3년입니다. 각 단계는 키 서명식에 묶여 있습니다.

Phase A  키 생성        2024년 4월    첫 번째 키 관리 시설에서 KSK-2024 생성
Phase B  키 복제        2024년 7월    두 번째 시설로 복사 -> 운영 투입 자격 획득
Phase C  최초 서명 생성  2024년 10월   Phase D에서 쓸 서명을 미리 생성
Phase D  게시           2025년 2월    KSK-2024가 루트 존에 등장
Phase E  롤오버         2026년 4분기  KSK-2024만 루트 존에 서명   <- 2026-10-11
Phase F  폐기           2027년 1분기  KSK-2017을 루트 존에서 제거
Phase G  삭제 1         2027년 2분기  첫 번째 시설의 HSM에서 KSK-2017 파기
Phase H  삭제 2         2027년 3분기  두 번째 시설의 HSM에서 KSK-2017 파기

여기서 사소하지만 정직하게 짚어둘 불일치가 하나 있습니다. ICANN FAQ는 Phase D(게시)를 "2025년 2월"로 적고 있는데, 루트 존 관리자인 Verisign은 KSK-2024가 루트 존에 등장한 날을 2025년 1월 11일로 명시합니다. Verisign 쪽 날짜가 자체 데이터와 맞아떨어지는데, 뒤에 나올 30일 홀드다운 이후 채택률이 2월 10일부터 치솟았다는 관측과 정확히 일치하기 때문입니다. 실제 존에 실린 날은 1월 11일로 보는 게 맞습니다.

그런데 왜 하필 매번 10월 11일일까요. 우연이 아닙니다. ICANN의 알고리즘 롤오버 제안서가 그 구조를 설명합니다 — 각 분기는 약 10일짜리 게시 슬롯 9개로 나뉘고, 키 변경은 분기의 11일째, 즉 슬롯 2에 게시됩니다. 4분기는 10월 1일에 시작하니 슬롯 2가 10월 11일입니다. 2017년에 예정됐던 롤오버 날짜도, 실제로 실행된 2018년 롤오버 날짜도 10월 11일이었던 이유가 이겁니다.

RFC 5011 — 왜 대부분은 아무것도 안 해도 되나

루트 존에는 부모가 없습니다. .com의 키는 루트 존의 DS 레코드가 보증하지만, 루트의 키를 보증해 줄 상위 존이 없습니다. 그래서 리졸버는 루트 KSK를 트러스트 앵커로 직접 설정해야 합니다. 그럼 그 키가 바뀔 때는 어떻게 하느냐 — 그게 RFC 5011(Automated Updates of DNS Security (DNSSEC) Trust Anchors, 현재 Internet Standard)입니다.

동작은 이렇습니다. 새 KSK가 트러스트 포인트의 DNSKEY 세트에 처음 나타나면, 리졸버는 그것을 후보로 기억합니다. 그리고 그 키가 유효하게 서명된 상태로 계속 존재하면 애드 홀드다운 타이머가 돕니다. RFC 5011의 정의를 그대로 옮기면, 애드 홀드다운 시간은 "30일, 또는 그 새 키를 처음 담은 트러스트 포인트 DNSKEY 세트의 원래 TTL 만료 시간 중 더 긴 쪽"입니다. 이 조건의 목적은 명시적입니다 — 리졸버가 키를 받아들이기 전에 새 키가 담긴 검증된 DNSKEY 세트를 최소 두 번은 보게 만들려는 것입니다. 루트 DNSKEY의 TTL은 위 dig 결과에서 172800초(2일)이므로, 실제로는 30일이 지배합니다.

30일이 지나면 리졸버는 새 키를 영구 트러스트 앵커 설정에 넣습니다. 운영자가 한 일은 아무것도 없습니다.

이게 이번 롤오버가 대부분의 사람에게 비사건인 이유입니다. KSK-2024는 2025년 1월부터 루트 존에 올라와 있었고, RFC 5011을 구현한 리졸버는 이미 2025년 2월에 그것을 받아들였습니다. 10월 11일에 서명자가 바뀌어도 그 리졸버는 이미 새 키를 알고 있으므로 아무 일도 일어나지 않습니다.

RFC 5011에는 알아둘 만한 조항이 두 개 더 있습니다. 하나는 준수 리졸버가 트러스트 포인트당 SEP 키를 최소 5개는 관리할 수 있어야 한다는 것. 다른 하나는 폐기(revocation) 규칙인데, 이게 다음 절의 핵심입니다.

10월 11일의 절벽 — 그리고 흔한 오해

이번 롤오버를 다룬 글들에서 이런 서술을 여러 번 봤습니다. "10월 11일 이후에도 KSK-2017은 DNSKEY 세트에 남아 있고 2027년 1월에야 폐기되므로, 기한을 놓친 운영자에게는 그전까지 고칠 마지막 기회가 있다."

이건 틀렸습니다. 정확히 말하면, 시간이 있다는 부분은 맞지만 "그때까지는 돌아간다"는 함의가 틀렸습니다.

DNSSEC 검증의 사슬을 따라가 보면 이유가 보입니다. 리졸버가 루트 DNSKEY 세트를 신뢰하려면, 그 세트에 붙은 RRSIG 중 자기가 트러스트 앵커로 가진 키가 서명한 것이 있어야 합니다. ICANN FAQ의 Phase E 서술은 한 문장입니다 — "KSK-2024만 루트 존에 서명한다(Only KSK-2024 is used to sign the root zone)." 즉 10월 11일부터 DNSKEY 세트의 RRSIG는 38696짜리 하나뿐입니다.

KSK-2017만 신뢰하는 리졸버 입장에서는, DNSKEY 세트 안에 KSK-2017이 보이는 것은 아무 도움이 안 됩니다. 그 세트를 검증할 방법이 없기 때문입니다. 자기가 아는 키로 서명된 RRSIG가 없으니까요. 그 리졸버는 10월 11일에 바로 죽습니다. 2027년 1월이 아니라요.

그러면 왜 KSK-2017을 굳이 존에 남겨 둘까요? 답은 RFC 5011의 폐기 규칙에 있습니다. RFC 5011은 키를 세트에서 빼는 것만으로는 폐기가 되지 않도록 설계됐습니다. 문서의 설명을 그대로 옮기면, 폐기 비트가 없다면 어떤 키 B가 단순히 A를 뺀 키 세트를 게시하는 것만으로 A를 무효화할 수 있게 되고, 이를 막기 위해 해당 DNSKEY의 개인키를 알아야만 그 DNSKEY를 폐기할 수 있는 메커니즘을 추가했다는 것입니다.

구체적으로 RFC 5011은 이렇게 규정합니다 — 키가 폐기된 것으로 간주되려면 리졸버가 그 키를 자기 서명된(self-signed) RRSet 안에서 REVOKE 비트가 1로 설정된 채로 봐야 합니다. 그리고 자기 서명된 RRSet이란 그 DNSKEY를 담고 있으면서 그 키로 검증되는 RRSIG가 붙어 있는 세트를 말합니다.

즉 2027년 1분기에 KSK-2017을 제대로 폐기하려면, 그 시점의 DNSKEY 세트는 KSK-2024와 폐기된 KSK-2017 양쪽으로 서명되어 있어야 합니다. 아직 KSK-2017을 트러스트 앵커로 들고 있는 RFC 5011 리졸버가 그 폐기를 보고 자기 저장소에서 지울 수 있게 하려고요. KSK-2017이 10월 이후에도 존에 남는 것은 나중에 규정대로 폐기당하기 위해서이지, 갱신에 실패한 리졸버를 살려두기 위해서가 아닙니다.

부수적으로, 이때 DNSKEY 응답에 RSA 2048 서명이 하나 더 붙습니다(서명 데이터만 256바이트). 오늘 측정한 1139바이트가 그만큼 커진다는 뜻입니다. 이 응답 크기 문제는 이 글 후반부의 주인공입니다.

RFC 5011의 또 다른 디테일 하나. REVOKE 비트가 설정된 DNSKEY는 비트가 없을 때와 지문(fingerprint)이 달라집니다. 키 태그가 바뀐다는 뜻입니다. 폐기 국면에 20326이라는 태그를 그대로 기대하고 짠 모니터링은 그때 오작동합니다.

2017년의 교훈 — 텔레메트리가 실제로 드러낸 것

이 롤오버 계획이 왜 이렇게 굼뜬지 — 2년 가까운 사전 게시 기간, 6년짜리 수명 주기 — 이해하려면 2017년으로 가야 합니다.

원래 KSK-2010에서 KSK-2017로 넘어가는 롤오버는 2017년 10월 11일로 예정돼 있었습니다. 그런데 9월 27일, ICANN은 연기를 발표합니다. 당시 공지를 직접 읽어보면 판단 근거가 나옵니다.

ICANN은 DNSSEC 검증 리졸버를 쓰는 인터넷 사용자 수 추정치를 근거로, 전 세계 인터넷 사용자 넷 중 하나, 약 7억 5천만 명이 이 롤오버의 영향권에 있을 수 있다고 밝혔습니다. (이건 피해자 수 예측이 아니라 노출 규모 추정입니다. 원문도 "could be affected"입니다.) 그리고 연기 사유를 이렇게 적었습니다 — 최근 확보한 데이터가 ISP와 네트워크 사업자들이 쓰는 상당수 리졸버가 아직 준비되지 않았음을 보여준다고요.

그 "최근 확보한 데이터"가 무엇인지도 공지에 설명돼 있습니다. 리졸버가 자기가 설정한 키를 루트 서버에 되보고할 수 있게 해 주는 아주 최근의 DNS 프로토콜 기능이라고요. 이름을 대지는 않았지만 RFC 8145(Signaling Trust Anchor Knowledge in DNSSEC)입니다. 2017년 4월에 나왔으니, 표준이 나온 지 다섯 달 만에 그 표준이 만들어낸 데이터가 세계 최대 규모의 암호 키 교체를 멈춰 세운 셈입니다.

그런데 여기서 진짜 교훈은 그 다음 문장에 있습니다. ICANN은 운영자들이 새 키를 갖고 있지 않은 이유가 여럿일 수 있다고 하면서, 그중 하나로 이렇게 적었습니다 — 널리 쓰이는 리졸버 프로그램 하나에서 최근 발견된 문제가, 키를 마땅히 그래야 하는 대로 자동 갱신하지 않는 것으로 보이며, 그 이유는 아직 조사 중이라고요.

이게 핵심입니다. 텔레메트리가 드러낸 것은 "운영자들이 게을렀다"가 아니었습니다. RFC 5011 자동 갱신을 구현한 소프트웨어에 버그가 있었다는 것이었습니다. 자동화를 켜 뒀고, 자동화가 조용히 동작하지 않고 있었고, 텔레메트리가 없었다면 10월 11일에야 알았을 일입니다.

당시 ICANN CEO였던 예란 마르비의 말은 이랬습니다 — 발표된 10월 11일 날짜로 롤오버를 강행하기보다 신중하고 합리적으로 진행하는 편을 택하겠다는 것이었습니다.

롤오버는 결국 정확히 1년 뒤인 2018년 10월 11일에 실행됐습니다.

지금 내 리졸버는 준비됐나 — 그리고 이 확인이 생각보다 어려운 이유

가장 확실한 방법은 리졸버에 직접 물어보는 것입니다. BIND라면 rndc managed-keys status, Unbound라면 루트 앵커 파일(보통 root.key)을 열어 38696이 있는지 보면 됩니다. 자기 인프라에 접근할 수 있다면 이게 정답입니다.

접근할 수 없는 리졸버(예: 상류 ISP 리졸버)를 밖에서 찔러보려면 RFC 8509(A Root Key Trust Anchor Sentinel for DNSSEC)가 있습니다. 리졸버가 특정 키를 트러스트 앵커로 갖고 있는지를 클라이언트 쪽에서 알아내는 장치입니다.

동작 원리는 이렇습니다. 질의 이름의 맨 왼쪽 레이블이 root-key-sentinel-is-ta-<key-tag> 또는 root-key-sentinel-not-ta-<key-tag> 이면 리졸버가 특별 처리를 합니다. 진리표는 RFC에 이렇게 나옵니다.

레이블      | 키를 신뢰함        | 키를 신뢰하지 않음
-----------------------------------------------------
is-ta       | 원래 응답 반환     | SERVFAIL 반환
not-ta      | SERVFAIL 반환      | 원래 응답 반환

주의할 점이 둘 있습니다. 키 태그는 다섯 자리로 제로 패딩해야 합니다(RFC의 예시대로 42는 00042). 38696과 20326은 마침 다섯 자리라 그대로 씁니다. 그리고 특별 처리가 발동하려면 전제 조건을 전부 만족해야 합니다 — 응답이 DNSSEC 검증을 거쳐야 하고, 검증 결과가 Secure여야 하며, CD 비트가 꺼져 있어야 하고, QTYPE이 A 또는 AAAA여야 하고, OPCODE가 QUERY여야 합니다. 하나라도 어긋나면 리졸버는 응답을 건드리지 않습니다.

이 전제 조건이 실전에서 발목을 잡습니다. 제가 처음에 iana.org 밑에 센티넬 레이블을 붙여 테스트했을 때는 전부 NXDOMAIN이 나왔습니다. 존재하지 않는 이름이라 센티넬이 발동할 조건이 아니었던 것입니다. Secure한 응답이 나오는 이름을 밑에 깔아야 합니다.

그래서 제대로 된 대조군을 세워 다시 측정했습니다. 존재하지 않을 것이 확실한 키 태그 00000을 대조군으로 씁니다. 센티넬이 실제로 발동하고 있다면 is-ta-00000은 반드시 SERVFAIL이 나와야 합니다. 이게 안 나오면 그 측정은 아무것도 증명하지 못합니다.

2026년 7월 16일에 실측한 결과입니다.

Quad9 (9.9.9.9)
  is-ta-38696   x12  ->  NOERROR 12
  is-ta-00000   x12  ->  SERVFAIL 9,  NOERROR 3      <- 섞여서 나옴
  not-ta-38696  x14  ->  SERVFAIL 5,  NOERROR 9      <- 섞여서 나옴

Cloudflare (1.1.1.1)
  is-ta-00000   x14  ->  NOERROR 14                  <- 센티넬 동작 관측 안 됨

Google (8.8.8.8)
  is-ta-00000   x14  ->  NOERROR 14                  <- 센티넬 동작 관측 안 됨

읽는 법은 이렇습니다.

Quad9에서 is-ta-00000이 SERVFAIL을 낸 적이 있다는 것은 일부 백엔드가 RFC 8509를 실제로 구현하고 있다는 증거입니다(대조군 통과). 그 백엔드들에서 not-ta-38696이 SERVFAIL이라는 것은 진리표상 KSK-2024를 신뢰하고 있다는 뜻이고, is-ta-38696이 항상 NOERROR인 것과도 모순이 없습니다. 세 결과가 서로 일관됩니다.

그런데 정직하게 말하면, 이 측정의 진짜 교훈은 그 결론이 아니라 결과가 섞여 나왔다는 사실 자체입니다. 같은 질의를 반복했는데 SERVFAIL과 NOERROR가 번갈아 나옵니다. 애니캐스트 주소 하나 뒤에 여러 백엔드 인스턴스가 있고, 그중 일부만 센티넬을 구현했다고 보면 설명이 됩니다. 실제로 저는 처음 한 번씩만 질의했을 때 깔끔한 진리표를 얻고 결론을 낼 뻔했습니다. 반복해 보니 재현되지 않았습니다.

그러니 이렇게 정리하는 게 맞습니다. 센티넬은 리졸버 인스턴스 단위 테스트이고, 대형 애니캐스트 리졸버를 상대로는 결정적인 진단 도구가 아닙니다. 질의 한 번으로는 아무것도 증명되지 않습니다. 최소한 반복 측정과 대조군 키 태그가 있어야 합니다. 그리고 Cloudflare와 Google에서 센티넬 동작이 관측되지 않았다는 것은 그들이 KSK-2024를 신뢰하지 않는다는 뜻이 전혀 아닙니다 — 단지 이 방법으로는 알 수 없다는 뜻입니다.

채택률은 지금 얼마인가 — 공개된 숫자가 없습니다

그럼 전 세계 리졸버 중 몇 퍼센트가 KSK-2024를 신뢰하고 있을까요.

공개된 최신 수치는 Verisign의 Duane Wessels가 2025년 3월 19일에 쓴 글에 있는 것으로, 2025년 3월 3일 기준 리졸버의 91.3퍼센트가 KSK-2024를 신뢰한다고 신호했다는 것입니다. 이 숫자는 벤더 자체 측정이고, 조건을 분명히 해야 합니다 — RFC 8145 신호를 보내는 리졸버의 표본(a sampling of resolvers)에 대한 것이지 전수가 아니며, RFC 8145를 구현하지 않은 리졸버는 애초에 보이지 않습니다. Verisign은 이 채택 속도가 직전 롤오버의 같은 시점과 정확히 일치한다고 덧붙였습니다.

2026년 중반 기준의 최신 채택률은 공개되지 않았습니다. 제가 찾을 수 있는 범위에서, 롤오버를 87일 앞둔 지금 시점의 공식 수치는 어디에도 게시돼 있지 않습니다. 그래서 여기에 숫자를 적지 않겠습니다.

같은 글에서 더 흥미로운 것은 오히려 다른 두 관측입니다.

하나. 리졸버의 100퍼센트가 KSK-2017을 트러스트 앵커로 갖고 있고, Verisign은 2027년 초 KSK-2017이 폐기될 때까지 그 상태가 유지될 것으로 봅니다. 당연합니다 — 그게 지금 유일한 서명 키니까요.

둘. 2019년에 폐기된 KSK-2010을 여전히 신뢰하는 리졸버가 꽤 있습니다. Verisign은 그 원인을 운영체제 소프트웨어 업데이트에 그 키가 잔존하고 있기 때문일 가능성이 높다고 봅니다. 7년 전에 죽은 키가 아직도 트러스트 스토어에 남아 있는 것입니다. 이게 DNSSEC 배포의 현실입니다 — 프로토콜은 깔끔하고, 배포된 세계는 지저분합니다.

그리고 IANA 파일의 validFrom이 2024-07-18이었던 것을 기억하시나요. Verisign은 2024년 7월, 즉 IANA 트러스트 앵커 파일에 키가 올라온 직후부터 소수의 리졸버가 KSK-2024를 트러스트 앵커에 넣기 시작했다고 관측했습니다. 운영자들이 수동으로 설정한 것으로 본다고요. 두 개의 독립적인 출처가 같은 날짜에서 맞아떨어집니다.

이 롤오버가 바꾸지 않는 것 — 알고리즘

앞에서 두 KSK 모두 알고리즘 8, RSA 2048비트라고 했습니다. 이제 그 얘기를 할 차례입니다.

ICANN의 알고리즘 롤오버 제안서는 이 상황을 담담하게 요약합니다 — 루트 존의 DNSSEC 서명은 2010년에 RSA 기반 알고리즘으로 시작했고, KSK는 2018년에 한 번 교체됐지만 암호 알고리즘 자체는 바뀐 적이 없으며, 이미 진행 중인 2026년 10월 11일 롤오버 역시 같은 알고리즘을 유지한다고요. 그리고 결정적인 한 문장 — 루트 존을 다른 서명 알고리즘으로 전환하는 확립된 메커니즘이 없다는 것입니다.

이 공백은 2021년에 발간된 ICANN의 2차 보안·안정성·복원력 검토(SSR2)가 지적했고, 이사회는 같은 해 7월에 그 권고를 채택했습니다. 그 결과가 2024년의 루트 존 알고리즘 롤오버 연구이고, 그것을 바탕으로 2026년 3월 2일에 공개 의견 수렴에 부쳐진 것이 Proposal for Root Zone KSK Algorithm Rollover입니다.

계획은 이렇습니다. RSA/SHA-256(알고리즘 8)에서 ECDSA P-256 with SHA-256(알고리즘 13) 으로 전환합니다. 2027년에 새 ECDSA 키를 생성하는 것으로 시작해, 교체된 RSA KSK를 최종 파기하는 2030년까지 약 4년에 걸칩니다. 방식은 이중 서명(double-signing)입니다.

여기서 한 가지 짚고 넘어가야 할 게 있습니다. RSA/SHA-256이 약해서 옮기는 게 아닙니다.

알고리즘 권고의 정본은 2025년 11월에 나온 RFC 9904(DNSSEC Cryptographic Algorithm Recommendation Update Process, RFC 8624를 폐기함)입니다. 이 문서의 표를 직접 열어보면 이렇습니다.

No. Mnemonics        Use/Signing   Use/Validation  Impl/Signing  Impl/Validation
 8  RSASHA256        RECOMMENDED   RECOMMENDED     MUST          MUST
13  ECDSAP256SHA256  RECOMMENDED   RECOMMENDED     MUST          MUST

두 알고리즘의 등급이 완전히 동일합니다. RSASHA256은 폐기 대상도, 비권장도 아닙니다. ECDSA P-256이 선택된 이유는 ICANN 연구의 기준 — IETF에서 이미 표준화됐을 것, 그리고 DNSSEC 검증에 대해 필수 구현으로 지정돼 있을 것 — 을 만족하면서 이미 다수의 TLD에 배포돼 있고 BIND, Unbound, Knot Resolver, PowerDNS 등 주요 소프트웨어가 모두 지원하기 때문입니다.

그럼 왜 굳이 옮기는가. 제안서가 드는 실질적 동기는 응답 크기 관리와, 애초에 "전환 절차가 존재한다는 것을 증명하는 것" 입니다. 알고리즘 롤오버를 한 번도 해 본 적이 없다면, 정말 필요한 순간(어떤 알고리즘이 깨졌을 때)에 할 수 없습니다. SSR2가 지적한 공백이 정확히 이것이었습니다.

덧붙여, RFC 9904는 알고리즘 요구사항의 정본을 RFC 문서에서 IANA 레지스트리로 옮겼습니다. 즉 위 표는 스냅숏이고, 앞으로 권고 등급이 바뀌면 RFC 개정이 아니라 레지스트리가 갱신됩니다. 코드나 문서에서 RFC 8624를 참조하고 있다면 지금이 고칠 때입니다.

알고리즘 롤오버의 역설 — 1536비트 논쟁

이제 이 글에서 가장 흥미로운 부분입니다.

ECDSA P-256으로 가려는 이유 중 하나가 서명이 작다는 것인데, 거기 도달하려면 먼저 응답을 훨씬 크게 만들어야 합니다. 이중 서명 방식이니 전환 기간 동안 루트 존은 RSA와 ECDSA 양쪽으로 서명되고, DNSKEY 세트에는 양쪽 키가 다 실립니다.

제안서는 이 문제를 정면으로 설명합니다. 2018년과 그 다음 KSK 롤오버에서 응답 크기가 문제되지 않았던 이유는, 알고리즘이 바뀌지 않는 롤오버에서는 DNSKEY 응답의 크기만 영향을 받기 때문입니다. 그리고 루트 서버가 받는 전체 질의 중 DNSKEY 질의는 0.5퍼센트도 되지 않습니다. DNSKEY 응답이 잘려서 TCP로 재시도되더라도 루트 서버 시스템에 미치는 영향은 무시할 만합니다.

그런데 이중 서명 알고리즘 롤오버에서는 위임(referral) 응답과 NXDOMAIN 응답까지 커집니다. 이건 루트 트래픽의 대부분입니다. 여기에 2020년 DNS Flag Day가 기본 최대 UDP 버퍼 크기로 1232바이트를 밀어붙인 것이 겹칩니다. 제안서의 결론은 냉정합니다 — 2048비트 ZSK로 이중 서명을 하면 대부분의 루트 서버 응답이 잘려서 TCP 재시도로 이어진다는 것입니다.

그래서 나온 대책이 이겁니다. 알고리즘 롤오버 시작 전에 RSA ZSK를 2048비트에서 1536비트로 낮춘다. 1536은 1024와 2048의 중간값이고, 이 크기여야 (분기별 ZSK 롤오버 중의 DNSKEY 응답을 빼면) 거의 모든 응답이 1232바이트 아래로 들어옵니다.

즉 응답 크기를 지키기 위해 암호 키를 일부러 약하게 만드는 것입니다. 그것도 약 3년 동안.

공개 의견 수렴에서 가장 많이 논쟁된 지점이 정확히 이것이었습니다. 의견 수렴 결과 보고서에 따르면 총 12건이 제출됐고, 여기에 ICANN 보안·안정성 자문위원회(SSAC)의 지각 제출 1건이 포함됐습니다. RSSAC, RySG, Verisign 세 조직은 지지를 표명했고, 네 명은 지지하면서 권고를 붙였고, 네 명은 우려나 반대를 제기했습니다.

반대 측 논거는 구체적입니다. 1536비트는 NIST가 인정하는 표준 RSA 키 크기가 아니고, 이 축소는 ZSK의 유효 보안 강도를 약 112비트에서 약 90~96비트로 낮추며, 이 저하된 상태가 롤오버 기간인 약 3년간 지속된다는 것입니다.

ICANN의 답변도 읽어볼 만합니다. 요점은 노출 창(exposure window)입니다. SSAC의 분석에 동의하면서, 각 ZSK 키가 실제로 사용되고 공개적으로 관측 가능한 기간이 약 110일이며 이 기간은 1536비트 키에 대한 무차별 대입 공격이 현재 역량으로 실현 가능하기에는 너무 짧다고 봅니다. 그리고 이렇게 적었습니다 — "2048비트 키 대비 보안 저하는 실재하지만 이 운영 창에 의해 한정된다(The security reduction relative to a 2048-bit key is real but bounded by this operational window)." 이 문장을 완화해서 옮기지 않는 게 중요합니다. ICANN은 보안이 낮아진다는 사실 자체를 부정하지 않습니다.

NIST 표준 크기가 아니라는 지적에 대해서는, NIST 키 관리 지침이 1024·2048·3072비트를 참조 크기로 열거하는 것은 맞지만 DNSSEC 운영에서 비표준 RSA 키 크기가 전례 없는 일은 아니며 루트 존 ZSK 자체가 예전에 1280비트였다고 답합니다.

숫자 쪽에서는 Verisign이 RSSAC-002 트래픽 데이터에 기반한 실증 분석을 함께 제출했는데, 1536비트 RSA ZSK와 ECDSA ZSK 조합이 응답의 약 1~5퍼센트를 1232바이트 위로 밀어 올릴 것이라는 결과였습니다. 완벽하지 않지만 2048비트를 유지하는 쪽보다 실질적으로 나은 결과라는 것이 ICANN의 판단입니다. 이것도 제출자 자체 측정이며, RSSAC-002 트래픽 데이터라는 특정 데이터셋에 기반한 추정치입니다.

또 하나 제기된 우려는 단계 일정 조정을 촉발하는 기준이 정의돼 있지 않다는 것이었습니다. 언제 연장하고 언제 후퇴할지의 판단 기준이 명문화돼 있지 않다는 지적입니다. 2017년의 연기가 결국 판단의 문제였다는 걸 생각하면 정당한 지적입니다.

결과는 이렇습니다. 계획에 구조적 변경은 없었습니다. ICANN은 제안대로 진행하되, 단계 전환 기준을 별도로 게시하고 운영자 커뮤니티를 대상으로 표적 아웃리치를 하겠다고 밝혔습니다.

기술적으로 재미있는 반론이 하나 더 있었습니다. 제안된 Phase DD는 ECDSA 서명을 먼저 게시하고 대응하는 ECDSA DNSKEY는 아직 게시하지 않는 단계인데, 여기에 대해 서명만 게시하는 것은 보안상 이득이 없고 어차피 ECDSA 공개키는 서명으로부터 복구 가능하다는 지적이 나왔습니다. 암호학적으로 맞는 말입니다.

언제 이게 당신 문제가 아닌가

정직하게 정리하면, 이 글을 읽는 대부분의 사람은 아무것도 할 필요가 없습니다.

신경 쓸 필요 없는 경우

DNSSEC 검증을 하지 않는다. (대부분의 사내 리졸버가 여기 해당합니다.)
Cloudflare, Google, Quad9 같은 퍼블릭 리졸버를 쓴다. 그들의 문제이지 당신의 문제가 아닙니다.
관리형 리졸버를 쓰고 벤더가 트러스트 앵커를 관리한다.
최신 BIND/Unbound/Knot을 기본 설정으로 돌리고 있고, RFC 5011 자동 갱신이 켜져 있으며, 2025년 2월 이후로 계속 떠 있었다. 이 경우 이미 KSK-2024를 갖고 있습니다.

확인해야 하는 경우

검증 리졸버를 직접 운영한다.
트러스트 앵커를 수동으로 설정했거나, 설정 관리 도구로 root.key 파일을 배포하고 있다. RFC 5011이 꺼져 있다면 자동 갱신은 일어나지 않습니다. ICANN이 RFC 5011을 쓰지 않는 소프트웨어를 위해 IANA 웹사이트에 트러스트 앵커 파일을 게시하는 이유가 이것이고, 권고는 리졸버 기동 시와 루트 DNSKEY 세트의 KSK가 바뀔 때 그 파일을 받아오라는 것입니다.
컨테이너 이미지나 어플라이언스에 트러스트 앵커가 구워져 있다. 이미지가 2025년 2월 이전에 빌드됐고 그 뒤로 재빌드되지 않았다면, 그리고 RFC 5011 상태 파일이 영속 볼륨이 아니라 컨테이너 레이어에 있어서 재시작마다 초기화된다면, 30일 홀드다운은 영원히 완료되지 않습니다. 이게 현대적 배포 환경에서 가장 그럴듯한 실패 모드입니다.
에어갭 환경이거나 루트 서버로의 아웃바운드가 제한돼 있다.

확인 방법은 단순합니다. 리졸버의 트러스트 앵커 저장소에 38696이 있는지 보면 됩니다. 있으면 끝입니다.

마치며

정리하면 이렇습니다. 2026년 10월 11일에 루트 KSK가 KSK-2017에서 KSK-2024로 넘어갑니다. 오늘 루트 존을 열어보면 두 키가 이미 나란히 들어 있고, 서명은 아직 KSK-2017이 하고 있습니다. RFC 5011을 켜 둔 리졸버는 2025년 2월에 이미 새 키를 받아들였으므로 그날 아무 일도 겪지 않습니다. 받아들이지 못한 리졸버는 그날 바로 죽습니다 — 2027년 1월까지의 유예 기간 같은 건 없습니다. KSK-2017이 존에 남아 있는 것은 규정대로 폐기당하기 위해서입니다.

2017년의 교훈은 여전히 유효합니다. 그때 롤오버를 1년 멈춰 세운 것은 게으른 운영자가 아니라 널리 쓰이는 리졸버의 자동 갱신 버그였고, 그걸 알아낸 것은 나온 지 다섯 달 된 텔레메트리 표준이었습니다. 자동화를 켜 뒀다는 것과 자동화가 동작하고 있다는 것은 다른 이야기입니다. 그래서 이번 계획은 2년 가까운 사전 게시 기간을 뒀습니다.

그리고 이번 롤오버는 알고리즘을 바꾸지 않습니다. 진짜 어려운 일 — RSA에서 ECDSA로 — 은 2027년에 시작해 2030년까지 가는 별개의 프로젝트이고, 그 계획은 응답 크기를 지키려고 RSA ZSK를 3년간 일부러 약하게 만들자는 제안 때문에 가장 많은 반론을 받았습니다. ICANN은 그 저하가 "실재하지만 한정된다"고 인정하면서 계획대로 갑니다.

이 두 가지가 이 글의 진짜 요점일지도 모릅니다. 인터넷의 신뢰 앵커를 바꾸는 일은 암호학 문제가 아니라 배포 문제이고, 배포된 세계에서는 7년 전에 죽은 키가 아직도 트러스트 스토어에 남아 있습니다. 그리고 안전한 전환을 설계하다 보면, 전환하는 동안만큼은 덜 안전해지는 것을 받아들여야 하는 순간이 옵니다. 정직한 계획은 그걸 숨기지 않고 문서에 적습니다.

지금 할 일이 있다면 하나뿐입니다. 검증 리졸버를 운영한다면, 트러스트 앵커 저장소를 열어 38696이 있는지 확인하십시오. 87일 남았습니다.