DNSSEC 루트 키 교체 예정: 10월 11일 무엇이 바뀌고 누가 점검해야 할까

DNSSEC 루트 키 교체와 우리가 확인할 것

2026년 10월 11일, DNS 응답 검증의 기준이 되는 루트 암호키가 교체될 예정입니다. 인터넷 식별자 관리 기능을 수행하는 IANA가 예고한 DNS 루트 키 교체입니다. 새 키는 KSK-2024이며, 키 태그는 38696입니다. [1]

일반 이용자가 비밀번호를 바꾸거나 프로그램을 설치할 일은 대개 없습니다. 중요한 점검 대상은 DNS 응답을 직접 검증하는 서버입니다. 이 글에서는 무엇이 바뀌는지, 누가 확인해야 하는지, 준비 상태 테스트를 어디까지 믿을 수 있는지 살펴보겠습니다. [11]

1 웹사이트 주소를 찾는 과정

도메인 이름 시스템(Domain Name System, DNS)은 사람이 입력한 도메인 이름을 컴퓨터가 이용할 주소 등으로 바꾸어 줍니다. 이 조회를 대신 수행하는 서버가 재귀 리졸버(recursive resolver)입니다. 통신사나 조직의 DNS 서버, 공용 DNS 서비스가 이 역할을 맡을 수 있습니다. [4]

그림 1 캐시가 없을 때의 DNS 주소 조회 개념도 [4]

리졸버는 루트 서버에서 .com 같은 최상위 도메인의 담당 서버를 안내받고, 그다음 해당 도메인의 권한 서버로 찾아갑니다. 매번 처음부터 모든 서버에 묻지는 않습니다. 이미 받은 응답을 일정 시간 저장하는 캐시 덕분입니다. [4]

2 주소가 진짜인지 확인하는 신뢰 사슬

DNS 보안 확장(Domain Name System Security Extensions, DNSSEC)은 DNS 데이터에 전자서명을 붙이고 검증하는 체계입니다. 응답이 해당 영역의 정당한 출처에서 왔는지, 중간에 바뀌지 않았는지 확인할 수 있습니다. DNS 질의 내용을 숨기는 암호화 기능은 제공하지 않습니다. [5]

검증에도 출발점이 필요합니다. 리졸버가 미리 신뢰하도록 설정한 공개키나 그 식별 정보를 신뢰 앵커(trust anchor)라고 합니다. 루트에는 자신을 보증해 줄 상위 영역이 없으므로, 루트 KSK의 공개 정보가 이 출발점이 됩니다. [1][5]

용어	맡는 역할
키 서명 키 Key Signing Key · KSK	루트의 공개키 묶음인 DNSKEY 레코드 집합에 서명
영역 서명 키 Zone Signing Key · ZSK	루트의 일반 DNS 데이터에 서명하며, 하위 영역의 DS도 여기에 포함
위임 서명자 레코드 Delegation Signer · DS	부모 영역에 놓이는 자식 공개키의 지문으로 신뢰 사슬을 연결

표 1 루트에서의 키 역할과 영역 사이의 연결 [5][12]

그림 2 서명된 위임을 따라 이어지는 DNSSEC 신뢰 사슬 [5][12]

이번에는 이 사슬 맨 위에서 공개키 묶음에 서명하는 키가 바뀝니다. 새 키를 신뢰하지 못하는 검증 리졸버는 정상 응답도 검증 실패로 처리할 수 있습니다. 웹사이트가 정상적으로 운영되고 있어도, 해당 리졸버를 사용하는 이용자에게는 주소 조회 오류가 나타날 수 있습니다. [3]

3 10월 11일에 실제로 바뀌는 것

기존 KSK-2017의 키 태그는 20326, 후속 KSK-2024의 키 태그는 38696입니다. 예정대로 전환하면 루트의 DNSKEY 레코드 집합을 서명하는 역할이 새 키로 넘어갑니다. 두 키는 모두 2048비트 RSA/SHA-256을 사용합니다. 이번 일정에 암호 알고리즘 변경이나 양자내성 암호 전환이 포함되는 것은 아닙니다. [1][3]

그림 3 배포 공지부터 전환까지의 주요 단계 [1][6][10][11]

2024년 7월 24일은 새 신뢰 앵커 배포를 알린 날짜입니다. 루트 DNS에 새 키를 미리 올린 날은 2025년 1월 11일입니다. 2026년 10월 11일은 새 키가 서명을 맡는 전환 예정일입니다. 공지, 사전 공개, 실제 역할 전환을 구분해야 합니다. [1][10]

여기서 10월 11일은 공식 일정에 적힌 날짜입니다. 확인한 IANA 일정표와 ICANN 운영 가이드에는 정확한 전환 시각이나 시간대가 별도로 적혀 있지 않습니다. 따라서 이 자료만으로는 한국시간 기준 전환 시각을 확정하기 어렵습니다.

4 자동 갱신이 있어도 확인하는 이유

RFC 5011에 따른 자동 갱신은 기존에 신뢰하는 키로 새 키가 들어 있는 공개키 묶음을 검증합니다. 새 키를 보자마자 받아들이지 않고 최소 30일의 추가 대기 기간을 거칩니다. 첫 관측 자료의 TTL이 30일보다 길면 더 오래 기다리며, 이후 검증 조건도 충족해야 합니다. [6]

따라서 10월 11일 전환을 며칠 앞두고 새 키를 처음 발견한 서버는 자동 갱신의 최소 대기 기간을 채울 수 없습니다. 새 키가 이미 신뢰 앵커로 등록되어 있는지 확인하고, 없다면 사용 중인 리졸버 공급사의 갱신 절차를 따라야 합니다. ICANN도 자동 갱신의 성공을 가정하지 말고 현재 설정을 확인하라고 안내합니다. [2][6]

5 내가 해야 할 일이 있는지 구분하기

사용 환경	이번에 확인할 일
일반 인터넷 이용자	대부분 별도 조치가 없습니다. 불확실하면 이용 중인 DNS 제공자에게 준비 여부를 문의합니다.
DNS 호스팅을 맡긴 사이트 운영자	이번 루트 키 교체만을 이유로 자체 도메인의 키나 DS를 바꿀 필요는 대개 없습니다. 직접 운영하는 검증 리졸버가 있는지는 별도로 확인합니다.
조직 또는 개인의 검증 리졸버 운영자	신뢰 앵커에 KSK-2024가 실제로 등록되어 있는지 확인합니다. 누락되었다면 공급사 지침으로 갱신합니다.

표 2 역할에 따른 점검 범위 [2][8][11]

6 준비 상태 테스트를 읽는 방법

Cloudflare는 브라우저로 열 수 있는 KSK-2024 준비 상태 테스트를 제공합니다. RFC 8509의 신뢰 앵커 센티널(trust anchor sentinel) 방식으로, 현재 조회 경로가 새 키를 신뢰하는지 알아봅니다. [7][9]

테스트 열기 dnstest.dev/ksk-2024/

테스트가 보여 주는 상황	해석과 다음 단계
새 키 신뢰가 확인됨	지금 테스트에 응답한 DNS 조회 경로에서 준비 상태가 확인된 것입니다.
새 키를 신뢰하지 않는 결과	테스트의 대조 항목이 정상이라는 전제에서, 리졸버 운영자가 신뢰 앵커를 점검해야 합니다.
판정 불가 또는 불확실	센티널 미지원, 조회 실패, 여러 리졸버의 혼합 응답 등이 원인일 수 있습니다. 새 키 누락을 뜻한다고 단정할 수 없습니다.

표 3 테스트 결과의 의미와 후속 조치 요약 [7][9]

브라우저의 보안 DNS 설정이나 VPN에 따라 테스트가 거치는 리졸버가 달라질 수 있습니다. 테스트 결과는 해당 DNS 조회 경로에 한정됩니다. 회사의 다른 기기와 애플리케이션이 쓰는 경로는 별도로 확인해야 합니다. 테스트 페이지는 JavaScript 실행이 필요합니다. [8][9]

운영자는 ICANN 안내에 따라 실제 신뢰 앵커 설정을 직접 확인하는 것이 우선입니다. 센티널 진단은 보조 수단이며, 새 키를 화면에 보여 주는 것과 리졸버가 이미 신뢰하는 것은 별개입니다. [2][7]

7 운영자를 위한 마지막 점검

자체 DNS 검증 환경을 운영한다면 다음 순서로 점검할 수 있습니다.

• 실제 사용 경로를 확인합니다. 호스트 OS뿐 아니라 컨테이너, 애플리케이션, 별도 보안 DNS 설정이 쓰는 리졸버도 포함합니다. [3]

• 각 검증 리졸버의 신뢰 앵커에서 KSK-2024와 키 태그 38696을 확인합니다. 파일에 후보 키가 보이는지만 확인하지 말고, 제품이 표시하는 신뢰 상태도 점검합니다. [2][6]

• 누락된 환경은 공급사 지침으로 갱신합니다. 전환이 가까운 시점에는 자동 학습만 켠 뒤 기다리는 것으로 끝내지 않습니다. [1][6]

• 전환 후 DNS 조회 오류와 검증 실패 로그를 살펴봅니다. 캐시 때문에 문제가 뒤늦게 드러날 수 있으며, 전환 순간 정상이라는 사실만으로 준비를 확정할 수 없습니다. [3]

문제가 생겼다고 개인 이용자가 DNSSEC 검증을 끄거나 회사의 DNS 설정을 임의로 바꿀 필요는 없습니다. 조회 오류의 원인을 담당자에게 확인하고, 운영자는 새 신뢰 앵커를 정상 반영하는 절차부터 점검하는 것이 좋습니다.

일반 이용자에게는 조용히 지나갈 가능성이 큰 변화입니다. 직접 검증 서버를 운영한다면 확인할 질문은 분명합니다. 지금 서비스를 제공하는 리졸버가 KSK-2024를 실제로 신뢰하고 있는지입니다.

참고 자료

[1] IANA 공식 일정과 키 상태

[2] ICANN 운영자 안내

[3] ICANN 전환 영향 가이드 2026년 7월 27일

[4] RFC 1034 DNS의 기본 동작

[5] RFC 4033 DNSSEC의 기능과 신뢰 사슬

[6] RFC 5011 신뢰 앵커 자동 갱신

[7] RFC 8509 신뢰 앵커 센티널

[8] Cloudflare의 전환 안내 2026년 10월 6일

[9] Cloudflare KSK 2024 준비 상태 테스트

[10] IANA 최초 배포 공지 2024년 7월 24일

[11] ICANN 루트 KSK 교체 FAQ

[12] RFC 6781 DNSSEC 키 운영 지침

이 글은 2026년 10월 8일 확인한 공식 자료를 바탕으로 작성했습니다. 일정은 변경될 수 있으므로 실제 운영 전 IANA와 ICANN의 최신 안내를 확인하세요. 개인 또는 조직 환경에서 테스트를 실행한 결과를 제시한 글은 아닙니다.